TCP connection status and closing mode and Their Impact on Server and Client

The status and closing method of TCP connections and their impact on the Server and Client 1. The status of TCP connections first describes the status during the establishment and closure of TCP connections. The TCP connection process is a state conversion. The factors that enable the State Conversion include user calls, specific data packets, and timeout. The specific status is as follows: CLOSED: initial status, indicating no connection. LISTEN: A Socket on the Server is listening for connection requests from a remote TCP port. SYN_SENT: wait for confirmation after sending the connection request. When the client Socket performs a Connect connection, it first sends the SYN packet, then enters the SYN_SENT state, and then waits for the Server to send the 2nd packets in the three-way handshake. SYN_RECEIVED: After receiving a connection request, send back the confirmation message and the peer connection request, and wait for the confirmation message. It is usually an intermediate state in the three-way handshake process of establishing a TCP connection, indicating that the Server Socket receives the SYN packet from the Client and responds. ESTABLISHED: indicates that the connection has been ESTABLISHED and data transmission can be performed. FIN_WAIT_1: The party that proactively closes the connection waits for the other party to return the ACK packet. If the Socket closes the connection in the ESTABLISHED State and sends a FIN packet to the other party (indicating that the other party no longer needs to send data), it enters the FIN_WAIT_1 state and waits for the other party to return the ACK packet, data can be read later, but data cannot be sent. Under normal circumstances, the ACK packet should be returned immediately regardless of the other Party's status, so the FIN_WAIT_1 status is generally difficult to see. FIN_WAIT_2: The party that closes the connection actively receives the ACK packet from the other party and waits for the other party to send the FIN packet. When the Socket in the FIN_WAIT_1 status receives the ACK packet returned by the other party, it enters the FIN_WAIT_2 status. Because the Socket in the FIN_WAIT_2 State needs to wait for the FIN packet sent by the other party, it is often seen. If the FIN_WAIT_1 status receives a packet with both FIN and ACK sent by the other party, it directly enters the TIME_WAIT status without passing through the FIN_WAIT_2 status. TIME_WAIT: The party that closes the connection actively receives the FIN packet sent by the other party and returns the ACK packet (indicating that the other party no longer has data to send and cannot read or send data later ), then wait for a long enough time (2MSL) to ensure that the other party receives the ACK packet (considering the possibility of losing the ACK packet and the impact of lost and repeated packets), and finally return to the CLOSED status to release network resources. CLOSE_WAIT: The party that passively closes the 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 ACK packet is returned and enters the CLOSE_WAIT status. In this status, if you still have data that has not been sent, you can continue to send data to the other party, but you cannot read the data until the data has been sent. LAST_ACK: The party that passively closes the connection can send a FIN packet to the other party after the data is sent in the CLOSE_WAIT state (indicating that the other party no longer needs to send data), and then waits for the other party to return the ACK packet. After receiving the ACK package, the system returns to the CLOSED status to release network resources. CLOSING: a rare exception. Under normal circumstances, after sending a FIN packet, you should first receive (or simultaneously receive) the ACK packet from the other party, and then receive the FIN packet from the other party, the CLOSING status indicates that the FIN packet has not received the ACK packet of the other party, but has received the FIN packet of the other party. There are two possible causes: first, if the two sides close the connection almost simultaneously, the two sides may send the FIN package at the same time; second, if the ACK package is lost and the other's FIN package is quickly released, the FIN will arrive before the ACK. Shows the status transition of TCP connections.
2. the TCP connection closing method requires three handshakes to establish a TCP connection, and the closing method requires four handshakes, which are divided into active and passive shutdowns. This is because the TCP connection is full-duplex. If I close your connection, it does not mean that you close my connection. Therefore, both parties must close it separately. After one party completes its data sending task, it can send a FIN packet to terminate the connection in this direction, indicating that it no longer has data to be sent. The party that receives the FIN packet cannot read the data, however, data can still be sent. Take the Client's active disconnection as an example: the Client sends a FIN package to the Server, indicating that the Client closes the connection and enters the FIN_WAIT_1 status, waiting for the Server to return the ACK package. After that, the Client can no longer send data to the Server, but can read the data. After receiving the FIN package, the Server sends an ACK package to the Client and enters the CLOSE_WAIT status. After that, the Server can continue to send data to the Client. After receiving the ACK packet returned by the Server, the Client enters the FIN_WAIT_2 status and waits for the Server to send the FIN packet. After the Server sends the data, it sends the FIN package to the Client and enters the LAST_ACK status. Wait until the Client returns the ACK package. After that, the Server cannot read or send data. After receiving the FIN package, the Client sends the ACK package to the Server and enters the TIME_WAIT status. Then, wait for a long enough time (2MSL) to ensure that the Server receives the ACK package and returns to the CLOSED status, release network resources. After receiving the ACK packet returned by the Client, the Server returns to the CLOSED status to release network resources. When a TCP connection is established or closed, it needs to be migrated in the following status (assuming that the Client initiates a connection and closes the connection actively ): client CLOSED-> SYN_SENT-> ESTABLISHED-> FIN_WAIT_1-> FIN_WAIT_2-> TIME_WAIT-> CLOSED Server CLODES-> LISTEN-> SYN_RECEIVED-> CLOSED-> LAST_ACK-> CLOSED 3. the impact on the Server and Client after a detailed understanding of the TCP connection status and closing method, we will find that the TIME_WAIT status is a pitfall! After the last ACK packet is sent, the connected party automatically closes the connection and enters the TIME_WAIT status no matter whether the other party receives the packet or not. The network resources can be released only after 2MSL is received. MSL is Maximum Segment Lifetime (the Maximum life cycle of a data packet). It is the longest time for a data packet to survive on the Internet. If it exceeds this time, the data packet will disappear in the network. Generally, the operating system sets 2MSL to 4 minutes, and the minimum is not less than 30 seconds. Therefore, the TIME_WAIT status is generally between 30 seconds and 4 minutes. This Protocol is indispensable for TCP/IP. It is designed by TCP/IP designers and cannot be solved. There are two main reasons for the TIME_WAIT status: reliable termination of TCP full-duplex connection. When closing the TCP closed connection, the final ACK packet is sent by the active closing party. If this ACK packet is lost, the passive closing party resends the FIN packet, therefore, the active party must maintain the status information to allow it to resend the ACK package. If this status information is not maintained, the active party will return to the CLOSED status and respond to the RST packet for the FIN packet resending by the passive party, the passive close will interpret this package as an error (SocketException of connection reset will be thrown in Java ). Therefore, to terminate a TCP full-duplex connection, you must be able to handle the loss of any packet in the four-way handshake protocol. The active closing party must maintain the status information and enter the TIME_WAIT status. Make sure that the lost and repeated data packets disappear in the network to prevent the previous connection packet from appearing again after it is lost, affecting the new connection. The TCP packet may be lost due to a router exception. During the lost period, the packet sender may resend the packet due to timeout. The lost packet will also be sent to the destination after the router recovers, this Lost packet is called Lost Duplicate. After a TCP connection is closed, if the same IP address and port are used to establish a new TCP connection, the lost and repeated data packets of the previous connection may appear again after the previous connection is closed, affects new connections. To avoid this problem, the TCP protocol does not allow the IP address and port of the connection in the TIME_WAIT status to start a new connection, only after 2MSL time, make sure that all the lost and repeated data packets in the last connection have been lost in the network. In this way, a new connection can be established securely. For the Client, each connection occupies one port, and the number of available ports allowed by the system is less than 65000 (this is achieved after the TCP Parameter is optimized ). Therefore, if the Client initiates too many connections and closes them actively (assuming there are no reuse ports or connections to multiple servers), a large number of connections are in the TIME_WAIT status after they are closed, wait for 2MSL to release network resources (including ports). Therefore, the Client cannot create a new connection because of the lack of available ports. For the Server (especially the Server that processes high-concurrency short connections), the connection established between the Server and the Client uses the same port, that is, the listening port, each connection is divided by a quintuple, including the source IP address, source port, Transport Layer Protocol Number (protocol type), destination IP address, and destination port. Therefore, theoretically, server is not limited by the number of system ports. However, the Server limits the number of connections on each port. It uses a hash table to record each connection on the port and is limited by the maximum number of opened file descriptors. Therefore, if the Server closes the connection, a large number of connections are in the TIME_WAIT status after the connection is closed, the network resources (including the connection records and file descriptors in the hash table) can be released only after 2MSL. Therefore, the Server cannot accept new connections due to the limitation of the hash table and file descriptor, this causes a sharp decline in performance, and the performance curve will continue to produce serious fluctuations. There are three ways to cope with this situation: Try to enable the Client to actively close the connection, because the concurrency of each Client is relatively low, so there is no performance bottleneck. Optimize the system TCP Parameters of the Server to balance the maximum value, consumption speed, and recovery speed of its network resources. Rewrite the TCP protocol and re-implement the underlying Code. However, this method is very difficult and the system stability and security may be affected.