The difference between a long TCP connection and a short connection

The difference between a long TCP connection and a short connection

 

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 and write operations. When the read and write operations are completed, the two parties can release the connection when they no longer need the connection. It requires three handshakes, and the release requires four handshakes, so the establishment of each connection requires resource consumption and time consumption

Classic three-way handshake diagram:

The classic four-way handshake closing diagram:

2. TCP short connection

Let's simulate the situation of a short TCP connection. The client initiates a connection request to the server, the server receives the request, and then the two parties establish a connection. The client sends a message to the server, the server responds to the client, and then a read and write is completed. At this time, either side can initiate a close operation, but generally the client initiates the close operation first. Why, the general server will not close the connection immediately after replying to the client, of course, there are special cases. From the above description, short connections generally only pass one read and write operation between client/server

The advantage of a short connection is that it is simpler to manage, the existing connections are all useful connections, and no additional control means are required.

3. TCP long connection

Next, let's simulate the situation of a long connection. The client initiates a connection to the server, the server accepts the client connection, and the two parties establish a connection. After the client and server complete a read and write, the connection between them will not be actively closed, and subsequent read and write operations will continue to use this connection.

First of all, let's talk about the TCP keep-alive function mentioned in the TCP/IP detailed explanation. The keep-alive function is mainly provided for server applications. The server application wants to know whether the client host crashes, so that it can use resources on behalf of the client. If the client has disappeared, leaving a half-open connection on the server, and the server is waiting for data from the client, the server should be far away from waiting for the client's data, the keep-alive function is to try to detect this half-open on the server side connect.

If there is no action on a given connection for two hours, the server sends a probe segment to the client, and the client host must be in one of the following four states:

  1. The client host is still running and reachable from the server. The client's TCP response is normal, and the server knows that the other party is normal. The server resets the keep-alive timer two hours later.
  2. The client host has crashed and is shutting down or being restarted. In either case, the client's TCP did not respond. The server will not receive a response to the probe and will time out after 75 seconds. The server sends a total of 10 such probes, each at 75 second intervals. If the server does not receive a response, it considers the client host closed and terminates the connection.
  3. The client host crashed and has been restarted. The server will receive a response to its keepalive probe, which is a reset, causing the server to terminate the connection.
  4. The client is running normally, but the server is unreachable. This situation is similar to 2. All TCP can find is that no response to the probe is received.

As can be seen from the above, the TCP keep-alive function is mainly to detect the survival status of long connections, but there is a problem here, the detection period of the keep-alive function is too long, and it only detects the survival of TCP connections, which is a relatively gentle approach. Keep-alive is not enough when encountering malicious connections.

In the application scenario of long connection, the client generally does not actively close the connection between them. If the connection between the client and the server is not closed, there will be a problem. As the number of client connections increases, the server Sooner or later, the server side needs to adopt some strategies, such as closing some connections that have not read and written events for a long time, so as to avoid some malicious connections that cause damage to the server side service; if conditions allow, you can use The client machine is granular, and the maximum number of long connections per client is limited, which can completely avoid a troublesome client from affecting the backend service.

The generation of long connections and short connections lies in the closing strategy adopted by the client and server. Specific application scenarios adopt specific strategies. There is no perfect choice, only suitable choices.

refer to:

1. TCP/IP Detailed Explanation Volume 1

Reprinted from:  http://www.cnblogs.com/beifei/archive/2011/06/26/2090611.html

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326316169&siteId=291194637