HTTP persistent connection and short connection

1. Relationship between HTTP protocol and TCP/IP protocol

HTTP persistent connections and short connections are essentially TCP persistent connections and short connections. HTTP is an application layer protocol. TCP is used at the transport layer and IP is used at the network layer. The IP protocol mainly solves the problem of network routing and addressing. The TCP protocol mainly solves how to transmit packets reliably on the IP layer, so that the other end of the network receives all packets from the initiator, and the order is the same as the sending order. TCP is reliable and connection-oriented.

 

2. How to understand that HTTP is stateless

The HTTP protocol is stateless, which means the Protocol has no memory for transaction processing and the server does not know what the client is in. That is to say, there is no connection between opening a webpage on a server and the webpage on the server you opened before. HTTP is a stateless connection-oriented protocol. Stateless does not mean that HTTP cannot maintain a TCP connection, nor does it mean that HTTP uses a UDP Protocol (No connection ).

 

3. What are persistent connections and short connections?

In HTTP/1.0, transient connections are used by default. That is to say, the browser and the server establish a connection every time they perform an HTTP operation, but the connection is interrupted when the task ends. If an HTML or other web page accessed by the client browser contains other web resources, such as JavaScript files, image files, and CSS files, each time the browser encounters such a web resource, an HTTP session is created.

However, from HTTP/1.1, persistent connections are used by default to maintain the connection feature. With the persistent connection HTTP protocol, this line of code is added to the response header:

Connection:keep-alive

When a persistent connection is used, after a webpage is opened, the TCP connection used to transmit HTTP data between the client and the server is not closed. If the client accesses the webpage on the server again, will continue to use this established connection. Keep-alive does not keep the connection permanently. It has a retention time, which can be set in different server software (such as APACHE. To achieve persistent connection, both the client and the server support persistent connections.

HTTP persistent connections and short connections are essentially TCP persistent connections and short connections.

3.1 TCP Connection

When the TCP protocol is used for network communication, a connection must be established between the server and the client before the real read/write operations. After the read/write operations are complete, when the two sides no longer need the connection, they can release the connection. The connection establishment requires three handshakes, And the release requires four handshakes, therefore, the establishment of each connection requires resource consumption and time consumption.

Classic three-way handshake:

The classic four-way handshake closure diagram:

3.2 TCPTransient connection

Let's simulate a short TCP connection. The client initiates a connection request to the server. The server receives the request and establishes a connection between the two parties. When the client sends a message to the server, the server responds to the client and then completes the read/write operation. At this time, either party can initiate the close operation, but generally the client initiates the close operation first. Why? Generally, the server will not close the connection immediately after replying to the client. Of course, there are special cases that cannot be ruled out. As described above, short connections generally only pass one read/write operation between the client and server.

The advantage of transient connection is that it is relatively simple to manage, and existing connections are useful connections without additional control measures.

3.3 TCPPersistent connection

Next, we will simulate the persistent connection. The client initiates a connection to the server, the server accepts the client connection, and both parties establish a connection. After a read/write operation is completed between the client and the server, the connection is not closed. Subsequent read/write operations will continue to use this connection.

First, let's talk about the TCP retention function described in the TCP/IP explanation. The retention function is mainly provided for server applications. The server application wants to know whether the client host crashes and thus can use resources on behalf of the customer. If the customer has disappeared, so that a semi-open connection is retained on the server, and the server is waiting for data from the client, the server will be far away waiting for data from the client, the alive function is to detect this semi-open connection on the server side.

If a given connection does not take any action within two hours, the server sends a detection packet segment to the customer. The customer's host must be in one of the following four States:

1. The client host still runs normally and is accessible from the server. The customer's TCP response is normal, and the server knows that the other party is normal. The server resets the active timer after two hours.
2. The client host has crashed and is disabled or is restarting. In any case, the customer's TCP does not respond. The server will not be able to receive a response to the test and time out after 75 seconds. The server sends a total of 10 such probes, with each interval of 75 seconds. If the server does not receive a response, it determines that the client host has been closed and the connection is terminated.
3. The client host crashes and has been restarted. The server will receive a response to its active detection. This response is a reset that causes the server to terminate the connection.
4. The client runs normally, but the server is not reachable. This is similar to 2. What TCP can find is that it has not received the probe response.

 

4. Advantages and Disadvantages of persistent connections and short connections

As can be seen from the above, long connections can save a lot of TCP establishment and closure operations, reduce waste and save time. For customers who frequently request resources, persistent connections are more suitable. However, there is a problem here. The probe cycle of the survival function is too long, and it is only used to detect the survival of TCP connections. It is a relatively simple practice in the case of malicious connections, the retention function is not enough. In persistent connection scenarios, the client generally does not take the initiative to close the connection between them. If the connection between the client and the server is never closed, there will be a problem, as the number of client connections increases, the server may not be able to cope with it sooner or later. At this time, the server needs to adopt some policies, such as closing connections that have not been read or written for a long time, in this way, some malicious connections can prevent server-side service losses. if conditions permit, you can use the client machine as the granularity to limit the maximum number of persistent connections of each client, this completely prevents a client from getting tired of backend services.

Short connections are relatively simple for servers. Existing connections are useful connections without additional control measures. However, if the customer requests frequently, it will waste time and bandwidth on the establishment and closure of TCP.

Persistent connections and short connections are generated by the closing policies adopted by the client and server. Specific policies are used in specific application scenarios. There is no perfect choice but a proper choice.

(To) HTTP persistent connections and short connections