One, the introduction

In TCP, there is usually a timer similar to the heartbeat to ensure that the transmission is normal. TCP manages four different timers for each connection.

  • Timing retransmission;
  • Persist timer;
  • Keepalive timer;
  • 2MSL timer, used to measure connections in TIME_WAIT state.

Here are three.

2. Timing retransmission timer

TCP provides a reliable transport layer. One of the methods it uses is to acknowledge the data received from the other end. But data and validation can be lost. TCP solves this problem by setting a timer when sending. If no acknowledgement is received when the timer overflows, it retransmits the data. For each connection, the starting serial number of the data in the message segment is also recorded. When an acknowledgement containing the sequence number is received, the timer is turned off. If the data is not retransmitted when ACK arrives, the smoothed RTT and smoothed mean deviation are updated based on this new measurement.

Persist Timer

We’ve seen how TCP controls traffic on the sender by letting the receiver specify the window size. When the window size is 0, the sender will not send data until the receiver sends an ACK notification for a non-0 window size. But what happens when this ACK is lost? The size of the sender window is 0, and the receiver thinks that the sender’s sending window is not 0. The two remained deadlocked until the connection was closed. That’s a problem! To prevent such deadlocks, on every TCP connection, the sender periodically checks with the receiver to see if the window has grown. This is called the persist timer.

4. Keepalive Timer

We would be surprised to find that no data can flow over an idle TCP connection. That is, if neither party to a TCP connection is sending data to the other, no information is exchanged between the two TCP modules. For example, there is no polling that can be found in other network protocols. This means that we can start a client and establish a connection with the server, and then go away for hours, days, weeks, or months with the connection remaining. However, many times a server wants to know if the client host crashed and shut down or crashed and restarted. Many implementations provide keepalive timers that provide this capability. This is the life timer. In fact, keepalive timers are not recommended in RPC, and many people believe that this functionality should not be provided in TCP if needed, but should be done by applications. In most protocols, this is also turned off for the following reasons:

  • In the case of a momentary error, this might free up a perfectly good connection;
  • They consume unnecessary bandwidth;
  • You spend more money on the Internet when you charge by packet.

Survivability is primarily provided for server applications. The server application wants to know if the client host has crashed so that it can use resources on behalf of the client. In short, a Keepalive timer is a heartbeat packet that we often encounter. It can be implemented in the application layer when needed.

See here, do you want to scan the QR code to follow the wechat public account Linwan Village Dragon cat.