In the TCP protocol, sometimes an event needs to be triggered regularly or according to an algorithm. At this time, the TCP protocol is implemented by using a timer. In TCP, there are four types of timers:
(1) Retransmission timer
(2) Hold timer
(3) Live timer
(4) Time waiting timer
These four timers have their own specific functions.
1： Retransmission timer
Retransmission timer: to control the lost message segment or the discarded message segment, that is, the waiting time for the confirmation of the message segment. When TCP sends a message segment, it creates a retransmission timer for the specific message segment. There are two possible situations: if the acknowledgement of the message segment is received before the timeout of the timer, the timer will be cancelled; if the timer expires before the acknowledgement of the specific message segment is received, the message will be retransmitted and the timer will be reset;
Retransmission time = 2 * RTT;
The value of RTT should be calculated dynamically. The commonly used formula is: RTT = previous RTT * I + (1-I) * current RTT. The value of I is usually 90%, i.e. the new RTT is 90% of the previous RTT value plus 10% of the current RTT value
Karn algorithm: for retransmission message, when calculating the new RTT, the RTT of retransmission message is not considered. Because it is impossible to infer whether the confirmation received by the sender is the confirmation of the last message segment or the confirmation of the retransmission message segment. Not at all.
2： Hold timer
Persistence timer is used after one side’s sliding window is 0, the other side stops transmitting data and enters the polling of persistence timer until the sliding window is no longer 0.
Let’s talk about the term, first of all, sliding window, which can be simply understood as the remaining space size of buffer. No matter write buffer or read buffer, once one side announces its sliding window size, the other side will transfer the window size data according to the sliding window size. However, when one side’s sliding window size is 0 when notified, the other side will start the persistence timer, basically using the TCP index backoff method, the first time is 1.5 seconds, the second time is 1.5×2 seconds, the third time is 1.5×4
The second is confused window syndrome. The symptom is caused by sliding windows. The cause is that the sender and receiver start data transmission when they are in a small sliding window. After the transmission, the consumption speed of reading and writing is not so fast, resulting in the next transmission, the sliding window is still so small. Then the phenomenon is that every time the data transmitted is very small. It’s like every train that leaves has only one carriage. In fact, we hope to save enough n carriages before transmission.
There is a solution to the confused window syndrome, and there are more than one, which can be solved by both the receiver and the sender. Roughly speaking, if the receiver solves the problem, when the receiving window is smaller than a certain size, the receiver will return the packet with window 0 to all the receiving requests to trigger the persistence timer of the other party. Similarly, the sender can only send when the data that can be sent is larger than a certain window.
3： Live timer
This is what we often call the keepalive of TCP. The actual use scenario is that when there is no data in the application layer for transmission, the packets that keep the heartbeat will be sent once every two hours (by default). If the transmission is successful, the port will continue to be active. If there is no normal return, the packets will be sent within the specified number of times (TCP keep alive probes, the default is 9 times) and the specified interval (TCP keep alive intvl, the default is 9 times) It’s 17s). If you don’t get a normal ack in the end, then the connection fails.
Of course, whether TCP needs to provide keepalive mechanism is controversial. We can set whether keepalive is enabled for each TCP connection and each indicator setting of keepalive.
4： Time waiting timer
When TCP closes the connection during the connection termination period, it does not mean that the connection is actually closed. During the time waiting period, the connection is still in an intermediate excessive state. In this way, the repeated fin message segments can be discarded after arriving at the end point. The value of this timer is usually set to twice the life expectancy of a message segment.
2msl timer: MSL is the maximum segment lifetime of a message segment. Setting this timer has two purposes:
One is to measure the time when the connection is in the time? Wait state. This allows TCP to send the last ack again to prevent the ACK from being lost (if lost, the other end will retransmit fin).
Second, in order to allow the old repeated segmentation to disappear in the network. Specifically, it can be explained that if a TCP connection has lost segment before disconnection, restart the same connection immediately after disconnection (both sides have the same IP address and port port), then the old segment of the previous lost segment may receive the new TCP connection, resulting in an undefined error. To avoid this, TCP specifies that a connection’s Avatar cannot be started when it is in the time “wait state. Since the time_wait state is maintained at 2msl, this ensures that the packets on a connection and the packets they should be in 2msl will disappear.
The above is about the explanation of four kinds of timers of TCP. If you have any questions, you can leave a message or go to the community of this site to discuss. Thank you for reading. I hope to help you. Thank you for your support!