Code Comics | TCP three-way handshake

[[356210]]

This article is reprinted from WeChat public account "Ma Ge Dan", author Chen Yuming. Please contact the WeChat public account "Ma Ge Dan" to reprint this article.

1. Three-way handshake can prevent the initialization of repeated historical connections (main reason)

2. Three-way handshake can synchronize the initial sequence numbers of both parties

3. Three-way handshake can avoid waste of resources

As shown in the figure:

The client sends multiple SYN packets to establish a connection. In the case of network congestion, the following happens:

An "old SYN message" arrives at the server earlier than the "latest SYN" message;

Then the server will return a SYN + ACK message to the client;

After receiving the message, the client can determine that this is a historical connection (the sequence number has expired or timed out) based on its own context, and then the client will send a RST message to the server to indicate that the connection is terminated.

If it is a two-way handshake connection, it is impossible to determine whether the current connection is a historical connection. A three-way handshake allows the client (sender) to determine whether the current connection is a historical connection because it has enough context when the client (sender) is ready to send the third message:

If it is a historical connection (serial number expired or timed out), the message sent in the third handshake is a RST message, thereby terminating the historical connection;

If it is not a historical connection, the third message sent is an ACK message, and the two communicating parties will successfully establish a connection;

Therefore, the main reason why TCP uses three-way handshake to establish a connection is to prevent historical connections from initializing the connection.

Both parties in the TCP protocol must maintain a "sequence number". The sequence number is a key factor in reliable transmission. Its functions are:

The receiver can remove duplicate data;

The receiver can receive the packets in order according to their sequence numbers;

It can identify which of the sent data packets have been received by the other party;

It can be seen that the sequence number plays a very important role in the TCP connection. Therefore, when the client sends a SYN message carrying the "initial sequence number", the server needs to send an ACK response message to indicate that the client's SYN message has been successfully received by the server. When the server sends the "initial sequence number" to the client, it still needs to get an ACK response from the client. This back and forth can ensure that the initial sequence numbers of both parties can be reliably synchronized.

Let me add one more thing:

If there is only a "two-way handshake", when the client's SYN request connection is blocked in the network and the client does not receive an ACK message, it will resend the SYN. ​​Since there is no third handshake, the server does not know whether the client has received the ACK confirmation signal it sent to establish a connection. Therefore, each time a SYN is received, it can only actively establish a connection. What will this cause?

If the client's SYN is blocked and the SYN message is sent repeatedly, the server will establish multiple redundant invalid links after receiving the request, resulting in unnecessary waste of resources.