HTTP keep-alive with long connections

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.

The so-called keep-alive connection in the previous HTTP protocol refers to the completion of multiple HTTP requests in a single TCP connection

, but the header is still to be sent separately for each request; the so-called polling is the active sending of HTTP request queries from the client (typically the browser) to the server for 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.

Not reliable (unreliable)

HTTP is a stateless protocol, which means that each request is independent and keep-alive failed to change the result. In addition, Keep-alive does not guarantee that the connection between the client and the server must be active, as is the case in the HTTP1.1 version. The only guarantee is that when the connection is closed you can get a notification, so you should not let the program rely on keep-alive to maintain the connection characteristics, otherwise there will be unintended consequences keep-alive is really efficient, saving a lot of time, but it is not without shortcomings. We all know that an operating system can support a limited number of connections, using ulimitcommand to view the maximum number of connections for the current system.

HTTP keep-alive with long connections