Byte side: TCP three-way handshake, very detailed questions!

Hello everyone, I am Xiaolin.

A reader was asked this question during an interview with ByteDance:

To sum up, there are two questions:

In the TCP three-way handshake, if the ack confirmation number received by the client in the second handshake is not what it expected, what will happen? Will it discard it directly or return a RST message?

Under what circumstances will an incorrect ack (ack in the second handshake) be received?

FAQ

Without further ado, let me get straight to the point. The process is to return an RST message. The process is as follows:

Three-way handshake to avoid historical connections

When the client sends multiple SYN packets to establish a connection, and the network is congested, the client will receive an incorrect ack. The specific process is as follows:

• The client first sent a SYN (seq = 90) message, but it was blocked by the network and the server did not receive it. Then the client resent the SYN (seq = 100) message. Note that it is not a retransmitted SYN. ​​The sequence number of the retransmitted SYN is the same.
• If the "old SYN message" arrives at the server earlier than the "latest SYN" message, the server will send a SYN + ACK message to the client, and the confirmation number of this message is 91 (90+1).
• After receiving the message, the client realizes that the confirmation number it expects to receive is 100+1, not 90+1, so it sends a RST message.
• After receiving the RST message, the server will terminate the connection.
• After the latest SYN arrives at the server, the client and server can complete the three-way handshake normally.

The "old SYN message" mentioned above is called a historical connection. The main reason why TCP uses a three-way handshake to establish a connection is to prevent the "historical connection" from initializing the connection.

We can also know from RFC 793 the primary reason why TCP connections use a three-way handshake:

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

In short, the primary reason for the three-way handshake is to prevent old repeated connection initialization from causing confusion. The example diagram of the three-way handshake to prevent historical connections given by RFC is as follows:

RFC 793

If it is a two-way handshake connection, the historical connection cannot be blocked. Then why can't the TCP two-way handshake block the historical connection?

Let me first state the conclusion. This is mainly because in the case of two handshakes, the "passive initiator" has no intermediate state to give to the "active initiator" to prevent the historical connection, which causes the "passive initiator" to establish a historical connection, resulting in a waste of resources.

Think about it, in the case of two handshakes, the "passive initiator" enters the ESTABLISHED state after receiving the SYN message, which means that it can send data to the other party at this time, but the "active initiator" has not entered the ESTABLISHED state at this time. Assuming that this is a historical connection, the active initiator determines that this connection is a historical connection, then it will return a RST message to disconnect the connection, and the "passive initiator" enters the ESTABLISHED state during the first handshake, so it can send data, but it does not know that this is a historical connection. It will only disconnect after receiving the RST message.

Two-way handshake cannot prevent historical connections

It can be seen that in the above scenario, the "passive initiator" did not block the historical connection before sending data to the "active initiator", causing the "passive initiator" to establish a historical connection and send data in vain, which completely wasted the resources of the "passive initiator".

Therefore, to solve this problem, it is best to block the historical connection before the "passive initiator" sends data, that is, before establishing a connection, so as not to waste resources. To achieve this function, a three-way handshake is required.

Source code analysis

Does it mean it will return RST if I say so? Of course not. I must use the source code to prove my conclusion.

Some students may feel discouraged when they hear that they need to analyze the source code.

In fact, to analyze our problem today, you just need to understand if else. I can also use Chinese to express the logic of the code, so it is okay to just read my text.

This time we focus on analyzing how to handle the syn+ack message with an incorrect confirmation number when in the SYN_SENT state.

The client in the SYN_SENT state will eventually call tcp_rcv_state_process after receiving the syn+ack message from the server, where it will do corresponding processing according to the TCP state. Here we only focus on the SYN_SENT state.

 // net / ipv4 / tcp_ipv4.c
 int tcp_rcv_state_process ( struct sock * sk , struct sk_buff * skb )
 {
 ...

 int queued = 0 ;

 ...

 switch ( sk -> sk_state ) {
 case TCP_CLOSE :
 ...
 case TCP_LISTEN :
 ...
 case TCP_SYN_SENT :
 ....
 queued = tcp_rcv_synsent_state_process ( sk , skb , th ) ;
 if ( queued >= 0 )
 return queued ;
 ...
 }

It can be seen that the tcp_rcv_synsent_state_process function will continue to be called next.

 static int tcp_rcv_synsent_state_process ( struct sock * sk , struct sk_buff * skb ,
 const struct tcphdr * th )
 {
 ....

 if ( th -> ack ) {
 /* rfc793:
 * "If the state is SYN-SENT then
 * first check the ACK bit
 * If the ACK bit is set
 * If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send
 * a reset (unless the RST bit is set, if so drop
 * the segment and return)"
 */
 // The confirmation number of ack is not expected
 if ( ! after ( TCP_SKB_CB ( skb ) -> ack_seq , tp -> snd_una ) ||
 after ( TCP_SKB_CB ( skb ) -> ack_seq , tp -> snd_nxt ) )
 // Return RST message
 goto reset_and_undo ;

 ...
 }

From the above function, we can know that when the client is in the SYN_SENT state, if it receives a syn+ack message with an incorrect confirmation number, it will return a RST message.

summary

In the TCP three-way handshake, if the ack confirmation number received by the client in the second handshake is not what it expected, what will happen? Will it discard it directly or return a RST message?

Return RST message.

Under what circumstances will an incorrect ack (ack in the second handshake) be received?

When the client initiates multiple SYN messages and the network is congested, the "old SYN message" arrives at the server earlier than the "new SYN message". At this time, the server will reply with a syn+ack message according to the received "old SYN message", and the confirmation number of this message is not what the client expects to receive, so the client will reply with a RST message.