Analysis of TCP Three-Way Handshake and Four-Way Wavehand Process

Analysis of TCP Three-Way Handshake and Four-Way Wavehand Process

Problem Description
TCP (Transmission Control Protocol) is one of the core protocols of the Internet, responsible for providing reliable, connection-oriented byte stream transmission services in an unreliable network environment. Its connection establishment and release processes are achieved through the "three-way handshake" and "four-way wavehand" mechanisms, respectively. Interviews often require a detailed explanation of the steps in these two processes, the content of the data packets transmitted in each step (especially changes in flags and sequence numbers), and why a three-way handshake is needed (instead of two or four) and a four-way wavehand (instead of three).

Step-by-Step Explanation of the Problem-Solving Process

Step 1: Understanding Key Fields in the TCP Header
Before analyzing the handshake and wavehand processes, it is necessary to master several core fields in the TCP header:

  • Sequence Number (seq): Identifies the starting number of the data byte stream sent by the sender, used for data ordering and deduplication.
  • Acknowledgment Number (ack): The next sequence number the receiver expects to receive, its value is the received seq + 1, indicating that the previous data has been correctly received.
  • Flags:
    • SYN: Synchronize flag. Set to 1 to request connection establishment.
    • ACK: Acknowledgment flag. Set to 1 to indicate the acknowledgment number field is valid.
    • FIN: Finish flag. Set to 1 to request connection release.

Step 2: Three-Way Handshake Connection Establishment Process
Assume the client actively initiates a connection to the server:

  1. First Handshake (SYN=1, seq=x)

    • The client sends a TCP segment with the SYN flag set to 1 and a randomly generated initial sequence number (seq=x). No application data is carried at this time.
    • The client enters the SYN-SENT state, waiting for server acknowledgment.
    • Purpose: The client expresses connection intent to the server and synchronizes the initial sequence number.

  2. Second Handshake (SYN=1, ACK=1, seq=y, ack=x+1)

    • After receiving the segment, if the server agrees to connect, it replies with a segment. It sets both SYN and ACK flags to 1, randomly generates the server's initial sequence number (seq=y), and sets the acknowledgment number to the client's sequence number + 1 (ack=x+1).
    • The server enters the SYN-RECEIVED state.
    • Purpose: The server acknowledges the client's connection request and simultaneously synchronizes its own initial sequence number.

  3. Third Handshake (ACK=1, seq=x+1, ack=y+1)

    • After receiving the server's reply, the client must send an acknowledgment segment. It sets the ACK flag to 1, changes the sequence number to x+1 (because the first handshake consumes one sequence number), and sets the acknowledgment number to the server's sequence number + 1 (ack=y+1). This segment can carry application data.
    • After the server receives this, both parties enter the ESTABLISHED state, and the connection is successfully established.
    • Purpose: The client acknowledges the server's synchronization request, preventing erroneous connection establishment due to delayed, duplicate connection requests arriving at the server.

Why is a Three-Way Handshake Needed?

  • Core Reason: To avoid resource waste caused by the initialization of historical duplicate connections. With only a two-way handshake, if a delayed duplicate SYN segment from the client arrives at the server, the server would mistakenly believe a new connection is established and allocate resources, leading to wasteful resource consumption. The third handshake gives the client an opportunity to determine if the connection is the latest (verified by the acknowledgment number), thereby rejecting historical requests.
  • Additionally, the three-way handshake ensures reliable synchronization of both parties' initial sequence numbers, laying the foundation for subsequent reliable transmission.

Step 3: Four-Way Wavehand Connection Termination Process
Assume the client actively initiates the close:

  1. First Wavehand (FIN=1, seq=u)

    • The client sends a FIN segment (FIN=1) with sequence number u (equal to the last byte sequence number of previously transmitted data + 1). The client enters the FIN-WAIT-1 state.
    • Purpose: The client notifies the server that data transmission is complete and requests to close the data channel from client to server.

  2. Second Wavehand (ACK=1, seq=v, ack=u+1)

    • Upon receiving the FIN, the server immediately replies with an ACK segment (ACK=1), acknowledgment number ack=u+1, and sequence number v. The server enters the CLOSE-WAIT state.
    • At this point, the connection from client to server is closed, but the server may still have data to send to the client.
    • After receiving the ACK, the client enters the FIN-WAIT-2 state, waiting for the server's FIN segment.

  3. Third Wavehand (FIN=1, ACK=1, seq=w, ack=u+1)

    • After completing the transmission of remaining data, the server sends a FIN+ACK segment (FIN=1, ACK=1) with sequence number w (which may be larger than v) and acknowledgment number still u+1. The server enters the LAST-ACK state.
    • Purpose: The server notifies the client that its data transmission is also complete and requests to close the data channel from server to client.

  4. Fourth Wavehand (ACK=1, seq=u+1, ack=w+1)

    • Upon receiving the FIN, the client replies with an ACK segment (ACK=1) with acknowledgment number ack=w+1 and sequence number u+1. The client enters the TIME-WAIT state, waiting for 2MSL (Maximum Segment Lifetime) before closing the connection.
    • The server closes the connection immediately after receiving the ACK.
    • Purpose: The client acknowledges the server's close request, ensuring the server can close normally.

Why is a Four-Way Wavehand Needed?

  • Because TCP connections are full-duplex, the data sending and receiving channels are independent. When closing a connection, one party sending a FIN only indicates it will no longer send data (but may still receive data). Therefore, the closing process requires both parties to initiate FIN and acknowledgment ACK separately, resulting in one more interaction than the connection establishment process.
  • Purpose of the TIME-WAIT State: Ensures the last ACK reaches the server (if lost, the server will retransmit FIN); Allows all segments generated during the lifetime of this connection to disappear from the network, avoiding impact on new connections.