Can this be considered? TCP is awesome.

Hello everyone, I am Xiaolin.

I saw an old man asked a question on the website.

To put it simply, why during the TCP three-way handshake, if the confirmation number of the SYN-ACK message received by the client does not meet the expectation, why does it return RST instead of discarding it?

If I say return to RST, does it mean return to RST?

Of course not, I also confirmed it by reading the RFC standard.

Let me describe the scene first:

• The client sends a SYN message (seq=100) to the server, but there is an uninvited guest in the network, and a historical SYN message (seq=90) arrives at the server first;
• When the server receives the historical SYN message, it will confirm the SYN message and send back a SYN-ACK message with the confirmation number 90+1;
• After receiving the SYN-ACK message, the client finds something wrong. It clearly sent a SYN message (seq=100). Logically, the confirmation number in the SYN-ACK message should be 100+1, but the SYN-ACK message it received has a confirmation number of 90+1. So it politely returns an RST to the server.
• After the server receives the RST message, it disconnects the connection in the SYN_RECEVIED state;
• Finally, the normal SYN message (seq=100) finally arrived at the server. After three handshakes, the TCP connection between both parties was established.

The above process is the process of TCP three-way handshake to prevent the establishment of historical connections. The reason why TCP needs three-way handshake is firstly to prevent confusion caused by old repeated connection initialization, and secondly to reliably synchronize the sequence numbers of both parties.

Why is it designed that when the client receives a SYN-ACK message that does not meet its expectations, it returns RST instead of discarding it?

Now let's assume it is discarded and see what happens?

It can be seen that when a client connected in the SYN_SENT state receives a SYN-ACK message that does not meet expectations, if the selected processing is "discard", both parties will trigger a timeout retransmission until the maximum number of retransmissions is reached before entering the CLOSE state. This process takes 10-20 seconds.

From the client's perspective, it is difficult to establish a connection with the server because an old connection with the same four-tuple already exists on the server. If the server connection is not terminated, the client's new connection (SEQ=100) cannot be confirmed. This is because in the non-LISTEN state, if a SYN is received, a challenge ack is returned. This ack does not confirm the receipt of the SYN message, but continues to reply to the last ACK sent.

Does it feel like the old connection (SEQ=90) on the server is just sitting there doing nothing?

Therefore, the task of killing the old connection on the server is left to the client.

When a client connected in the SYN_SENT state receives a SYN-ACK message that does not meet its expectations, it directly sends RST to the server, killing the server's old connection so that the client's new connection can be established quickly.

What do you think? TCP is full of details!