214

Trying to understand as best as I can the differences between TCP socket and websocket, I've already found a lot of useful information within these questions:

and so on...

In my investigations, I went through this sentence on wikipedia:

Websocket differs from TCP in that it enables a stream of messages instead of a stream of bytes

I'm not totally sure about what it means exactly. What are your interpretations?

kanaka
  • 70,845
  • 23
  • 144
  • 140
pierroz
  • 7,653
  • 9
  • 48
  • 60
  • 1
    I think your sentence from Wikipedia is a little misleading. From what I've just read from your links it seems like WebSockets are just HTTP TCP connections used for non-http traffic. IE, you negotiate with the server on a TCP connection to it's port 80 to use the socket for say VPN type traffic or something. So a websocket would just be a non-http, http socket? Spitballing... Not sure what they mean by "messages" instead of bytes from the Wikipedia excerpt. – 0xhughes Jun 05 '13 at 16:44
  • 5
    Messages: Gimme a json payload, gimme another json payload. Complete messages Byte Stream: Give me n number of bytes, I'll respond with 100 Continue and you give me the next n number bytes. Repeat until there are no more bytes. These are incomplete messages that are reassembled on the server. Use for streaming and chunking – Sinaesthetic Aug 14 '18 at 17:52

2 Answers2

292

When you send bytes from a buffer with a normal TCP socket, the send function returns the number of bytes of the buffer that were sent. If it is a non-blocking socket or a non-blocking send then the number of bytes sent may be less than the size of the buffer. If it is a blocking socket or blocking send, then the number returned will match the size of the buffer but the call may block. With WebSockets, the data that is passed to the send method is always either sent as a whole "message" or not at all. Also, browser WebSocket implementations do not block on the send call.

But there are more important differences on the receiving side of things. When the receiver does a recv (or read) on a TCP socket, there is no guarantee that the number of bytes returned corresponds to a single send (or write) on the sender side. It might be the same, it may be less (or zero) and it might even be more (in which case bytes from multiple send/writes are received). With WebSockets, the recipient of a message is event-driven (you generally register a message handler routine), and the data in the event is always the entire message that the other side sent.

Note that you can do message based communication using TCP sockets, but you need some extra layer/encapsulation that is adding framing/message boundary data to the messages so that the original messages can be re-assembled from the pieces. In fact, WebSockets is built on normal TCP sockets and uses frame headers that contains the size of each frame and indicate which frames are part of a message. The WebSocket API re-assembles the TCP chunks of data into frames which are assembled into messages before invoking the message event handler once per message.

Rudolf Adamkovič
  • 31,030
  • 13
  • 103
  • 118
kanaka
  • 70,845
  • 23
  • 144
  • 140
  • Thank you very much! very helpful to me... Don't you want to update the wikipedia article? :) – pierroz Jun 05 '13 at 19:39
  • 5
    So a web socket is just an extra layer between a normal tcp socket and web browser? – Marc Casavant May 04 '14 at 15:45
  • 24
    @MarcCasavant the way you ask the question seems to imply that WebSockets is overhead with no good reason to exist. I would flip it around and say that WebSockets is an encapsulation of TCP that brings TCP like functionality and performance to browsers without using a plugin and without giving up hard-won browser security best practices (like CORS). After the hand-shake, the overhead of the extra layering is very light (2-byte header for small frames). – kanaka May 06 '14 at 18:34
  • Just trying to understand the concept :). I have no doubt that they are incredibly useful and awesome. I'm having a hard time visualizing how this all looks within the system. – Marc Casavant May 07 '14 at 22:21
  • 5
    @oberstet That's a considerable mis-statement of the [actual policy](http://en.wikipedia.org/wiki/Wikipedia:Expert_editors). What you allege would be absurd. All it really says is "Expert editors are cautioned to be mindful of the potential conflict of interest that may arise if editing articles which concern an expert's own research, writings, or discoveries." – user207421 Aug 11 '14 at 06:36
  • 2
    @EJP Yes, it is absurd. It is my experience how the policy unfolds in *practice*. The "policy police" comes around and removes valuable information - as acknowledged by actual readers. Please see http://en.wikipedia.org/wiki/Talk:Comparison_of_WebSocket_implementations and http://en.wikipedia.org/wiki/User_talk:Oberstet#Conflict_of_Interest_on_WebSockets_comparison – oberstet Aug 11 '14 at 07:43
  • 1
    One could say that WebSockets are the most standarized way of using a "RAW TCP/IP like connection" with a browser? Within the framing, it, though, does wait for the complete messages to be received. So it's not really a stream, but shouldn't be a problem (actually quite usefull). Check games based on WebSockets, they work in most browsers and are actually very responsive. – Paul Jul 05 '16 at 19:27
198

WebSocket is basically an application protocol (with reference to the ISO/OSI network stack), message-oriented, which makes use of TCP as transport layer.

The idea behind the WebSocket protocol consists of reusing the established TCP connection between a Client and Server. After the HTTP handshake the Client and Server start speaking WebSocket protocol by exchanging WebSocket envelopes. HTTP handshaking is used to overcome any barrier (e.g. firewalls) between a Client and a Server offering some services (usually port 80 is accessible from anywhere, by anyone). Client and Server can switch over speaking HTTP in any moment, making use of the same TCP connection (which is never released).

Behind the scenes WebSocket rebuilds the TCP frames in consistent envelopes/messages. The full-duplex channel is used by the Server to push updates towards the Client in an asynchronous way: the channel is open and the Client can call any futures/callbacks/promises to manage any asynchronous WebSocket received message.

To put it simply, WebSocket is a high level protocol (like HTTP itself) built on TCP (reliable transport layer, on per frame basis) that makes possible to build effective real-time application with JS Clients (previously Comet and long-polling techniques were used to pull updates from the Server before WebSockets were implemented. See Stackoverflow post: Differences between websockets and long polling for turn based game server ).

codeviper
  • 78
  • 10
Paolo Maresca
  • 7,396
  • 4
  • 34
  • 30