Source: author: dong but person links: https://www.zhihu.com/question/20215561/answer/40250050 zhihu copyright owned by the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.
You can think of WebSocket as a big patch for HTTP to support long connections. It has some commonalities with HTTP, and is an improved design to solve some problems that HTTP alone cannot solve. In the previous HTTP protocol, the so-called keep-alive connection refers to the completion of multiple HTTP requests in a TCP connection, but each request still needs to send a separate header. So-called polling involves repeatedly and actively sending HTTP requests from a client (typically a browser) to the server to find out if it has new data. A common shortcoming of these two modes is that in addition to the real data part, the server and the client have to exchange a large number of HTTP headers, making the information exchange very inefficient. The “long links” they make are bogus. Long connections, except that __ benefits do not require any changes to the existing HTTP Server and browser architectures.
The first problem WebSocket solves is that after establishing a TCP connection over the first HTTP Request, subsequent exchanges do not need to send HTTP Requests, making the long connection a true one. Long connection. However, the ability to exchange data without sending HTTP headers is obviously different from the original HTTP protocol, so it needs to be upgraded to both the server and the client. On this basis, WebSocket is also a two-channel connection, which can send and receive information on the same TCP connection. There is also multiplexing function multiplexing, which allows several different URIs to reuse the same WebSocket connection. These are all things that the original HTTP cannot do.
A little more technical detail, because seeing someone ask that WebSocket might go into some sort of half-dead state. This is actually some of the flaws in the design of the original online world. The above WebSocket is true. Although the long connection solves the problems on both sides of the server and the client, but the pit is the network application in addition to the server and the client, another huge existence is the intermediate network link. An HTTP/WebSocket connection often passes through numerous routes, firewalls. You think your data is being sent in a “connection,” but it actually has to cross many mountains, be forwarded many times, be filtered many times, and finally reach its destination. In this process, the middle nodes are likely to surprise you.
For example, these bad intermediate nodes might consider a connection to be dead if no data is sent for a period of time, and cut it off on their own initiative. In this case, neither the server nor the client receives any warning, and they simply assume that the red line between them is still there, sending messages over and over in vain that never reach the other side. The implementation of the network stack has layers of caches on top of each other, and until these caches are filled, your program won’t find any errors at all. In this way, a nice WebSocket long connection may enter a half-dead state without knowing it.
And the solution, WebSocket designers have already thought about. RFC 6455 – The WebSocket Protocol** allows The server and client to send Ping/Pong frames. This Frame is a special Data packet that contains only some metadata and does not require real Data Payload. It can maintain the connection status of the intermediate network without affecting the Application.