TCP waved four times, you are familiar with it! But what about unexpected situations? What about malicious attacks? What about single-end running away?

1. Preface

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

The articles two days ago talked about the abnormal situation of TCP's three-way handshake. Today, let's continue to talk about the four-way handshake.

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 magical. In the face of changing network conditions, it can only ensure reliability through continuous retransmission and various algorithms.

When data transmission is completed and the connection needs to be disconnected, TCP will complete the disconnection of both ends through four handshakes and reclaim their respective resources. So today, let's continue to talk about how to deal with problems such as abnormalities and one-end running away during the TCP four-way handshake.

[[312418]]

2. TCP four-way handshake

1. Simple understanding of four waves

Although we are talking about the abnormal situation of four handshakes, before that, let's first have a brief understanding of TCP's four handshakes.

When data transmission is completed and the connection needs to be disconnected, TCP will use four waves to safely disconnect.

Why does a handshake take three times, but a wave takes four?

Essentially, both parties need to go through a "breakup" process to ensure that they and the other party are in the right state. In a friendly and negotiated manner, if you are the first to propose the breakup, you should also show the greatest goodwill to the other party and not catch the other party off guard. If you say you don't want to play anymore, then who will dare to play with you in the future?

The following picture shows the classic TCP four-wave message and the changes in the status of both ends.

Let us explain this picture:

• Initially, both ends are in the ESTABLISHED state and transmitting data. One end can actively initiate a "FIN" packet to prepare to disconnect. In this scenario, the client initiates the "FIN" request. After sending the "FIN", the client enters the FIN-WAIT-1 state.
• After receiving the "FIN" message, the server replies "ACK" to indicate that it has understood the message, and then enters the CLOSED-WAIT state from the ESTABLISHED state and starts to do some preparations before disconnecting.
• After the client receives the "ACK" message in response to the previous "FIN", it enters the FIN-WAIT-2 state. When the server is ready to disconnect, it will also send a "FIN, ACK" message to the client, indicating that it is also ready and requesting to disconnect. After sending the message, the server enters the LAST-ACK state.
• After receiving the "FIN, ACK" message, the client will immediately reply "ACK" to indicate that it has received the message and enter the TIME_WAIT state. For stability and security reasons, the client will wait for 2MSL in the TIME-WAIT state and finally enter the CLOSED state.
• After the server receives the "ACK" message from the client, it directly enters the CLOSED state from the LAST-ACK state.

Normally, after four waves, both ends enter the CLOSED state, after which both ends officially disconnect.

2. Abnormal TCP handshake

We have briefly understood the normal packet sending and response process of four waves. Next, let's continue to look at the abnormal situations that occur during the four waves.

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 FIN packet for disconnecting the connection is lost.

We have emphasized before that if a packet is sent out and no "ACK" is received from the other end within a certain period of time, the packet is considered lost and the timeout retransmission mechanism will be triggered. It does not matter whether it is the packet you sent that is lost or the "ACK" from the other end that is lost.

So here, if the "FIN" packet sent first by the client is lost, or if the "ACK" reply from the other end is not received, a timeout retransmission will be triggered until the number of retransmissions is triggered, and the connection will be closed directly.

For the server, if the "FIN" sent by the client is not received, there is no perception. After a period of time, the connection will also be closed.

(2) The server's first reply ACK is lost.

At this time, because the client did not receive the "ACK" response, it will try to retransmit the previous "FIN" request. After the server receives it, it will retransmit the "ACK" again.

At this time, the server has entered the CLOSED-WAIT state and started to prepare for disconnection. When ready, it will reply "FIN, ACK". Note that this message carries the response sequence number of the previous "ACK".

As long as the message is not lost, the client can use the response sequence number in the "FIN, ACK" packet to directly enter the TIME-WAIT state from the FIN-WAIT-1 state and start a wait of up to 2MSL.

(3) The FIN and ACK sent by the server are lost.

The server will retransmit after the timeout. At this time, the client has two situations: either it is in the FIN-WAIT-2 state (the previous ACK is also lost) and will keep waiting; or it is in the TIME-WAIT state and will wait for 2MSL time.

That is to say, the client is still there for a short period of time. After receiving the "FIN, ACK" packet sent by the server, the client will also reply with an "ACK" response and make its own state switch.

(4) The last ACK from the client is lost.

After the client replies "ACK", it will enter the TIME-WAIT state and start waiting for up to 2MSL. Because the server has not received an "ACK" reply, it will retry for a while until the server actively disconnects after the retry timeout.

Or wait for a new client to access, and after receiving the server's retry "FIN" message, reply with a "RST" message. After receiving the "RST" message, reset the server's status.

(5) After the client receives the ACK, the server runs away.

After receiving the "ACK", the client enters the FIN-WAIT-2 state, waiting for the "FIN" packet sent by the server. If the server runs away, this packet will never arrive.

In the TCP protocol, there is no mechanism to handle this state. However, the protocol does not care, the system will take over this state, for example, in Linux, you can use the tcp_fin_timeout parameter to set a timeout for this state.

It should be noted that when the tcp_fin_timeout limit is exceeded, the state does not switch to TIME_WAIT, but directly enters the CLOSED state.

Reference: https://blog.huoding.com/2016/09/05/542

(6) After receiving the ACK, the client runs away.

After receiving the "ACK", the client runs away directly. The subsequent "FIN, ACK" sent by the server has no receiver and no reply. The TCP timeout retry mechanism will be continuously used. At this time, the server is in the LAST-ACK state.

Then we need to analyze two situations:

After a certain period of time, the server actively disconnects.

After receiving "RST", the connection is actively disconnected.

The "RST" message is a reset message, indicating that the current error should be returned to the initial state. If a new client accesses after the client runs away, it will send a "SYN" here in the hope of establishing a connection. At this time, this "SYN" will be ignored and directly reply with a "FIN, ACK" message. The new client will not recognize the "FIN" message after receiving it, and will reply with a "RST" message.

3. Summary time

Today we talked about some processing strategies when TCP encounters errors in the four wave phases.

In most cases, the TCP protocol itself guarantees reliability, such as timeout retransmission, but sometimes the operating system needs to take over some states, such as tcp_fin_timeout.