Is HTTP1.1 Keep-Alive considered a long connection?

[[435412]]

This article will talk about the colloquial term "long connection, short connection". The article will be described according to the following mind map:

The focus is on organizing the knowledge system around these two difficulties/misunderstandings.

• Long connection vs short connection
• Http1.1 persistent connection vs WebSocket persistent connection

Long connection vs short connection

A long connection refers to sending multiple data packets continuously on a connection.

A short connection means that when two parties want to exchange data, a connection is established. When the data is sent, the connection is disconnected. That is, each connection only completes one unit of business transmission, and a new connection is established to transmit data if necessary.

In fact, both long and short connections refer to TCP connections, emphasizing the application layer's use of the underlying TCP connection. The application decides which connection to use based on its own circumstances.

Long connections are mostly used for frequent operations, point-to-point communication, and the number of connections cannot be too large. Each TCP connection requires a three-way handshake, which takes time. If each operation is a short connection, the processing speed will be much lower. Therefore, it is not disconnected after each operation. The next time the data packet is processed, it is OK to send it directly without establishing a TCP connection. For example: the database connection uses a long connection. If short connections are used for frequent communication, socket errors will occur, and frequent socket creation is also a waste of resources.

Conventional web sites generally use short connections, which is determined by the characteristics of the web site. The number of clients on the web site is large and the access time/frequency is not fixed. Using short connections can save server resources. If the clients all maintain long connections, it is conceivable how much server resources will be occupied. Therefore, the concurrency is large, but it is better to use short connections when each user does not need to operate frequently.

HTTP1.1 Persistent Connection

Early HTTP 1.0 was a pure TCP short connection application. Each connection completed an HTTP request/response model. This frequent creation/destruction of connections undoubtedly resulted in certain performance losses.

The Keep-alive of HTTP1.1, which is currently widely used, is officially called a persistent connection (English: HTTP persistent connection, also known as HTTP connection reuse), and is colloquially called "HTTP long connection" in China.

HTTP1.1keep-alive, I think it is a compromise between the application layer HTTP protocol and the TCP connection, and it is the multiplexing negotiation of the application layer for the lower layer TCP connection.

Http1.0's frequent creation/destruction of connections does indeed bring unnecessary performance loss to both parties in communication#Unnecessary#

Directly using a typical long connection will put a lot of pressure on the server. #Not allowed#

Therefore, HTTP1.1's keep-alive allows multiple HTTP requests to reuse a TCP connection, and on the other hand, leaves the reuse period to the client/server to negotiate at the application layer: each request/response at the application layer carries a Connection: Keep-Alive header for sliding renewal.

The essence of HTTP 1.1 Keep-Alive is the application layer sliding renewal and multiplexing of TCP connections?

Let's recall that all common clients/servers have parameters such as KeepAliveTImeout.

• The default KeepAliveTimeout of client IE is 1 minute[1];
• The default ConnectionTimeout duration of the IIS server is 2 minutes[2]
• Server ASP.NetCore Kestrel default KeepAliveTimeout=130s[3]
• Server nginx default keepalive_timeout=60s[4]

These parameters all prove that HTTP Keep-Alive is a sliding renewal multiplexing of TCP connections.

Anyone with a discerning eye can see that the sliding timeout for TCP Connection reuse in 1.2.4 was decided on the spur of the moment. The reason why the sliding timeout for ASP.NET Core Kestrel as a .NETCore hosting server is 130s is quite interesting. I will find out the relevant information for you: KestrelServerLimits.KeepAliveTimeout=130s[5]

Typical long connection Websocket

Websocket is a typical long connection. After the TCP connection is established through the first HTTP Request, there is no need to send HTTP Request for data interaction. However, exchanging data without sending HTTP header is obviously different from the original HTTP protocol, so it requires upgrading both the server and the client to achieve it. This negotiation is completed before Websocket data transmission: when the TCP connection is established through the initial HTTP, the Upgrade header is carried to notify both parties to upgrade the protocol.

Websocket also has a Keepalive mechanism. The function of Websocket's Keepalive is to detect whether the connected peer is still alive in a complex network environment.

Narration Summary

Both long and short connections refer to TCP connections, emphasizing the application layer's usage of TCP connections.

HTTP1.1 Keep-alive is a compromise for TCP connections. It is neither a short connection nor a typical long connection.

HTTP1.1 Keep-alive is officially called persistent connection. My opinion is that HTTP1.1 Keep-Alive is a sliding renewal and reuse of TCP connections at the application layer.

A typical long-connection Websocket completes the long-connection confirmation before data transmission.