211

I've read about WebSockets and I wonder why browser couldn't simply open trivial TCP connection and communicate with server like any other desktop application. And why this communication is possible via websockets?

xap4o
  • 2,776
  • 2
  • 19
  • 13
  • Because WebSockets and browsers communicate at the application level via HTTP and not at transport layer via TCP? – anonymous Apr 21 '10 at 08:41
  • 8
    But what's the problem? Let them use TCP. – xap4o Apr 21 '10 at 08:46
  • 2
    More info http://stackoverflow.com/questions/8051516/how-to-establish-a-tcp-socket-connection-from-a-web-browser-client-side – Hernán Eche Jan 30 '13 at 11:54
  • 2
    "WebSocket is a protocol providing full-duplex communications channels over a single TCP connection". You can create TCP connections also which are full duplex? what is this special about WebSockets? – Abhishek Jain May 22 '14 at 09:39
  • 15
    The problem is that usually web servers have only one port open for security reasons, namely port `80`. By definition one port can attach to one application **ONLY**. So what if a client wants to use a service, other than web (HTTP) but there is only one port available? Voila! Websockets! – Pithikos Aug 20 '14 at 13:57
  • 3
    @Pithikos hit the bull's eye as to why we need this complexity of websockets and not just deal with straight TCP sockets for browser-server communication. – Sunny Dec 14 '15 at 16:03
  • 2
    reading the answers, I personally am left wondering if there are disadvantages, other than security, for http server to listen on one port and the socket server to listen on another port. – Alexander Mills Jan 21 '16 at 06:36

4 Answers4

316

It's easier to communicate via TCP sockets when you're working within an intranet boundary, since you likely have control over the machines on that network and can open ports suitable for making the TCP connections.

Over the internet, you're communicating with someone else's server on the other end. They are extremely unlikely to have any old socket open for connections. Usually they will have only a few standard ones such as port 80 for HTTP or 443 for HTTPS. So, to communicate with the server you are obliged to connect using one of those ports.

Given that these are standard ports for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you. The purpose of web sockets is to allow you to initiate a connection via HTTP, but then negotiate to use the web sockets protocol (assuming the server is capable of doing so) to allow a more "TCP socket"-like communication stream.

Ash
  • 9,296
  • 2
  • 24
  • 32
  • So basically WebSocket is simply a wrapper for TCP in the sense that UDP is simply a wrapper for IP? – Pacerier Feb 26 '13 at 18:06
  • 3
    @Pacerier: A WebSocket requires some sort of transport protocol to operate over, but that transport layer doesn't have to be TCP (it's almost always going to be TCP in practice though). You could think of WebSockets as a kind of wrapper around TCP, but I don't believe there's any prescriptive link between the two. – Ash Feb 27 '13 at 08:33
  • 5
    "Over the internet, you're communicating with someone else's server on the other end.""Given that these are standard ports(80 & 443) for web servers that generally speak HTTP, you're therefore obliged to conform to the HTTP protocol, otherwise the server won't talk to you." Usually, the websocket server that we access would be our own. So we can have an application with a protocol that we define listen to a port. Then, why would we need HTTP handshake and a protocol switching? Instead why can't we can directly follow a websocket like protocol? – ratul Oct 24 '13 at 13:44
  • @ratul: Not quite sure I understand 100% your situation, but it sounds like you're talking about where you control both the server and client infrastructure? As far as I know you can use any protocol for your web socket, depending on what the library you're using supports, or how much you're willing to write yourself. – Ash Oct 25 '13 at 11:44
  • 4
    By RFC6455, WebSocket needs a handshake in HTTP first and then the protocol upgrades to WebSocket. Most of the browser follow this. I don't know how your client side(browser) will support, if you are using any protocol in server. It is like we can communicate in french, only both of us know french. And handshaking is like, I asking you, 'Can we communicate in french?'in english(here HTTP). Here browsers(like chrome)know french but we have to teach server french. My question was why RFC6455(WebSocketProtocol)want to do the handshake in HTTP and complicate things, why can't they do it their way? – ratul Oct 25 '13 at 13:15
  • 1
    @ratul: While I think I see what you're getting at, the "why did they design the standard that way?" is beyond my understanding, but I'd guess that since it's _Web_Sockets, there's an implied assumption that HTTP will be in there somewhere. Perhaps you should ask a brand new question on your specific query, or post a query on the WHATWG mailing list? – Ash Oct 25 '13 at 13:23
  • Hi @Ash, I have a spring boot application with client server setup using web sockets. When I transfer a 40GB file it takes around 12 mins using web sockets. I am sending it in 4K blocks. Can you help me in understanding why it is slow? – Sreeja Mohan Jul 06 '17 at 20:30
  • @Sreeja I don't know sorry. You probably should create a question around that. – Ash Jul 08 '17 at 00:20
  • This answer could do with a simple explanation of what web sockets provide, i.e. full duplex data streams via HTTP. – wulfgarpro Oct 08 '17 at 03:05
  • @ratul I'd recommend avoiding external link shortening sites, Stack Overflow offers this if you click the share button on the bottom of the post. (FYI, the link goes to [Why websocket needs an opening handshake using HTTP? Why can't it be an independent protocol?](https://stackoverflow.com/a/19569871/4975230)) – jrh Dec 07 '18 at 20:57
44

Web browsers operate at the Application layer, whereas TCP operates at the Transport Layer. As a web application developer, it's easier to send messages over the wire via the Application Layer instead of raw bytes at the Transport Layer.

Underlying WebSockets is TCP, it's just abstracted away for simplicity.

wulfgarpro
  • 6,666
  • 12
  • 69
  • 110
3

Websocket is a application layer protocol while TCP is transport layer protocol. At transport layer, we usually have TCP and UDP protocol. Any message from application layer need to go through transport layer to be transmitted to other machine. Hence, websocket and tcp have a relationship to each other and can not be comparable.

Minh Trần
  • 356
  • 4
  • 13
3

To make it simple, the websocket communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.

Would you like to use existed TCP port or open a new TCP port that might be blocked by firewall?

Eugene
  • 10,627
  • 5
  • 49
  • 67