[TCP / IP] seven kinds of timers

[TCP / IP] seven kinds of timers

Establishes a connection timer (connection-establishment timer)


   As the name suggests, this timer is used when the connection is established, we know, TCP requires three-way handshake to establish a connection, as shown below: 

   Process of establishing the connection, while sending a SYN, starts a timer (default should be three seconds), if the SYN packet is lost, it will resend SYN packets after 3 seconds (of course, will start a new timer arranged into six second timeout), of course, it would not have been made endless SYN packet in / proc / sys / net / ipv4 / tcp_syn_retries may be provided in the end SYN packet to be retransmitted several times.

Retransmission timer (retransmission timer)


   The retransmission timer setting data is transmitted in TCP, after the timer expires without receipt of the returned acknowledgment ACK, the transmitting side will resend queue segment to be retransmitted. RTO retransmission timer used generally have the following rules:

When TCP sends a transmit queue is located in the forefront of the segment after the start RTO timer;
if the queue is empty timer is stopped, or restart the timer;
When the timer expires, TCP will retransmit the forefront of the send queue segment;
when one or more integrated segment is confirmed, this or these segments are removed from the queue
   retransmission timer to ensure that the receiving end can receive the missing segment, in turn, to ensure that the receiving end data delivered to the receiving process always ordered complete. Because the receiver will never put a disorder incomplete segment delivered to the receiving process.

Delayed Answer Timer (delayed ACK timer)
   

    Delayed response also known as piggyback ACK, the timer is used when the delayed response. Why delay the response it? Delayed response is to improve the efficiency of the network.

   Illustration, such as the server receives data from the client, not immediately return ACK to the client, but some time (usually a maximum 200ms), so if the server if the data needs to be sent to the client, and then the ACK on data sent to the server with the client, so than immediately back to the client saves an ACK packet.

Adhere to the timer (persist timer)
   

    We already know that TCP by the recipient to indicate that you want to control the flow of data from a number of bytes received by the sender (ie, the window size). If the window size is 0 what would happen? This effectively prevents the transmission of the data sender, until the window becomes non-zero so far. After the receive window becomes non-zero, it sends an acknowledgment message ACK segment sequence number and a window size specified needs.

   If this acknowledgment ACK lost, then wait for the other two sides is possible because the connection is terminated: waiting for the recipient to receive data (because it has advertised a non-zero window to the sender), while the sender waits allow it to continue to send DataWindow update. To prevent this deadlock situation, the sender uses a stick timer (persist timer) for periodically polling to the receiver in order to detect whether the window has been increased. These segments sent from the sender called probe window (window probe).

Keep alive timer (keepalive timer)


   When the TCP connection is established specifies SO_KEEPALIVE, keep-alive timer to take effect. If the client and server data exchange long time, you need to keep alive timer to determine whether the peer is still alive, but this is actually very practical, because the default is 2 hours not only exchange data detection, time is too long . If you really want to confirm whether the peer alive, you should implement your own heartbeat package, rather than relying on the keep-alive timer.

FIN_WAIT_2 timer (FIN_WAIT_2 timer)


   After the closed end of the active call completion close (i.e., to send FIN passive end closed, and has received its acknowledgment ACK to the FIN) proceeds FIN_WAIT_2 state. If this time because the network suddenly cut off, passive shut down for some other reasons, led the initiative to close one end of the closed end of the passive can not receive incoming FIN, take the initiative to shut down period can not always wait around, resources are not occupied doing nothing, right? This time you need to run for FIN_WAIT_2 timer, if the timer expires, or did not receive passive closed end sent a FIN, then I am sorry, ranging from the direct release of this link. FIN_WAIT_2 timer time can view and settings from / proc / sys / net / ipv4 / tcp_fin_timeout in.

TIME_WAIT timer (TIME_WAIT timer, also known as 2MSL timer)


   TIME_WAIT is actively closed end of the connection and finally into the state, rather than directly into the CLOSED state, and why? The first reason is shut down in case of a passive end of the last ACK is not received within the timeout period, it resends the final FIN, 2MSL (segment maximum survival time) to ensure that the waiting time will be retransmitted FIN initiative off period of the last received and re-transmitted the ACK; another reason is that when the waiting time 2MSL any late segment are received and discarded, to prevent the old packet in the TCP connection appears inside a new TCP connection. Inevitably, in this 2MSL waiting time, the same connection is not established (the IP source, source port, destination IP, destination port).

Guess you like

Origin blog.csdn.net/bible_reader/article/details/95919812