What is the principle of WebSocket? Why can I make a persistent connection

You can think of WebSocket as an HTTP protocol. In order to support a large patch of long connection, it and HTTP have some commonality, is to solve the HTTP itself can not solve some problems and make an improved design.  In the previous HTTP protocol, the so-called keep-alive connection refers to the completion of multiple HTTP requests in a single TCP connection, but it is still a separate header for each request, and the so-called polling is the proactive sending of the server from the client (typically the browser) HTTP Request query whether there is new data. One of the common drawbacks of these two modes is that the server and client have to exchange HTTP headers in large quantities in addition to the real data part, and the information exchange efficiency is very low. They establish a "long connection" that is pseudo. Long connections, but the benefit is that you do not need to modify the existing HTTP server and browser architecture to be implemented.

The first problem that WebSocket solves is that after the TCP connection is established through the first HTTP request, the subsequent exchange data does not need to send the HTTP request again, making the long connection become a true. Long connection. However, there is no need to send HTTP headers to Exchange data, which is obviously different from the original HTTP protocol, so it needs to be upgraded for both the server and the client. On this basis WebSocket is also a two-channel connection, which can be either sent or received on the same TCP connection. There are also multiplexing functions, and several different URIs can be reused for the same WebSocket connection. These are the original HTTP can not do.

Also say a little technical detail, because see someone ask WebSocket may enter some kind of half-dead state. This is actually some flawed design of the original network world. The WebSocket is true. Long connections solve both the server and the client side of the problem, but the pit is the network application in addition to the server and the client, another huge presence is the middle of the network link. A http/websocket connection often has to go through countless routes, firewalls. You think your data is sent in a "connection", in fact, it will cross the mountains and rivers, after countless times of forwarding, filtering, in order to finally reach the end. In this process, the processing of intermediate nodes is likely to surprise you.

For example, the middle nodes of these pits may think that a connection is useless without data sending for a period of time, and they will cut off these connections on their own. In this case, regardless of the server or the client will not receive any prompt, they will only wishful thinking that the red line between each other, in vain side by side to send the information can not reach the other shore. In the implementation of the computer network protocol stack There will be a layer of cache, unless you fill these caches, your program will not find any errors. In this way, a good WebSocket long connection, it may be unaware of the situation into a half-dead state.

And the solution, WebSocket designers have already thought. is to allow the server and client to send Ping/pong Frame (RFC 6455-the WebSocket Protocol). This Frame is a special kind of packet, it contains only some metadata and does not need the real data Payload, can maintain the connection state of the intermediate network without affecting the application.

What is the principle of WebSocket? Why can I make a persistent connection