TCP定时器

一、常见的四种TCP定时器
1、超时重传计时器
2、坚持计时器
3、保活计时器
4、时间等待计时器
二、四个定时器的特点和应用场景
1、超时重传计时器（Retransmission Timer）
超时重传计时器：为了控制丢失的报文段，设置的一种定时器。发送端在将TCP报文发送出去之后会等待目标端对该报文的确认，此时等待的结果有两种：当超过定时器设置的时间还没有收到确认的话，则认为刚才发送的报文丢失了，需要重新传送，并将定时器复位，如果重新传送之后还是没有收到对端的确认，则进行再次重传，一般第一次重传是在发现超时后1s，第二次重传是在第一次重传后3s，第三次重传是在第二次重传后6s…；如果在重传定时器到期之前收到了对端的确认，则撤销已经设置好的重传定时器。
几点注意事项：
（1）发送端在发送完报文段之后，必须保留该报文段的副本，为发生超时重传时使用，之后在收到对端确认之后，才可以销毁该副本。
（2）发送出去的报文段和确认报文段都要进行编号，这样才能确定是哪一个报文段收到了对端确认，哪一个报文段没有收到对端确认。
（3）超时重传定时器设置的重传时间应该比报文段传输的往返时间更长一些。但是重传时间应该如何设定呢？
重传时间=2*RTT
RTT的值应该动态计算：RTT=previous RTT*i+current RTT *(1-i) 其中i通常等于90%，这个公式的意思是RTT的值等于上一次RTT值的90%加上当前RTT值的10%
Karn算法：对于重传报文，在计算新的RTT值时，不考虑重传报文的RTT值，因为无法确认发送端的确认是对上一次传送保温==报文的确认还是对重传报文的确认。
2、坚持计时器（persistent timer）
坚持计时器是专门为零窗口设立的，它的具体应用场景是，当接收端的滑动窗口为0时，发送端就停止传输数据并进入坚持计时器的轮询，直到接收端的滑动窗口不再为0。
当坚持计时器的时间到期之后，发送端就给接收端发送一个探测报文段，该探测报文段中只有一个字节，并且该探测报文段是有序号的，意思是告诉接收端，对零滑动窗口的确认已经失效，必须重传。
坚持计时器的定时时间设置为重传时间，当定时时间到了之后还没有收到对端的确认就继续发送探测报文段，并将定时时间加倍并复位，依此类推，直到定时间超过阈值(60s)之后，就每隔60s发送一个探测报文段，知道接收端的窗口打开为止，
3、保活计时器（keeplive timer）
该计时器侧重保持客户端和服务端的连接，当一方断开连接时，另一方超过保活定时器的定时时间（2小时）还没有收到对端的消息时就会发送探测报文段给另外一方，当发送了10个报文段（每隔75s发送一个）还没有收到对方的消息就断开连接。设想一下，如果tcp层没有keepalive的机制，一旦一方断开连接却没有发送FIN给另外一方的话，那么另外一方会一直以为这个连接还是存活的，几天，几月。那么这对服务器资源的影响是很大的。
4、时间等待计时器（Time_Wait Timer）
因为TCP连接是双向的，因此在关闭连接时，双方都需要关闭，。先发FIN包的一方执行的是主动关闭；后发FIN包的一方执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL（报文的最大生存周期，在Linux下一般为30s）时长。
为什么主动关闭的一方不直接进入CLOSED状态，而是进入TIME_ WAIT状态，并且停留两倍的MSL时长呢？这是因为TCP是建立在不可靠网络上的可靠的协议。例子：主动关闭的一方收到被动关闭的一方发出的FIN包后，回应ACK包，同时进入TIME_ WAIT状态，但是因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_ WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：
旧的TCP连接已经不存在了，系统此时只能返回RST包
新的TCP连接被建立起来了，延迟包可能干扰新的连接
不管是哪种情况都会让TCP不再可靠，所以TIME_WAIT状态有存在的必要性。