TCP定时器

一、定时器

在TCP/IP协议栈中，因为重传，等待，确认的情况，很多都会用带定时器，所以定时器是TCP/IP协议栈中一个至关重要的“部件”，在很多时候都仰仗定时器来确认一个请求。最明显的大概就是TCP/IP协议栈中的四次挥手时的timewait时刻了，主动发起断开连接的一端，在等待timewait时间无回应后，即断开连接。这个时候的timewait就使用了一个定时器。 

二、常见的几个定时器

1.连接建立(connection establishment)定时器

TCP协议的三次握手中客户端会给服务器端发送一个SYN报文，此时客户端等待服务器响应，如果达到“连接建立定时器”定时时间时，还没有收到响应，即认为没有连接成功。

重传(retransmission)定时器

TCP传输中，每次数据报文的传输后，都会开启一个对应的重传定时器，如果在定时器时间内没有收到对端响应，即认为对端没有收到这个报文，则对这个报文进行重传。重传定时器的时间是动态计算的，与RTT（往返时延）有紧密联系。 往返时延——即从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

延迟ACK(delayed ACK)定时器

在报文传输时，接收端收到一个必须应答的报文，但又不必立刻确认，此时延迟ACK定时器开始计时，在定时时间内，如果有报文需要发送，则确实应答跟随报文一起传输；如果定时器超时，此时接收端需要单独发送一个确认应答。

持续 (persist)定时器

发送端在发送数据时，收到对端通告窗口大小为0，即此时无法继续接受数据，所以发送端停止发送数据，并打开持续定时器进行计时，超时后，对对端发送一字节数据，判断对端窗口是否已有足空间接受数据。 窗口的通告并不可靠，因为在发送时，只有发送的数据才会被对端确认，而ACK不会被对端确认，所以即使对端已经通告窗口为0，但此时或许还有没有被确认的ACK在窗口移动后产生的空间。

保活(keep alive)定时器

两个端相连后，如果在一段时间内，没有开始正常的数据传输，则保活定时器开始计时，超时后，立刻向对端发送一个报文，强迫对端做出应答。如果对端做出应答，则继续保证两端之间的通信；如果收到RST，则认为对端重启；如果连续多次没有收到回应，则认为对端主机崩溃。单步法确认故障原因。 

FIN_WAIT_2定时器

某个连接从FIN_WAIT_1的状态变为FIN_WAIT_2的状态后，如果也不再接受任何数据后，定时器第一次定时，如果超时后，还没有发送任何数据，则第二次计时开始。第二次计时结束后，二者连接被关闭。 这个定时器主要用于TCP四次挥手中的FIN报文发送时的场景。 本人假设一个场景以便于理解（如果不正确还请大神指出）：在四次挥手途中，一端突然关机或其他操作导致无法正常发送报文，此时对端回一直等待FIN报文，浪费网络资源，如果这个定时器起作用，则会主动断开连接。

TIME_WAIT定时器

即在timewait时刻的定时器。进入timewait状态时开启定时，超时后断开连接。 因为在主动发送端最终会停留在timewait，等待一段时间，这个时间是报文最长存活时间的二倍，才会确认对端确实已经断开，然后断开本端的连接，当前的端口才能重复使用。