Xiaobian first used to see the introduction of a Chinese encyclopedia website to the Web Socket, feel very embarrassed. If you follow this answer to participate in the Internet companies such as BAT front-end development interview, estimated will be despised.
Let’s read some English material.
Let’s go straight to stackOverflow and translate:
Original address:
Stackoverflow.com/questions/1…
This discussion has over 80,000 views.
First, let’s read this response, which has 166 likes:
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. When we send a number of bytes from the buffer to a normal TCP socket, the SEND system call returns the number of bytes actually 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 the destination socket for sending data is a non-blocking socket or a non-blocking socket for writes, the number of bytes sent may be less than the number of bytes waiting to be sent in 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. If it is a blocking socket, the two will be equal because, as the name implies, the API call will not return if the SEND system call does not send all the data to be sent.
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.
The difference between a Web socket and a TCP socket is that the data sent is no longer a series of bytes, but is sent in a complete “message body”, which cannot be further divided. Either all the data is sent successfully or none is sent at all. There is no partial sending as with TCP socket non-blocking operations. In other words, operations on sockets in Web sockets are non-blocking operations.
This distinction is also clearly stated on Wikipedia: Websocket addressed to pegasus int ‘l from TCP in that it enables a stream of messages instead of a stream of bytes
Let’s look at the receiver differences. The original: 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 correspond 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 receipt 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.
Similarly, in the TCP socket scenario, the number of bytes read by the receiver from the TCP socket is not necessarily the same as the number of bytes sent by the sender calling SEND. But the WebSocket? The receiver of a WebSocket reads data from a socket, rather than using recV /read directly like a TCP socket, using an event-driven mechanism. That is, the application registers an event handler, which is called as a callback when the data sent by the sender of the Web socket is available after the receiver has copied the data from the kernel buffer to the application layer.
Here’s an example:
I sent a message “Wang Zixi” through WebSocket:
The string seen in the debugger is injected into the function as an input parameter to the callback function:
WebSocket message body observed in Chrome Developer Tools:
When asked about the difference between TCP and WebSocket in your next interview, you should know what to say.
For more of Jerry’s original articles, please follow the public account “Wang Zixi “:
