The state and shutdown of TCP connections and their impact on server and client

The state and shutdown of TCP connections and their impact on server and client

1. Status of the TCP connection

let's start by describing the status of the TCP connection during the setup and shutdown process. The TCP connection process is the transformation of the State, and the factors that cause the state to transition include user invocation, specific packets, and timeouts, as shown in the following states:

CLOSED: The initial state, indicating that there is no connection.
a socket on the listen:server side is listening for connection requests from a remote TCP port.
syn_sent: Waits for a confirmation message after sending a connection request. When the client socket makes a connect connection, the SYN packet is sent first, then enters the syn_sent state, and then waits for the server side to send the 2nd packet in the three-time handshake.
syn_received: A connection request is received with a loopback acknowledgment message and a peer connection request, and then waits for confirmation information. This is usually an intermediate state in the three-time handshake process that establishes a TCP connection, indicating that the server-side socket receives a SYN packet from the client and responds.
established: Indicates that the connection has been established and can be transferred.
Fin_wait_1: The party that actively closes the connection waits for the other party to return an ACK packet. If the socket actively shuts down the connection in the established state and sends the FIN packet to the other party (indicating that no data needs to be sent), it enters the fin_wait_1 state, waits for the other party to return the ACK packet, and can then read the data, but cannot send the data. Under normal circumstances, regardless of the other party in what state, should immediately return the ACK packet, so the fin_wait_1 state is generally difficult to see.
Fin_wait_2: The party that actively closes the connection receives the ACK packet returned by the other party and waits for the other party to send the FIN package. When the socket in the FIN_WAIT_1 state receives the ACK packet returned by the other party, it enters the fin_wait_2 state. Because the socket in the fin_wait_2 state needs to wait for each other to send the FIN packet, all is often seen. If you receive a packet with fin and ACK at the same time in the Fin_wait_1 state, you will go directly to the TIME_WAIT state without going through the fin_wait_2 state.
Time_wait: The party that actively closes the connection receives an ACK packet after receiving the FIN packet sent by the other side (indicating that the other party also no longer has data to send, and cannot read or send the data thereafter), Then wait long enough (2MSL) to ensure that the other party receives the ACK packet (taking into account the potential of the missing ACK packet and the impact of the stray packet), and finally returns to the closed state, releasing the network resources.
close_wait: Indicates that the side of the passive shutdown connection is waiting to close the connection. After receiving the fin packet sent by the other party (indicating that the other party no longer has data to send), the corresponding return ACK packet, and then enter the Close_wait state. In this state, if your own data is not sent, you can continue to send to the other side, but no longer read the data until the data is sent.
Last_ack: The side of a passive closed connection can send a FIN packet to the other party after the data has been sent in the Close_wait state (indicating that it no longer has data to be sent), and then waits for the other party to return an ACK packet. When the ACK packet is received, it returns to the closed state, releasing network resources.
CLOSING: A rare exception state. Under normal circumstances, send fin packets should be received (or received) the other party's ACK packet, and then received the other side of the fin package, and the closing status indicates that after sending fin packet and did not receive the other's ACK package, but has received the other side's fin package. There are two situations that can lead to this state: first, if both sides close the connection at the same time, it is possible for both sides to send fin packets simultaneously, and if the ACK packet is lost and the other's fin packet is sent out quickly, the fin will arrive before the ACK.
The state transitions for TCP connections are as shown

2. How TCP connections are closed

establishing a TCP connection requires three handshakes, while closing the connection requires four handshakes and is divided into active and passive shut down. This is because the TCP connection is full, and I close your connection and it doesn't mean that you shut down my connection, so both sides must shut down separately. When a party completes its data sending task, it can send fin packets to terminate the connection in this direction, indicating that no data needs to be sent; the party receiving the fin package cannot read the data again, but can still send the data. Take the client active shutdown connection as an example:

The client sends a FIN packet to the server, indicating that the client actively closes the connection and then enters the fin_wait_1 state, waiting for the server to return an ACK packet. After that, the client cannot send data to the server, but can read the data.
after the server receives the fin packet, it sends an ACK packet to the client and then enters the close_wait state, after which the server cannot read the data again, but can continue to send data to the client. After the client receives the ACK packet returned by the server, it enters the fin_wait_2 state, waiting for the server to send fin packets.
after the server finishes sending the data, the fin packets is sent to the client, then enters the Last_ack state, waits for the client to return the ACK packet, and the server cannot read the data or send the data.
after the client receives the FIN packet, it sends an ACK packet to the server, then enters the time_wait state, Waits long enough (2MSL) to ensure that the server receives the ACK packet, and finally returns to the closed state, releasing the network resource. When the server receives the ACK packet returned by the client, it returns to the closed state and frees the network resources.
TCP connections are set up to shutdown and need to undergo the following state migrations (assuming the client initiates the connection and actively shuts down the connection):

