Byte One: Is there any difference between HTTP long connection and TCP long connection?

Hello everyone, I am Xiaolin.

A reader sent me a private message before. During his interview at ByteDance, he was asked these two questions:

The first question: How is MySQL's NULL value stored?

Second question: What is the difference between HTTP persistent connection and TCP persistent connection?

The first question is mainly to test whether you know how a record is stored in MySQL. I have written an article to explain it a few days ago. If you haven't read it yet, you can read this article: Byte-wise: How is the MySQL NULL value stored?

The second question is actually asking what is the difference between HTTP's Keep-Alive and TCP's Keepalive?

This is a good question. I think many people will confuse them because these two things look so similar that they can easily be mistaken for the same thing.

If you have carefully read the series of articles on illustrated networks on my website, you should know the answer to this question because I have written about it before.

However, there may be many students who have forgotten what they read, so this time I will take you to review it again.

In fact, these two are completely different things, and the implementation levels are also different:

• HTTP Keep-Alive is implemented by the application layer (user mode) and is called HTTP long connection;
• TCP's Keepalive is implemented by the TCP layer (kernel mode) and is called the TCP keepalive mechanism;

Next, let’s talk about them one by one.

HTTP Keep-Alive

The HTTP protocol uses a "request-response" model, that is, the client initiates a request and the server returns a response, back and forth.

Request-Response

Since HTTP is implemented based on the TCP transport protocol, before the client and server can communicate via HTTP, they need to establish a TCP connection first. The client then sends an HTTP request, and the server returns a response after receiving it. At this point, the "request-response" mode is completed, and the TCP connection is then released.

An HTTP request

If each request goes through the following process: establish TCP -> request resource -> respond to resource -> release connection, then this method is HTTP short connection, as shown in the following figure:

HTTP short connection

This is really tiring, as a resource can only be requested once per connection.

Is it possible to keep the TCP connection open after the first HTTP request is completed, so that subsequent HTTP requests can continue to use this connection?

Of course you can. HTTP's Keep-Alive implements this function. You can use the same TCP connection to send and receive multiple HTTP requests/responses, avoiding the overhead of connection establishment and release. This method is called HTTP long connection.

HTTP persistent connection

The characteristic of HTTP long connection is that the TCP connection state is maintained as long as either end does not explicitly request to disconnect.

How can I use the Keep-Alive feature of HTTP?

In HTTP 1.0, it is disabled by default. If the browser wants to enable Keep-Alive, it must be added to the request header:

 Connection : Keep - Alive

Then when the server receives the request and responds, it also adds a header to the response:

 Connection : Keep - Alive

By doing this, the connection is not disconnected but remains connected. When the client sends another request, it uses the same connection. This continues until the client or server asks to disconnect.

Since HTTP 1.1, Keep-Alive has been enabled by default. If you want to disable Keep-Alive, you need to add the following to the HTTP request header:

 Connection : close

Most browsers now use HTTP/1.1 by default, so Keep-Alive is turned on by default. Once the client and server reach an agreement, the persistent connection is established.

HTTP long connection not only reduces the overhead of TCP connection resources, but also provides a feasible basis for HTTP pipelining technology.

The so-called HTTP pipelining means that the client can send multiple requests at once without waiting for the server's response during the sending process, which can reduce the overall response time.

For example, a client needs to request two resources. In the past, in the same TCP connection, the client first sent request A, then waited for the server to respond, and then sent request B after receiving the response. The HTTP pipelining mechanism allows the client to send request A and request B at the same time.

The right side shows the HTTP pipeline mechanism

However, the server still responds in order, responding to request A first, and then responding to request B after completion.

Moreover, the client can only send the next batch of requests after the server responds to the first batch of requests sent by the client. In other words, if the server response process is blocked, the client will not be able to send the next batch of requests, which will cause the problem of "head of line blocking".

Some students may ask, if HTTP long connection is used, if the client does not initiate a new request after completing an HTTP request, then this TCP connection is always occupied, isn’t it a waste of resources?

That's right. In order to avoid wasting resources, web service software generally provides a keepalive_timeout parameter to specify the timeout period of HTTP long connections.

For example, if the timeout of HTTP long connection is set to 60 seconds, the web service software will start a timer. If the client does not initiate a new request within 60 seconds after completing the last HTTP request, the callback function will be triggered to release the connection when the timer expires.

HTTP long connection timeout

TCP Keepalive

TCP's Keepalive is actually TCP's keep-alive mechanism. I have written about its working principle in my previous article, so I will just paste the previous content here.

If there is no data exchange between the two ends of the TCP connection, and the conditions for triggering the TCP keep-alive mechanism are met, the TCP protocol stack in the kernel will send a detection message.

• If the peer program is working normally, when the TCP keep-alive detection message is sent to the peer, the peer will respond normally, so the TCP keep-alive time will be reset and wait for the next TCP keep-alive time to arrive.
• If the peer host crashes, or the peer is unreachable due to other reasons, when the TCP keepalive detection message is sent to the peer, but there is no response, after several consecutive keepalive detection times, TCP will report that the TCP connection has died.

Therefore, the TCP keep-alive mechanism can determine whether the other party's TCP connection is alive by detecting messages when there is no data exchange between the two parties. This work is completed in the kernel.

TCP keep-alive mechanism

Note that if an application wants to use the TCP keepalive mechanism, it needs to set the SO_KEEPALIVE option through the socket interface for it to take effect. If it is not set, the TCP keepalive mechanism cannot be used.

Summarize

HTTP's Keep-Alive is also called HTTP long connection. This function is implemented by the "application" and allows the same TCP connection to be used to send and receive multiple HTTP requests/responses, reducing the overhead of multiple TCP connection establishment and release caused by HTTP short connections.

TCP's Keepalive is also called TCP's keep-alive mechanism. This function is implemented by the "kernel". When the client and the server have not exchanged data for a certain period of time, the kernel will send a probe message to detect whether the other party is still online in order to ensure that the connection is still valid, and then decide whether to close the connection.