Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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:

  • fundamental difference between websockets and pure TCP
  • How to establish a TCP Socket connection from a web browser (client side)?

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?

like image 445
pierroz Avatar asked Jun 05 '13 16:06

pierroz


People also ask

What is the difference between TCP socket and WebSocket?

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.

What is the difference between sockets and WebSockets?

WebSockets typically run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic.

Are WebSockets faster than TCP?

WebSockets performs quite well, with an average round trip time of about 20 microseconds (0.02 milliseconds), but straight up TCP still beats it handily, with an average round trip time of about 2 microseconds (0.002 milliseconds), an order of magnitude less.

Is WebSocket slower than TCP?

So to break it all down in terms of speed: A websocket connection is a little slower than a "raw" TCP one, and TCP is a little slower than UDP (when it comes to real time transmission of data), but this comes at the cost of lost packets - right?


1 Answers

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.

like image 171
kanaka Avatar answered Oct 03 '22 22:10

kanaka