TCP Four-Way Handshake and TIME_WAIT State

TCP Four-Way Handshake and TIME_WAIT State

Description
The TCP four-way handshake is the process used for the normal termination of a TCP connection, involving the exchange of four specific packets (FIN and ACK) between a client and a server. Corresponding to the "three-way handshake" for connection establishment, terminating a connection typically requires four steps, hence the name "four-way handshake." A key but often misunderstood state in this process is the TIME_WAIT state. Understanding the steps of the four-way handshake and the role of the TIME_WAIT state is crucial for diagnosing network connection issues, developing high-performance network applications, and defending against related attacks (such as connection depletion attacks).

Analysis Process

We will break down the four-way handshake step by step and delve into the TIME_WAIT state.

  1. Connection Termination Initiation

    • Description: Assume a TCP connection is already established, and the communicating parties are referred to as "client" and "server." When one party (e.g., the client that has finished sending data) decides to close the connection, it initiates the termination process.
    • Action: The client sends a close command to its TCP stack (e.g., calling socket.close() in programming). Subsequently, the client's TCP protocol stack constructs a TCP packet with the FIN flag in the header set to 1 (FIN stands for "Finish," indicating the sender has no more data to send). This packet also contains a sequence number (Sequence Number, assumed to be u), which is the sequence number of the last data byte from previous communication plus 1.
    • State Change: After sending this FIN packet, the client's state changes from the stable connection state (ESTABLISHED) to FIN_WAIT_1. This means the client is waiting for the other party to acknowledge its FIN request.

  2. Server Acknowledges the FIN

    • Description: Upon receiving the FIN packet from the client, the server understands that the client wishes to close the connection.
    • Action: The server must acknowledge this. It sends an acknowledgment (ACK) packet. The acknowledgment number (Acknowledgment Number) of this ACK packet is set to the received FIN packet's sequence number plus 1, i.e., u+1. This indicates the server has successfully received all data up to sequence number u (including this FIN, which consumes a sequence number).
    • State Change:
      • Upon receiving this ACK, the client knows its close request has been acknowledged by the server. The client's state thus changes from FIN_WAIT_1 to FIN_WAIT_2. At this point, the connection from the client to the server is half-closed; the client can no longer send data but can still receive data from the server.
      • The server's state changes from ESTABLISHED to CLOSE_WAIT. This indicates the server is aware the client wants to close and is waiting for its own application to close the connection.

  3. Server Sends FIN Packet

    • Description: After the server-side application finishes sending data, it also decides to close the connection.
    • Action: The server-side TCP stack constructs its own FIN packet, with a sequence number (assumed to be w) based on the data stream it previously sent. This packet is sent to the client.
    • State Change: After sending the FIN packet, the server's state changes from CLOSE_WAIT to LAST_ACK. This means the server has issued its own termination request and is waiting for the final acknowledgment.

  4. Client Acknowledges the Server's FIN

    • Description: The client receives the FIN packet from the server.
    • Action: The client must send an acknowledgment (ACK) packet with an acknowledgment number of w+1.
    • State Change:
      • Upon receiving this ACK, the server considers the connection normally closed. The server's state changes from LAST_ACK to CLOSED (initial state).
      • The key point is here: After sending the final ACK, the client does not immediately enter the CLOSED state. Instead, it enters a state called TIME_WAIT.

  5. In-depth Understanding of the TIME_WAIT State

    • What it is: TIME_WAIT is also known as the 2MSL wait state. MSL stands for "Maximum Segment Lifetime," the maximum time a TCP packet can exist in the network before being discarded. The duration of TIME_WAIT is typically twice the MSL. In modern operating systems, this value is often 30 seconds, 60 seconds, or 120 seconds.
    • Why it is needed (two core purposes):
      • Reliable Connection Termination: The final ACK packet sent by the client might get lost in the network. If the server does not receive this ACK, it will assume its FIN packet was lost and retransmit the FIN packet. If the client directly entered the CLOSED state after sending the ACK and reused the same port to establish a new connection, a delayed FIN packet from the previous connection arriving later might be mistakenly interpreted as a termination signal for the new connection, incorrectly closing the new connection. A client in the TIME_WAIT state, if it receives a retransmitted FIN packet, will resend the ACK, ensuring the connection is safely and reliably terminated.
      • Allowing Old Connection Packets to Expire in the Network: During the 2MSL wait time, all delayed packets belonging to this recently closed connection will time out and disappear from the network. This ensures that these old, delayed packets do not cause confusion with future new connections that reuse the same quadruple (source IP, source port, destination IP, destination port).

Summary
The TCP four-way handshake is a carefully designed, reliable connection termination mechanism. The TIME_WAIT state is an integral part of it. Although it temporarily occupies system port resources (potentially causing "port exhaustion" issues in high-concurrency servers), its primary goal is to ensure the reliability of the TCP protocol. When designing and optimizing network services, it is necessary to understand and properly handle the TIME_WAIT state, rather than simply attempting to bypass it.