Timer in TCP

In TCP, the timer 1. connection establishment "starts when a new connection is established when the SYN packet segment is sent. If no response is received within 75 seconds, connection establishment will be aborted. 2. The retransmission timer is set when a data segment is sent over TCP. If the timer times out and the peer confirmation is not reached, TCP retransmits the data segment. The value of the retransmission timer (that is, the time for TCP to wait for peer confirmation) is dynamically calculated, which is closely related to the RTT estimation value and also depends on the number of times the packets have been retransmitted. 3. The "delayed ACK (delayed ACK)" timer is set when TCP receives data that must be confirmed but does not need to be confirmed immediately. If there is data to be sent over the connection within ms, the delayed ACK response can be sent back to the peer end along with the data, which is called accept with confirmation. If this confirmation fails to be taken out after ms, the timer times out and an immediate confirmation is sent. 4. The "persist" timer is set when the receiving window of the notification to the peer end is 0 to prevent TCP from sending data. The window announcements sent by the connection peer are not reliable (only data is confirmed and ACK is not confirmed). Subsequent window updates that allow TCP to send data may be lost. Therefore, if TCP has data to be sent, but the Receiving Window of the Peer notification is 0, the timer starts continuously, and 1 byte of data is sent to the peer after the timeout, determines whether the Receiving Window of the peer is opened. 5. The "keep alive" timer takes effect when the SOF_KEEPALIVE option is set in the so_options field of the TCP Control Block. If the consecutive idle time of the connection exceeds 2 hours, the active timer times out. In this case, the connection detection packet segment should be sent to the peer end to force the Peer to respond. If you receive the expected response, TCP can determine that the Peer host is working normally. TCP will not perform a life-saving test until the connection is idle for more than two hours. If you receive an RST Reset response, TCP determines that the Peer host has restarted. If no response is received for several consecutive active standbys, TCP assumes that the Peer host has crashed, but it cannot distinguish between host failure and connection failure. 6. The FIN_WAIT_2 timer starts when a connection changes from the FIN_WAIT_1 state to the FIN_WAIT_2 State and cannot receive any new data. It is set to 10 minutes. After the timer times out, It is reset to 75 seconds, and the connection is closed after the second time out. The purpose of this timer is to prevent a connection from staying in the FIN _ WAIT _ 2 state forever if the peer side does not send any FIN. (assuming TCP does not use the semi-open function ). 7. TIME_WAIT timer is also called 2MSL timer. 2MSL refers to two times the MSL, that is, the maximum message segment survival time. When the connection is transferred to the TIME_WAIT status, that is, when the connection is closed, the timer starts. The reason for 2MSL waiting is described in the status transition diagram. When the connection enters the TIME_WAIT status, the timer is set to 1 minute. After the timeout, the TCP Control Block is deleted and the port number can be used again.