Client
Fin_wait_2, time_wait, fin_wait_1, established, Syn_sent, CLOSED ,

Server
Close_wait, Last_ack, established, syn_received, LISTEN, Clodes ,

3. Impact on server and client

after a detailed understanding of the status and shutdown of the TCP connection, we will find that the TIME_WAIT state is a pit-daddy presence! The party that actively closes the connection will enter the TIME_WAIT state after sending the last ACK packet, waiting for 2MSL time before the network resource can be freed, regardless of whether the other party receives it. The MSL is the maximum Segment Lifetime (the maximum lifetime of a packet), which is the longest time a packet can survive on the Internet, and the packet will disappear in the network if it exceeds that time. The operating system typically sets 2MSL to 4 minutes, at least 30 seconds, so the time_wait state is generally maintained at 30 seconds to 4 minutes. This is the TCP/IP protocol is necessary, is designed by the TCP/IP designer, that is, unable to solve. There are two main reasons for the existence of the TIME_WAIT state:

the termination of a TCP full-duplex connection is reliably implemented. When closing a TCP closed connection, the final ACK packet is issued by the active shut-down party, and if the ACK packet is lost, the passive shutdown will re-send the fin packet, so the active party must maintain the status information to allow it to re-send the ACK packet. If this status information is not maintained, then the active party will return to the closed state and respond to the RST packet to the passive side of the fin packet, while the passive shut-down party interprets the package as an error (the socketexception in Java will be thrown connection reset). Therefore, to realize the normal termination of TCP full-duplex connection, it must be able to handle the loss of any packet in the four handshake protocol, the active shutdown must maintain the state information into the TIME_WAIT state.
Make sure that the stray packets disappear in the network, preventing the packets in the last connection from getting lost and re-appearing, affecting the new connection. TCP packets may be lost due to router anomalies, during the lost, the packet sender may resend the packet due to timeouts, the lost packets will be sent to the destination after the router is restored, the lost packet is called lost Duplicate. After shutting down a TCP connection, if a new TCP connection is established using the same IP address and port immediately, it is possible that the previous connection's stray packets will reappear after the previous connection is closed, affecting the newly established connection. To avoid this situation, the TCP protocol does not allow the use of a connection's IP and port in the TIME_WAIT state to initiate a new connection, and only after 2MSL of time, to ensure that all stray packets in the last connection have disappeared in the network before a new connection can be established securely.
for the client, each connection needs to occupy one port, and the system allows less than 65,000 available ports (which can be achieved after TCP parameter optimization). Therefore, if the client initiates excessive connections and actively shuts down (assuming no ports are being reused or connecting multiple servers), there will be a large number of connections in the TIME_WAIT state after shutting down, waiting for 2MSL of time before releasing network resources (including ports). The client will not be able to create a new connection due to a lack of available ports.

for server (especially for servers with high concurrent short connections), server-side connections to client are using the same port, which is the listening port, each connection is differentiated by a five-tuple, including the source IP address, the source port, the Transport Layer Protocol number (protocol type), Destination IP address, destination port, so theoretically, the server is not limited by the number of system ports. However, the server has a limit on the number of connections on each port, and it uses a hash table to record each connection on the port and is limited by the maximum number of open file descriptors. Therefore, if the server actively shuts down the connection, there will also be a large number of connections in the TIME_WAIT state after shutting down, waiting for 2MSL of time before releasing network resources (including connection records and file descriptors on the hash table). As a result, the server will not be able to accept new connections due to the limitations of the hash table and file descriptors, resulting in a sharp decline in performance, which will continue to cause severe fluctuations. There are three ways to respond to this situation:

attempts to have the client actively shut down the connection, because the concurrency of each client is relatively low, resulting in no performance bottleneck.
optimizes the server's system TCP parameters to balance its network resource maximum, consumption speed, and recovery speed.
rewriting the TCP protocol and re-implementing the underlying code is difficult, and the stability and security of the system can be compromised.

The state and shutdown of TCP connections and their impact on server and client