Differences Between TCP persistent connection and short 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:

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. 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, this semi-open connection is attempted 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.

It can be seen from the above that the TCP active-active function is mainly used to detect the survival status of persistent connections. However, there is a problem here that the probe cycle of the active function is too long, in addition, it only detects the survival of TCP connections. It is a relatively simple practice. In the case of malicious connections, it is not enough to enable the persistence function.

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 be prevented from damaging the server service. If conditions permit, the maximum number of persistent connections of each client can be limited by the granularity of the client machine, this completely prevents a client from getting tired of backend services.

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.