We all know that the establishment of TCP connection has "3-Way Handshake Connection and 4-Way Handshake Termination", but what exactly happened in the middle? Why is the number of handshake more in termination? What if only 2-Way Handshake are used? What will happen if there is network delay or packet loss during the handshake? This article will give you the answer.

TCP Header Format

In order to better explain the process of "3-Way Handshake Connection and 4-Way Handshake Termination", let's first look at the header format of the TCP message.

TCP header format

Sequence Number

It is a random number generated by the computer when establishing a connection, which exists in the SYN packet. Each time data is sent, the sequence number will be accumulated once. Data Bytes size.

Used to solve the problem of disordered network packets.

Confirmation Response Number

Refers to the sequence number of the data that is expected to be received next time. After receiving this confirmation response, the sender will think that the data before the sequence number has been received correctly.

Used to solve the problem of packet loss.

Control Bit

• ACK: When it is 1, it means that the Confirmation Response field becomes valid.
• RST: When it is 1, it means that abnormality occurs in the TCP connection and the connection must be disconnected.
• SYN: When it is 1, it means that it is hoped to establish a connection and use the sequence number field as the initial value of the sequence number.
• FIN: When it is 1, it means that it is hoped to disconnect and no data will be sent in the future.

3-Way Handshake

Let's take a look at the schematic diagram of the 3-Way Handshake:

TCP 3-Way Handshake process

Handshake Process

1. First handshake

   When no connection is established, both the client and the server are in the CLOSE state. When the client wants to initiate a connection, it will send the first message to the server: SYN message. The format is as follows:

   

   TCP first handshake message

   • The client will randomly initialize the sequence number: client_isn and use it as the sequence number.
   • The SYN bit will be set to 1.

   After sending the message, the client will enter the SYN-SENT state.

2. Second handshake

   After receiving the SYN message from the client, the server will respond and send: SYN + ACK message. The format is as follows:

   

   TCP Second handshake message

   • The server will also randomly initialize the sequence number: server_isn and use it as the sequence number.

   • Confirm the response number: client_isn + 1.

   • SYN and ACK position 1.

   After sending this message, the server will enter the SYN-RCVD state.

3. Third handshake

   After the client receives the response from the server, it needs to respond to the server with the last message: ACK message. The format is as follows:

   

   TCP third handshake message

   • Confirm the response number: server_isn + 1.
   • ACK position 1.
   • This message will carry the data that the client needs to send.

   After sending this message, the client will enter the ESTABLISHED state. The server will also enter the ESTABLISHED state after receiving the message.

Why is it necessary to do three times?

• Only 3-Way Handshake can prevent the initialization of historical duplicate connections (main reason).
• Only 3-Way Handshake can synchronize the initial sequence numbers of both parties.
• Only 3-Way Handshake can avoid resource waste.

1. Avoid duplication of historical connections

RFC 793 explains the use of 3-Way Handshake for TCP connections:

The principle reason for the three-way handshacke is to prevent old duplicate connection initiations from causing confusion.

The main reason for the 3-Way Handshake is to avoid initialization confusion caused by historical duplicate connections.

Just reading this sentence may feel very abstract. But it doesn't matter. Let's look at the following example to understand what historical connections are, and how the 3-Way Handshake prevents confusion caused by historical connections.

Let's consider the following scenario: The client first sends a message SYN (seq = 90), Then when no response was received, the server crashed and the SYN message was not received by the server due to network congestion. The client restarted and tried to establish a connection again, sending SYN (seq = 100).

Warning

The scenario here does not belong to SYN message retransmission. If the message retransmission is caused only by network congestion, the sequence numbers of the two SYNs are the same.

TCP 3-Way Handshake to avoid historical connections

It can be seen that the main problem caused by network congestion is that the old SYN message arrives at the server earlier than the new SYN message. If only two handshakes are used, then when the server responds to the old message (seq = 90), the server and the client have established a connection based on the synchronization sequence of seq = 90, and both parties enter the ESTABLISHED state at the same time.

But in the 3-Way Handshake, we can see that After receiving the old SYN message, the server responded with a SYN + ACK message. When the client receives the response message of ACK = 90 + 1, it can be found that it does not meet its expectations, so it sends a RST message to terminate the connection establishment before the connection is established.

2. Synchronize the sequence numbers of both parties

Both parties in the TCP protocol communication must maintain a sequence number to ensure the reliable transmission of messages. The main functions are:

• The receiver can remove duplicate data.
• The receiver can reorganize the messages in order through the sequence number.
• The sender can know which messages have been received through the sequence number in the ACK message.

3. Avoid resource waste

In fact, this reason is the same as the first "avoid duplication of historical connections". If there are only two handshakes, the connection has been established when the old SYN message arrives at the server. Then when the new SYN message arrives, the server has to establish a connection again. This leads to the waste of resources by establishing an incorrect connection the first time, Moreover, the wrong connection may have generated data transmission, thus wasting network resources.

Why not use 4-Way Handshake?

Actually, the handshake is four times, but the second and third times in the middle can be merged, so it becomes a 3-Way Handshake.

4-Way Handshake merged into 3-Way Handshake

4-Way Handshake

Handshake Process

TCP 4-Way Handshake

1. First handshake

   The client actively sends a FIN message, indicating that it will not send data anymore, and enters the FIN_WAIT_1 state.

2. Second handshake

   After receiving the FIN message, the server will reply with an ACK message for confirmation, and then the server enters the CLOSE_WAIT state.

3. Third handshake If the application on the server has sent all the data, The server will send a FIN message to indicate that it will no longer send data and enter the LAST_ACK state.

4. The fourth handshake

   After receiving the FIN message from the server, the client will reply with an ACK confirmation message. After that, the client will enter the TIME_WAIT state. After receiving this ACK message, the server will enter the CLOSE state, and the client will enter the CLOSE state after waiting for 2MSL time after sending the message.

Why can't 4-Way Handshake be combined into 3-Way Handshake?

Because when the client initiates the shutdown, the application may still have data that has not been sent yet.

The ACK message sent by the server in the second handshake is only to indicate that the FIN message initiated by the client has been received. The decision on whether to send the FIN message in the third handshake is not on the server, but on the application on the server. Only when all the data of the application has been sent and the application calls the shutdown function, the server will send FIN message.

Summary

The TCP protocol establishes a link to ensure transmission correctness through 3-Way Handshake and 4-Way Handshake.

The 3-Way Handshake include: the SYN message initiated by the client, the SYN + ACK message responded by the server, and the ACK message confirmed by the client. The SYN + ACK message responded by the server is a combination of the ACK response to the first handshake and the SYN message initiated by itself, so the 4-Way Handshake becomes a 3-Way Handshake. The 3-Way Handshake can effectively avoid resource waste and errors caused by repeated historical connections.

The 4-Way Handshake include: the FIN message initiated by the client, the ACK message responded by the server, the FIN message initiated by the server, and the ACK message confirmed by the client. The reason why the 4-Way Handshake cannot be compressed into 3-Way Handshake like the handshake is that when the client requests to close the connection, the server may still have data that has not been transmitted. It needs to wait for the server application to send the data before sending the server's FIN message.

References for this article

1. Xiaolin coding

Contributors

• dingyuqi

Changelog

Last Updated: View All Changelog

• 00419-

  feat(docs): add new article

  On 11/27/24

Copyright

Copyright Ownership:dingyuqi

This article link:/en/article/3y3tmv0x/

License under:Attribution-NonCommercial-NoDerivatives 4.0 International (CC-BY-NC-ND-4.0)