TCP three-way handshake and four-way handshake, what happens if it fails in the middle?

Author: Kobayashi coding
graphic computer foundation (operating system, computer network, computer composition, database, etc.) website: https://xiaolincoding.com

Hello everyone, I am Xiaolin.

I have written an article about what happens when a packet is lost at a certain step during the TCP three-way handshake and four-way handshake.

At that time, it was mainly a text description, which may not be easy to remember, so I re-drawn the picture for the abnormal situation of each step, so that everyone can understand and remember.

Let's go!

TCP three-way handshake packet loss

The first handshake is lost, what happens?

When the client wants to establish a TCP connection with the server, the first thing to send is the SYN message, and then enter SYN_SENTthe state .

After that, if the client fails to receive the SYN-ACK message from the server (the second handshake), it will trigger the "timeout retransmission" mechanism to retransmit the SYN message, and the retransmitted SYN message The serial numbers are the same .

Different versions of the operating system may have different timeouts, some are 1 second, and some are 3 seconds. This timeout is hard-coded in the kernel. If you want to change it, you need to recompile the kernel, which is troublesome.

When the client does not receive the SYN-ACK message from the server after 1 second, the client will resend the SYN message, how many times will it be resent?

In Linux, the maximum number of retransmissions of the SYN message of the client is controlled by a tcp_syn_retrieskernel parameter, which can be customized, and the default value is generally 5.

# cat /proc/sys/net/ipv4/tcp_syn_retries
5

Usually, the first timeout retransmission is after 1 second, the second timeout retransmission is after 2 seconds, the third timeout retransmission is after 4 seconds, the fourth timeout retransmission is after 8 seconds, and the second timeout retransmission is after 8 seconds. Five times after retransmitting with a timeout of 16 seconds. That's right, each timeout takes twice as long as the previous one .

After the fifth overtime retransmission, it will continue to wait for 32 seconds. If the server still does not respond with ACK, the client will no longer send SYN packets, and then disconnect the TCP connection.

Therefore, the total time-consuming is 1+2+4+8+16+32=63 seconds, about 1 minute.

For example, assuming that the parameter value of tcp_syn_retries is 3, then when the client's SYN message is always lost in the network, the following process will occur:

Specific process:

When the client retransmits the SYN message 3 times overtime, since tcp_syn_retries is 3, the maximum number of retransmissions has been reached, so wait for a while (the time is twice the time of the previous timeout), if the server still fails to receive The second handshake (SYN-ACK message), then the client will disconnect.

The second handshake is lost, what happens?

When the server receives the first handshake from the client, it will return a SYN-ACK message to the client. This is the second handshake, and the server will enter SYN_RCVDthe state

The second handshake SYN-ACKmessage actually has two purposes:

The ACK in the second handshake is the confirmation message for the first handshake;
The SYN in the second handshake is a message initiated by the server to establish a TCP connection;

So, if the second handshake is lost, something more interesting will happen. What will happen?

Because the second handshake message contains the ACK confirmation message of the first handshake to the client, if the client has not received the second handshake for a long time, then the client thinks that its own SYN message ( The first handshake) is lost, so the client will trigger the timeout retransmission mechanism and retransmit the SYN message .

Then, because the second handshake contains the server's SYN message, when the client receives it, it needs to send an ACK confirmation message to the server (the third handshake), and the server will think that the SYN message has been received by the client. end received.

Then, if the second handshake is lost, the server will not receive the third handshake, so the server will trigger a timeout retransmission mechanism to retransmit the SYN-ACK message .

Under Linux, the maximum number of retransmissions of SYN-ACK packets is determined by tcp_synack_retrieskernel parameters, and the default value is 5.

# cat /proc/sys/net/ipv4/tcp_synack_retries
5

Therefore, when the second handshake is lost, both client and server retransmit:

The client will retransmit the SYN message, which is the first handshake, and the maximum number of retransmissions is determined by the tcp_syn_retrieskernel parameters;
The server will retransmit the SYN-ACK message, which is the second handshake, and the maximum number of retransmissions is determined by the tcp_synack_retrieskernel parameters.

For example, suppose the parameter value of tcp_syn_retries is 1, and the parameter value of tcp_synack_retries is 2, then when the second handshake is always lost, the process that occurs is as follows:

Specific process:

When the client retransmits a SYN message once overtime, since tcp_syn_retries is 1, the maximum number of retransmissions has been reached, so wait for a while (the time is twice the time of the previous timeout), if it still fails to receive the SYN message from the server The second handshake (SYN-ACK message), then the client will disconnect.
When the server retransmits the SYN-ACK message 2 times overtime, since tcp_synack_retries is 2, the maximum number of retransmissions has been reached, so wait for a while (the time is twice the time of the previous timeout), if it still fails to receive The client's third handshake (ACK message), then the server will disconnect.

The third handshake is lost, what happens?

After the client receives the SYN-ACK message from the server, it will return an ACK message to the server, which is the third handshake, and the client state enters ESTABLISHthe state

Because the ACK of the third handshake is the confirmation message of the SYN of the second handshake, so when the third handshake is lost, if the server side fails to receive the confirmation message, it will trigger a timeout restart. The transmission mechanism retransmits the SYN-ACK message until the third handshake is received, or the maximum number of retransmissions is reached.

Note that the ACK message will not be retransmitted. When the ACK is lost, the corresponding message will be retransmitted by the other party .

For example, assuming that the parameter value of tcp_synack_retries is 2, then when the third handshake has been lost, the process that occurs is as follows:

Specific process:

When the server retransmits the SYN-ACK message 2 times overtime, since tcp_synack_retries is 2, the maximum number of retransmissions has been reached, so wait for a while (the time is twice the time of the previous timeout), if it still fails to receive The client's third handshake (ACK message), then the server will disconnect.

TCP four wave packet loss situation

The first wave is lost, what happens?

When the client (actively closing the party) calls the close function, it will send a FIN message to the server, trying to disconnect from the server, and the connection of the client enters FIN_WAIT_1the state

Under normal circumstances, if the ACK from the server (the passive closing party) can be received in time, it will quickly change to FIN_WAIT2the state .

If the first wave is lost, and the client fails to receive the ACK from the passive party, it will trigger the timeout retransmission mechanism and retransmit the FIN message. The number of retransmissions is controlled by tcp_orphan_retriesparameters

When the number of times the client retransmits the FIN message tcp_orphan_retriesexceeds , it will no longer send the FIN message, and will wait for a period of time (the time is twice the time of the previous timeout), if it still fails to receive the second wave, Then go directly to closethe state .

For example, assuming that the parameter value of tcp_orphan_retries is 3, when the first wave is always lost, the process that occurs is as follows:

Specific process:

When the client retransmits the FIN message 3 times after the timeout, because tcp_orphan_retries is 3, the maximum number of retransmissions has been reached, so wait for a while (the time is twice the time of the previous timeout), if the server still fails to receive The second wave (ACK message), then the client will disconnect.

The second wave is lost, what happens?

When the server receives the first waving from the client, it will return an ACK confirmation message first, and the connection of the server enters CLOSE_WAITthe state .

We also mentioned earlier that the ACK message will not be retransmitted, so if the server's second wave is lost, the client will trigger the timeout retransmission mechanism and retransmit the FIN message until it receives the server's first wave. Wave twice, or reach the maximum number of retransmissions.

For example, assuming that the parameter value of tcp_orphan_retries is 2, when the second wave is always lost, the process that occurs is as follows:

Specific process:

When the client retransmits the FIN message 2 times overtime, because tcp_orphan_retries is 2, the maximum number of retransmissions has been reached, so wait for a period of time (the time is twice the time of the previous timeout), if the server still fails to receive The second wave (ACK message), then the client will disconnect.

Let me mention here that when the client receives the second wave, that is, after receiving the ACK message sent by the server, the client will be in FIN_WAIT2the state In this state, it needs to wait for the server to send the third wave, that is, the service end of the FIN message.

For the connection closed by the close function, since the data can no longer be sent and received, FIN_WAIT2the state cannot last for too long, and tcp_fin_timeoutcontrols the duration of the connection in this state, and the default value is 60 seconds.

This means that for the connection closed by calling close, if no FIN message is received after 60 seconds, the connection of the client (active close party) will be closed directly, as shown in the following figure:

Note, however, that if the active closing party uses the shutdown function to close the connection, specifying that only the sending direction is closed, but the receiving direction is not closed, it means that the active closing party can still receive data.

At this time, if the active closing party has not received the third wave, the connection of the active closing party will always be in FIN_WAIT2the state ( tcp_fin_timeoutthe connection closed by shutdown cannot be controlled). As shown below:

The third wave is lost, what happens?

When the server (passive closing party) receives the FIN message from the client (active closing party), the kernel will automatically reply ACK, and the connection is in CLOSE_WAITthe state of

At this time, the kernel has no right to replace the process to close the connection, and the process must actively call the close function to trigger the server to send a FIN message.

When the server is in the CLOSE_WAIT state and the close function is called, the kernel will send a FIN message, and the connection will enter the LAST_ACK state at the same time, waiting for the client to return ACK to confirm the connection is closed.

If the ACK is not received for a long time, the server will resend the FIN message, and the number of retransmissions is still tcp_orphan_retriecontrolled by the s parameter, which is the same as the control method of the number of retransmissions of the FIN message resent by the client.

For example, assuming tcp_orphan_retries = 3, when the third wave is always lost, the process that occurs is as follows:

Specific process:

When the number of times the server retransmits the third waving message reaches 3 times, since tcp_orphan_retries is 3, the maximum number of retransmissions is reached, so wait for a while (the time is twice the time of the previous timeout), if still If the fourth wave (ACK message) from the client is not received, the server will disconnect.
Because the client closes the connection through the close function, there is a time limit in the FIN_WAIT_2 state. If the third wave (FIN message) from the server is still not received within the tcp_fin_timeout time, the client will disconnect.

The fourth wave is lost, what happens?

When the client receives the FIN message of the third hand wave from the server, it will return an ACK message, that is, the fourth hand wave, and the client connection enters TIME_WAITthe state

In the Linux system, the TIME_WAIT state will last for 2MSL before entering the closed state.

Then, before the server (passive closing party) does not receive the ACK message, it is still in the LAST_ACK state.

If the ACK message of the fourth hand wave does not reach the server, the server will resend the FIN message, and the number of retransmissions is still controlled by tcp_orphan_retriesthe parameters

For example, assuming tcp_orphan_retries is 2, when the fourth waving is always lost, the process that occurs is as follows:

Specific process:

When the server retransmits the wave message for the third time and reaches 2, because tcp_orphan_retries is 2, the maximum number of retransmissions is reached, so wait for a while (the time is twice the time of the previous timeout), if it still fails to receive The fourth wave of the client (ACK message), then the server will disconnect.
After receiving the third wave, the client will enter the TIME_WAIT state and start a timer with a duration of 2MSL. If the client receives the third wave (FIN message) again on the way, it will reset the timer. When waiting After 2MSL duration, the client will disconnect.

over!

How about it, is it clear now?