After reading the long connection in HTTP protocol, most programmers collected it...

What is a long connection?

Long connection or short connection

Compared with short connections, long connections save more resources. If you need to create a link, initiate handshake authentication, and close the link to release resources every time you send a message, it will consume a lot of system resources. Long connections are only created when they are first created or when the link is disconnected and reconnected. After the link is created, the service provider and consumer will maintain the link through business messages and heartbeats, so that multiple messages can reuse the same link to save resources.

[[283396]]

HTTP1.1 stipulates that the default long connection (HTTP persistent connection, also translated as persistent connection) is maintained. After the data transmission is completed, the TCP connection is kept open (no RST packet is sent, no four-way handshake), waiting to continue using this channel to transmit data under the same domain name; the opposite is a short connection.

The HTTP header Connection: Keep-alive is an experimental extension of HTTP1.0 browsers and servers. The current HTTP1.1 RFC2616 document does not explain it because the required function is already enabled by default and does not need to be included. However, in practice, it can be found that browser message requests will include it. If the HTTP1.1 version of the HTTP request message does not want to use a long connection, it is necessary to add Connection: close to the HTTP request message header. The "HTTP Authoritative Guide" mentioned that some old HTTP1.0 proxies do not understand Keep-alive, which causes the long connection to fail: client-->proxy-->server, the client carries Keep-alive, but the proxy does not recognize it, so it forwards the message intact to the server, the server responds to Keep-alive, and is also forwarded to the client by the proxy, so the "client-->proxy" connection and the "proxy-->server" connection are kept open. However, when the client sends the second request, the proxy will think that there will be no request for the current connection, so it ignores it and the long connection fails. The book also introduces a solution: when the HTTP version is 1.0, Keep-alive is ignored, and the client knows that a persistent connection should not be used. In fact, in actual use, there is no need to consider so much. In many cases, the proxy is controlled by ourselves, such as Nginx proxy. The proxy server has persistent connection processing logic, and the server does not need to do patch processing. It is common that the client and the Nginx proxy server use HTTP1.1 protocol & persistent connection, while the Nginx proxy server and the backend server use HTTP1.0 protocol & short connection.

In actual use, the presence of the Keep-Alive value in the HTTP header does not necessarily mean that a long connection will be used. Both the client and the server can ignore this value, that is, they do not follow the standard. For example, when I write a multi-threaded HTTP client to download files, I do not follow this standard. Concurrent or continuous multiple GET requests are separated in multiple TCP channels. Each TCP channel has only one GET. After the GET is completed, there is a four-way handshake of TCP closing immediately. This makes it easier to write code. At this time, although the HTTP header has Connection: Keep-alive, it cannot be said to be a long connection. Under normal circumstances, client browsers and web servers have implemented this standard because their files are small and numerous, and it is valuable to maintain a long connection to reduce the overhead of reopening TCP connections.

Previously, when using libcurl to upload/download, it was a short connection. By capturing the packets, we can see: 1. Each TCP channel has only one POST; 2. After the data transmission is completed, we can see the four-way handshake packet. As long as curl_easy_cleanup is not called, the curl handle may always be valid and reusable. I say may here because the connection is bilateral. If the server is closed, then my client side cannot achieve a long connection even if it is kept.

If you use the Windows WinHTTP library, when you POST/GET data, although I close the handle, the TCP connection will not be closed immediately, but will wait for a while. At this time, the underlying WinHTTP library supports the functions required for Keep-alive: Even without Keep-alive, the WinHTTP library may add this TCP channel multiplexing function, while other network libraries like libcurl will not do this.

1. Overview

To improve network performance optimization, it is very important to reduce latency and increase response speed.

Usually when we make a request in the browser, the header part is often like this

Keep-alive is to maintain a long connection between the browser and the server, and this connection can be reused. It is enabled by default in HTTP1.1.

2. Why does connection reuse improve performance?

Usually when we initiate an http request, we first need to complete the TCP three-way handshake, then transmit data, and finally release the connection. The three-way handshake process can be referred to here TCP three-way handshake detailed explanation and connection release process

One response process

In the case of high-concurrency request connections or multiple frequent request operations from the same client, unlimited creation will lead to poor performance.

If you use keep-alive

