TCP persistence Timer

Introduction

TCP allows the receiver to specify the number of data bytes (that is, the window size) to be received from the sender for traffic control. What happens if the window size is 0? This effectively prevents the sender from transmitting data until the window is not 0.
TCP does not confirm the ACK packet segment. TCP only confirms the ACK packet segments containing data.
If a confirmation is lost, the two parties may terminate the connection because they are waiting for the other party: the receiver waits for receiving data (because it has advertised a non-zero window to the sender ), while the sender is waiting for a window update that allows it to continue sending data. To prevent this deadlock, the sender uses a persistence timer (persist timer) to periodically query the receiver to see if the window has increased. These message segments sent from the sender are called Window probe ).

Example

To observe the timer, we start a receiving process. It listens to connection requests from customers, accepts connection requests, and then sleeps for a long time before reading data from the Internet.
SockProgramYou can specify a suspend option-P to enable the server to sleep between accepting connections and performing the first read operation. We call the server in this way:

 
Svr4 % sock-I-s-p1000005555
 

This command sleep for 100 seconds (27.8 hours) before reading data from the network ). The customer runs on the host bsdi and writes 5555 bytes to port 1024 of the server. The output result of tcpdump is given (we have removed the connection establishment process in the result ).
Packet segment 1 ~ 1 3 shows the normal data transmission process from the customer to the server, with 9216 bytes of data filled in the window. The server Notification window size is 4096 bytes, and the default plug-in cache size is 4096 bytes. But in fact it receives a total of 9216 bytes of data, which is in the S v R 4 TCPCodeThe result of some form of interaction with the stream subsystem.
In packet segment 1 3, the server confirms the first four data packet segments, and then the announcement window is 0, so that the customer stops sending any other data. This causes the customer to set its persistence timer. If the customer does not receive a window update when the timer time arrives, it explores the empty window to determine whether the window update is lost. Because the server process is in sleep state, TCP caches 9216 bytes of data and waits for the application process to read it.
Note the time interval between the customer's window probes. After receiving a window announcement with a size of 0, the 1st (packet segment 1 4) interval is 4.949 seconds, and the next (packet segment 16) interval is 4.996 seconds, the subsequent intervals are about 6, 12, 24, 48, and 60 seconds respectively.

Why are these intervals always a few seconds shorter than 5, 6, 12, 24, 48, and 60? Because these probes are triggered by TCP's 500 ms timer timeout routine. When the timer time arrives, the system sends a window probe and receives a response about 4 ms later.
when a response is received, the timer is restarted, but the time between the next tick is about 500 minus 4 ms. The ordinary TCP index backoff is used for calculating the persistence timer. For a typical LAN connection, the first timeout is calculated as 1. the timeout value of 5 seconds and 2nd times is doubled to 3 seconds. Multiply the value of 4 to 6 seconds, and then multiply the value of 8 to 1 and 2 seconds. However, the timer is always in the range of 5 to 5 ~ Between 6 and 0 seconds, which is consistent with the observed phenomenon.
the window probing contains one byte of data (sequence number: 9 2 1 7 ). TCP always allows sending a byte of data before closing the connection. Note that, even so, the ACK with the returned window 0 does not confirm this byte (they confirm all data including 9216), so this byte is continuously retransmitted.
the difference between persistence and Retransmission timeout is that TCP never gives up sending window probing. These probes are sent every 60 seconds. This process continues until the window is opened or the connection used by the application process is terminated.