Part of the content in this article is quoted from the following list of articles:

The TCP state machine is a better way to understand the TCP mechanism. In addition, there are many timers in TCP. In this article, we combine the state machine to explain in detail the role of various timers and why they exist.

State description in TCP

The TCP state machine is as follows:

The TCP connection establishment process is as follows:

The release process of TCP connection is as follows:

TCP timer description

TCP timers include the following types:

Connection-establishment timer

Retransmission timer

Delayed ACK timer

Persist timer

Keepalive timer (keepalive timer)

FIN_WAIT_2 timer (FIN_WAIT_2 timer)

TIME_WAIT timer (TIME_WAIT timer, also called 2MSL timer)

1. Connection-establishment timer (connection-establishment timer)

purpose: Prevent infinite waiting when establishing a connection.

Timer mechanism: As the name implies, this timer is used when establishing a connection. We know that TCP connection establishment requires a 3-way handshake. In the process of establishing a connection, when sending a SYN, a timer will be started (the default should be 3 seconds), if the SYN packet is lost, the SYN packet will be resent after 3 seconds (of course, a new timer will also be started) , Set to 6 seconds timeout), of course, it will not send SYN packets endlessly. In /proc/sys/net/ipv4/tcp_syn_retries you can set how many times to resend SYN packets.

Corresponding state machine: No timeout: SYN_SENT->ESTABLISHED, timeout: SYN_SENT->CLOSED.

2. Retransmission timer

purpose: Ensure data reliability.

Timer mechanism: The retransmission timer is set when TCP sends data. After the timer expires, if the return confirmation ACK is not received, the sender will resend the message segment in the queue that needs to be retransmitted. The general rules for using RTO retransmission timer are as follows:

When TCP sends the message segment at the front end of the sending queue, it starts this RTO timer;
If the queue is empty, stop the timer, otherwise restart the timer;
When the timer expires, TCP will retransmit the top segment of the sending queue;
When one or more segments are confirmed cumulatively, this or these segments will be cleared out of the queue.

The retransmission timer ensures that the receiving end can receive the missing message segments, and then ensures that the data delivered by the receiving end to the receiving process is always in order and complete. Because the receiving end will never deliver an out-of-sequence and incomplete segment to the receiving process.

Corresponding state machine: Unable to reflect. Regardless of whether the timer expires or not, it is in the ESTABLISHED state.

Remarks: The description of RTT and RTO is as follows:
RTT (Round Trip Time): The round trip time of a connection, that is, the difference between the time when the data is sent and the time when the confirmation is received;
RTO (Retransmission Time Out): Retransmission time out, that is, from the moment of data transmission, retransmission will be performed after this time.
For the calculation method of RTO, please refer to RFC 6298.

3. Delayed ACK timer

purpose: Reduce the number of ACK packets and improve transmission efficiency. (The percentage of the payload of the ACK packet is too low)

Timer mechanism: Delayed response is also referred to as piggybacked ACK. This timer is used when delayed response. Why delay the response? Delayed response is to improve the efficiency of network transmission.
For example, after the server receives the data from the client, it does not return an ACK to the client immediately, but waits for a period of time (generally the maximum 200ms), so if the server needs data If sent to the client, then the ACK will be sent to the client together with the data from the server, which saves a packet of data compared to immediately returning an ACK to the client.

Corresponding state machine: Unable to reflect. Regardless of whether the timer expires or not, it is in the ESTABLISHED state.

4. Persist timer

purpose：Prevent no recovery after zero window.

Timer mechanism: We already know that TCP performs flow control by letting the receiver specify the number of data bytes (ie window size) that it wants to receive from the sender. What happens if the window size is 0? This will effectively prevent the sender from transmitting data until the window becomes non-zero. After the receiving end window becomes non-zero, an acknowledgement ACK will be sent to indicate the required segment number and window size.
If this confirmation ACK is lost, both parties may terminate the connection because they are waiting for each other: the receiver is waiting to receive data (because it has notified the sender of a non-zero window) , And the sender is waiting for a window update that allows it to continue sending data. To prevent this deadlock from happening, the sender uses a persistent timer to periodically query the receiver to find out whether the window has increased. These segments from the sender are called window probes.
The deadline of the persistence timer is set to the value of the retransmission time, but if no response from the receiver is received, another probe segment will be sent and the timer will be persisted The value of is doubled and reset, and the sender continues to send the probe segment, doubling and resetting the value of the persistence timer until the value increases to the threshold (usually 60 seconds). After that, the sender will send a segment every 60s until the window is reopened;

Corresponding state machine: Unable to reflect. Regardless of whether the timer expires or not, it is in the ESTABLISHED state.

5. Keepalive timer (keepalive timer)

purpose: Prevent dead links.

Timer mechanism: When SO_KEEPALIVE is specified when the TCP connection is established, the keep-alive timer will take effect.
Whenever the server receives information from the client, it resets the keeplive timer. The timeout is usually set to 2 hours. If the server has not received the information from the client for more than 2 hours, it will send a probe message If 10 probe segments are sent (one every 75 seconds) and no response is received, the connection is terminated.

Corresponding state machine: No timeout: ESTABLISHED, timeout: ESTABLISHED->FIN_WAIT_1.

Remarks: This is actually very impractical, because the default is 2 hours without data interaction before detecting, the time is too long. If you really want to confirm whether the peer is alive, you should implement the heartbeat packet yourself instead of relying on this keepalive timer.

6.FIN_WAIT_2 timer (FIN_WAIT_2 timer)

purpose: Prevent an exception during the close process, causing the resource to be unreleased

Timer mechanism: After the actively closed end calls close (that is, it sends FIN to the passively closed end and receives its confirmation ACK for FIN), it enters the FIN_WAIT_2 state. If at this time, due to the sudden network disconnection, a period of passive shutdown, etc., the actively closed end cannot receive the FIN from the passively closed end, the actively closed section cannot always be silly waiting, occupying resources. Let it go? At this time, the FIN_WAIT_2 timer is required. If the FIN from the passively closed end is not received when the timer expires, then I am sorry, no longer, just release the link. The time of the FIN_WAIT_2 timer can be viewed and set from /proc/sys/net/ipv4/tcp_fin_timeout.

Corresponding state machine: No timeout: FIN_WAIT_2->TIME_WAIT, timeout: FIN_WAIT_2->CLOSED.

7.TIME_WAIT timer (TIME_WAIT timer, also called 2MSL timer)

purpose: 1. Prevent the passively disconnected party from being unable to receive the last ACK and unable to release resources; 2. Prevent the newly released port from being used by the new connection, and the message of the old connection is delayed and sent to the new connection.

Timer mechanism: TIME_WAIT is the last state entered by the end actively closing the connection, instead of directly changing to the CLOSED state. Why? The first reason is that if the passively closed end does not receive the last ACK within the timeout period, the last FIN will be retransmitted. The 2MSL (maximum survival time of the message segment) waiting time ensures that the retransmitted FIN will be actively sent. The closed segment receives and resends the last ACK; another reason is that during the 2MSL waiting time, any late segment will be received and discarded to prevent packets from the old TCP connection from appearing in the new TCP connection. Inevitably, within this 2MSL waiting time, the same (source IP, source port, destination IP, destination port) connection will not be established.
If the active closing party receives the FIN+ACK segment retransmitted by the passive closing party within the waiting 2MSL time, the active closing party will resend the confirmation response message and restart 2MSL Timer until both parties in communication enter the CLOSED state.

Corresponding state machine: No timeout: TIME_WAIT->TIME_WAIT, timeout: TIME_WAIT->CLOSED.