The TCP three-way handshake is well known, but what about accidental packet loss? What about intentional non-ACK response?

1. Preface

When we talk about the TCP protocol, the most talked about are the three-way handshake and the four-way wave. But have you ever thought about how to deal with an exception during the three-way handshake or the four-way wave? Who handles it?

As a reliable protocol, TCP needs to establish a connection between two ends before and after data transmission, and maintain the connection status on both ends. TCP is not special. In the face of changing network conditions, it can only ensure reliability through continuous retransmission and various algorithms.

Before establishing a connection, TCP will use three handshakes to ensure that the status of both ends is correct, and then data can be transmitted normally. After the data transmission is completed, four handshakes are used to ensure that both ends reasonably disconnect and recycle their respective resources.

When we learn about TCP connection establishment and disconnection, it is a standard process, but the network is changeable and often not as standard as in textbooks. So today we will talk about how to deal with abnormalities in the TCP three-way handshake.

[[312105]]

2. TCP three-way handshake

1. Simple understanding of the three-way handshake

Although we are talking about the abnormal situation of the three-way handshake, let's first understand the three-way handshake.

When transmitting data via TCP, the first step is to establish a connection. The process of TCP establishing a connection is what we often call a three-way handshake.

We often describe the three-way handshake as "request → response → response of response".

As for why the TCP handshake is three times, it is actually to make both ends go through the "request → response" process once to confirm that the other party is still there. Network conditions are changeable, and both ends need to actively initiate a request and the other party's response process to ensure that the other party and the network are normal.

The picture below shows the classic TCP three-way handshake messages and the changes in the status of both ends.

Let's first explain this picture:

• Initially, both ends are in the CLOSE state. In order to provide services, the server will actively listen to a port and enter the LISTEN state.
• The client actively sends a "SYN" packet for the connection, and then enters the SYN-SENT state. After receiving the "SYN" packet sent by the client, the server replies with a "SYN, ACK" packet, and then enters the SYN-RCVD state.
• After the client receives the "SYN, ACK" packet sent by the server, it can confirm the existence of the other party, then reply with an "ACK" packet and enter the ESTABLISHED state.
• After the server receives the last "ACK" packet, it also enters the ESTABLISHED state.

After the normal three-way handshake, both ends enter the ESTABLISHED state, after which the normal data transmission process begins.

2. Abnormal TCP handshake

We have already discussed the normal packet sending and response of the three-way handshake, as well as the state reversal of both ends. Next, let's take a look at the abnormal situations that occur during the three-way handshake.

(1) The client’s first “SYN” packet is lost.

If the first "SYN" packet of the client is lost, that is, the server does not know that the client has ever sent a packet, then the processing flow is mainly on the client.

In the TCP protocol, in a set of "request-response" at one end, if the "ACK" packet of the response is not received within a certain time range, whether the other party has not received the request packet or the other party's response packet has not been received by itself, it is considered to be lost and the timeout retransmission mechanism will be triggered.

So at this time, the "SYN" packet will be retransmitted. According to the description in "TCP/IP Detailed Explanation Volume I: Protocol", three attempts will be made at this time, with intervals of 5.8s, 24s, and 48s respectively. The three attempts take about 76s, and most Berkeley systems limit the maximum time to establish a new connection to 75s.

That is to say, if the first "SYN" packet of the three-way handshake is lost, it will be retransmitted, and the total attempt time is 75s.

(2) The server receives the "SYN" packet and the "SYN, ACK" packet it sends back is lost.

At this point, the server has received the data packet and responded. If the "SYN, ACK" packet of the response is lost, from the client's perspective, it will think that the initial "SYN" is lost, and then continue to retransmit, which is the "Error 1 process" we mentioned earlier.

For the server, if the sent "SYN, ACK" packet is lost and the "ACK" packet sent by the client is not received within the timeout period, retransmission will be triggered. At this time, the client is in the SYN_RCVD state and will wait for 3s, 6s, and 12s respectively before resending the "SYN, ACK" packet.

The number of retransmissions of this "SYN, ACK" packet has different configurations in different operating systems. For example, in Linux, it can be configured through tcp_synack_retries, and the default value is 5. If the "ACK" response packet is not received within this number of retries, the server will automatically close the connection.

At the same time, since the client will also retransmit when it does not receive "SYN, ACK", when the client receives the retransmitted "SYN", it will immediately resend the "SYN, ACK" packet.

(3) The “ACK” packet in the client’s last reply to “SYN, ACK” is lost.

If the last "ACK" packet is lost, the server will use the retransmission mechanism because it cannot receive the "ACK", and the client will enter the ESTABLISHED state.

In most cases, after the client enters the ESTABLISHED state, it believes that the connection has been established and will send data immediately. However, the server is still in the SYN-RCVD state because it has not received the last "ACK" packet.

The key here is how the server handles the data packet received from the client when it is in the SYN-RCVD state.

This is also a controversial issue. Some materials state that when the server is in the SYN-RCVD state, after receiving the client's data packet, it will directly reply with an RTS packet response, indicating a server error, and enter the CLOSE state.

However, this setting is a bit too strict. Imagine that the server is still going through the three-way handshake stage to determine whether the other party really exists. At this time, the other party's data has been sent, so it definitely exists.

Therefore, when the server is in the SYN-RCVD state, when it receives the data packet actually sent by the client, it will consider the connection to be established and enter the ESTABLISHED state.

So why is this actually happening?

When the client starts sending data packets in the ESTABLISHED state, it will carry the confirmation number of the previous "ACK". Therefore, even if the "ACK" packet responded by the client is lost, when the server receives this data packet, it can enter the ESTABLISHED state normally through the confirmation number of the ACK in the packet.

(4) The client intentionally does not send the last "SYN" packet.

I have been talking about the normal abnormal logic before. Both parties are relatively friendly and do things according to the rules. The anomalies are mainly due to objective problems such as the network. Next, let’s talk about a malicious situation.

If the client is malicious and does not reply after sending the "SYN" packet and receiving the "SYN, ACK", the server is in a semi-connected state. Although the server will configure the number of retries through tcp_synack_retries and will not wait indefinitely, there is also a time period.

If there are a large number of such malicious connections in a short period of time, it will put a lot of pressure on the server. This is the so-called SYN FLOOD attack.

This falls into the category of security attack and defense, so we won’t discuss it today. If you are interested, you can learn about it yourself.

3. Summary time

Today we talked about how to deal with some issues when TCP encounters anomalies during the three-way handshake phase of establishing a connection.

In most cases, TCP reliability is guaranteed by timeout retransmissions, but the number of retransmissions, state transitions, and other details are the subject of this article.