During the timeout idle time, the connection will not be closed, and the same repeated request will reuse the original connection, reducing the number of handshakes and greatly improving efficiency.

It is not the case that the longer the keep-alive timeout is set, the better the performance will be. If it is not closed for a long time, too many zombie connections and leaked connections will appear.

Then okttp on the client side is similar to the keep-alive mechanism implemented by the client.

2. Expiration time of long connection

In the figure above, Keep-Alive: timeout=20 means that this TCP channel can be maintained for 20 seconds. In addition, there may be max=XXX, which means that this long connection will be disconnected after receiving XXX requests at most. For the client, it doesn't matter if the server does not tell the client the timeout. The server may actively initiate a four-way handshake to disconnect the TCP connection, and the client will know that the TCP connection is invalid. In addition, TCP also has a heartbeat packet to detect whether the current connection is still alive. There are many ways to avoid wasting resources.

3. Data transmission completion identification of long connection

After using a persistent connection, how do the client and server know that the transmission is over? There are two parts: 1. Determine whether the transmitted data has reached the size indicated by Content-Length; 2. Dynamically generated files do not have Content-Length, and they are transmitted in chunks (chunked). In this case, we need to judge based on the chunked encoding. The chunked encoded data has an empty chunked block at the end, indicating that the data transmission is over. For more details, please refer to this article.

1. Limitation on the number of concurrent connections

In web development, we need to pay attention to the number of concurrent browser connections. The RFC document says that the client and the server can connect to two channels at most, but it is up to the server and individual clients to do so. Some servers limit the number of TCP connections to only one at a time, which makes the client's multi-threaded download (the client connects to multiple TCP channels with the server to pull data at the same time) unable to play its role, while some servers have no restrictions. The browser client is more disciplined and limits the number of concurrent TCP connections that can be started under the same domain name to download resources. The limit on the number of concurrent connections is also related to long connections. When opening a web page, the download of many resources may be placed in only a few TCP connections. This is TCP channel reuse (long connection). If the number of concurrent connections is small, it means that it takes longer to download all resources on the web page (users feel that the page is stuck when opening); if the number of concurrent connections is large, the server may have a higher resource consumption peak. The browser only limits the concurrent connections under the same domain name, which means that web developers can put resources under different domain names and put these resources on different machines, which is a perfect solution.

Easily confused concepts - TCP keep alive and HTTP keep-alive:

• TCP keep alive is to check whether the current TCP connection is alive;
• HTTP's Keep-alive is to keep a TCP connection alive longer. They are concepts at different levels.

TCP keep alive performance:

When a connection has no data communication for a period of time, one party will send a heartbeat packet (Keep Alive packet). If the other party responds, it indicates that the current connection is valid and continues to be monitored.

This "period of time" can be set. Please google it for details.

2. HTTP pipelining

The benefits of using HTTP persistent connection include the use of HTTP pipelining (also translated as pipelined connection), which means that multiple HTTP requests can be made in parallel within a TCP connection, and the next HTTP request is initiated before the response to the previous HTTP request is completed. From the wiki, I learned that this technology is not widely used at present. The use of this technology requires both the client and the server to support it. Currently, some browsers fully support it, and the server's support only requires: correctly returning the Response in the order of HTTP requests (that is, the request & response adopt FIFO mode). The wiki also specifically points out that as long as the server can correctly handle client requests using HTTP pipelinning, then the server supports HTTP pipelining.

Since the order in which the server returns the response data must be consistent with the order in which the client requested it, FIFO is required, which can easily lead to Head-of-line blocking: the response to the first request affects the subsequent requests. For this reason, the performance improvement of HTTP pipelining technology is not obvious (Wikipedia mentions that this problem will be solved in HTTP2.0). In addition, this technology must be used with idempotent HTTP methods, because the client cannot know how far it has been processed, and unpredictable results may occur after retrying. The POST method is not idempotent: for the same message, the first POST and the second POST may perform differently on the server.

The HTTP persistent connection wiki mentions the guiding significance of HTTP1.1's pipeline technology for the RFC's stipulation that a user has a maximum of two connections: if the pipeline technology is implemented well, having more connections will not improve performance. I think so too. Concurrency has been achieved in a single connection, so there is no need for more connections, unless the bottleneck is the resource limitation on a single connection, forcing you to open more connections to compete for resources.