Differences between TCP sockets and web sockets one more time

Question

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?

User · Answer

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 ).

User · Answer

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

[sockets] Differences between TCP sockets and web sockets, one more time

The answer is

Examples related to sockets

Examples related to tcp

Examples related to websocket

Tags