Hello everyone, I am Xiaolin.

I saw an old man ask 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 expectations, why is it returning RST instead of discarding it?

Do I return RST when I say return RST?

Of course not, I also checked the RFC standard.

Let me describe the scene first:

• The client sends a SYN message (seq=100) to the server, but there is an unexpected visitor 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 return the SYN-ACK message, the confirmation number is 90+1;
• After the client received the SYN-ACK message, he found that something was wrong. He obviously sent a SYN message (seq=100). According to reason, the confirmation number in the SYN-ACK message is 100+1, but now the received The confirmation number is the SYN-ACK message of 90+1, so it politely returned RST to the server;
• After the server receives the RST message, the server disconnects the connection in the SYN_RECEVIED state;
• Finally, the normal SYN message (seq=100) finally arrives at the server. After three handshakes, the TCP connections of both parties are established.

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

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

Now let's assume it's a discard process and see what happens?

It can be seen that when a client connected in the SYN_SENT state receives a SYN-ACK packet that does not meet expectations, if the selected processing is "discard", then both parties will trigger a timeout retransmission until the maximum number of retransmissions is reached. It will enter the CLOSE state, and this process needs to last for 10-20 seconds.

From the perspective of the client, it is too late to establish a connection with the server, because there is already an old connection with the same quadruple on the server side. If the connection on the server is not killed, then it is impossible to confirm the new connection of the client. Connection (SEQ=100), because in the non-LISTEN state, if a SYN is received, it will always return a challenge ack. This ack is not a confirmation of the receipt of the SYN report, but continues to reply to the last sent ACK.

Is there a feeling that the old connection (SEQ=90) on the server side is occupying the latrine?

So, the work of killing the old connection on the server side is left to the client side.

When the client connected in the SYN_SENT state receives a SYN-ACK message that does not meet the expectations, it will directly send RST to the server to kill the old connection of the server, so that the new connection of the client can be quickly established .

How about it, TCP is full of details!