The night before the long link appeared

Before we get to the long connection, what is the short connection? In the original version of the HTTP protocol, TCP connections were disconnected for every HTTP communication.

In the early communications, there was no big problem because they were small text transfers. However, as the HTTP documents contained a large amount of rich text, for example, when browsing an HTML page with multiple images in a browser, when sending a request to access the HTML page resources, Other resources contained in the HTML page are also requested. Therefore, each request causes unnecessary TCP connections to be established and disconnected, which increases the overhead.

Keep alive – field

To solve this problem, some browsers use a non-standard Connection field when making requests.

Connection: keep-alive
Copy the code

The above fields require that the server not close the TCP connection so that other requests can be reused. The server also responds to this field.

Connection: keep-alive
Copy the code

Such a reusable TCP connection is established until the client or server actively closes the connection, but this is not a standard field and may not behave consistently across implementations, so it is not a fundamental solution.

Long connections appear

In January 1997, HTTP/1.1 was released, which further refined the HTTP protocol and remains the most popular version.

The biggest change in HTTP/1.1 is the introduction of HTTP Persistent Connections, which means that TCP Connections are not closed by default and can be reused by multiple requests without declaring the keep-alive field.

Benefits of persistent connections

  • This reduces the overhead caused by the repeated establishment and disconnection of TCP connections and reduces the load on the server side.
  • This allows HTTP requests and responses to end earlier, which increases the speed of web page display.

When the client and server discover that the other side is inactive for a period of time, they can actively close the connection. However, it is standard practice for the client to send Connection: close on its last request, explicitly asking the server to close the TCP Connection.

Connection: close
Copy the code

Currently, most browsers allow up to six persistent connections to the same domain name.

Pipeline mechanism

Note: The pipeline mechanism is based on persistent connections

HTTP/1.1 also introduced the pipelining mechanism, which allows clients to send multiple requests simultaneously within the same TCP connection, further improving the efficiency of the HTTP protocol, which previously required waiting and receiving the response before sending the next request. With the advent of pipelining, the ability to send the next request without waiting for a response makes it possible to send multiple requests in parallel without having to wait for one response after another. Persistent connections can end requests faster than one connection after another. Pipework is much faster than persistent connections, with the more requests, the more significant the time difference.

case

If A client needs to request two resources, it is before, in the same TCP connection, sends A request first, and then wait for the server accordingly, B requests again after you receive the pipe mechanism is to allow the browser sends A request and B at the same time, but the server is in accordance with the order, to respond to A request to respond to the request B.

The Content – Length field

A TCP connection can send back multiple responses, so there must be a mechanism to distinguish which response the packet belongs to. This is the role of the Content-Length field, which declares the Length of the data in the response.

Content-Length: 3495
Copy the code

The code above tells the browser that the response is 3495 bytes long and that the following bytes belong to the next response. In version 1.0, the Content-Length field was not required because the browser noticed that the server had closed the TCP connection, indicating that all the packets had been received.

Block transfer encoding

Premise condition is to use the Content – Length field, the server sends a response before, must know the response data Length, for some very time-consuming dynamic operations, this means that the server will have to wait until all finished, to send data, so the efficiency of no, better processing method is to produce a piece of data, will send a piece, Use the stream pattern instead of the cache pattern.

As a result, version 1.1 makes it possible to skip the Content-Length field and instead use chunked Transfer Encoding, as long as the transfer-Encoding field in the request or response header indicates that the response will consist of an undetermined number of data blocks.

Transfer-Encoding: chunked
Copy the code

Each non-empty chunk of data is preceded by a hexadecimal value indicating the length of the chunk, followed by a chunk of size 0 indicating that the data for the response has been sent.

Problems with long connections

Although HTTP1.1 version allows reuse a TCP connection, but the same TCP connection, all of the data communication is carried out in accordance with the order, so the server only processed a response, will go to the next response, particularly if the previous response slowly, later there will be many requests queue waiting, this is called team head block.

How to avoid it?

  1. Reduce the number of requests.
  2. Open multiple persistent connections at the same time.