TCP的四种定时器

TCP在建立连接后会启动四个定时器：重传计时器：Retransmission Timer 坚持计时器：Persistent Timer 保活计时器：Keeplive Timer 时间等待计时器：Time_Wait Timer

1、重传计时器

为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器;若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位;TCP的发送方没有在规定的时间内收到确认就要重传已发送的报文段。这种重传概念很容易理解，但重传时间的选择却不简单。 如果把超时重传的时间设置的太短，就会引起很多报文段不必要的重传，是网络负荷量增加。但若设置的太长，使网络的空闲时间增大，降低了传输效率。

TCP采用了一种自适应算法，它记录每一个报文段发出的时间，以及收到相应的确认的时间，这两个时间差就是报文的往返时间RTT。
重传时间 = 2*RTT；
RTT是动态计算的：
RTT=旧的 RTT*i + (1-i)*当前RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10%

Karn算法：
对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。在计算加权平均RTTs时，只要报文重传了，就不在采用其往返时间样本。

2、坚持计时器 （在发送方）

专门为对付零窗口通知而设立的。
首先是滑动窗口，可以简单理解为缓冲区剩余空间大小。不管是写缓冲还是读缓冲，一旦一方通告了自己的滑动窗口大小，另外一方就会根据滑动窗口大小传递窗口大小的数据了。但是，当被通告，一方的滑动窗口大小为0的时候，另外一方就会启动坚持定时器。
当发送端收到零窗口的确认时，就启动坚持计时器，当坚持计时器截止期到时，发送端TCP就发送一个特殊的报文段，叫探测报文段，这个报文段只有一个 字节的数据。探测报文段有序号，但序号永远不需要确认，甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP，确认已丢失，必须重传。 坚持计时器的截止期设置为重传时间的值，但若没有收到从接收端来的响应，则发送另一个探测报文段，并将坚持计时器的值加倍和并复位，发送端继续发送 探测报文段，将坚持计时器的值加倍和复位，知道这个值增大到阈值为止(通常为60秒)。之后，发送端每隔60s就发送一个报文段，直到窗口重新打开为止; 补充： 坚持定时器的原理是简单的，当TCP服务器收到了客户端的0滑动窗口报文的时候，就启动一个定时器来计时，并在定时器溢出的时候向客户端查询窗口 是否已经增大，如果得到非零的窗口就重新开始发送数据，如果得到0窗口就再开一个新的定时器准备下一次查询。通过观察可以得知，TCP的坚持定时器使用 1，2，4，8，16……64秒这样的普通指数退避序列来作为每一次的溢出时间。

其次是糊涂窗口综合症。这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。从而影响网络利用率。
糊涂窗口综合症有解决办法，还不止一种，在接收方或者发送方都可以解决。大致就是如果接收方解决，那么接收方在接收窗口小于一定大小的时候，对所有的接收请求都返回窗口为0的包，来触发另外一方的坚持定时器。同样发送方也是，在可以发送的数据大于一定窗口的时候才发送。

再次补充： TCP通过让接收方指明希望从发送方接收的数据字节数(即窗口大小)来进行流量控制。如果窗口大小为 0会发生什么情况呢?这将有效地阻止发送方传送数据，直到窗口变为非0为止。 TCP不对ACK报文段进行确认， TCP只确认那些包含有数据的ACK报文段。 如果一个确认丢失了(这个确认是”接收方“向”发送方“发送的ACK，通知”发送方“自己的窗口已经非0了)，则双方就有可能因为等待对方而使连接 终止：接收方等待接收数据(因为它已经向发送方通告了一个非 0的窗口)，而发送方在等待允许它继续发送数据的窗口更新。为防止这种死锁情况的发生，发送方使用一个坚持定时器 (persist timer)来周期性地向接收方查询，以便发现窗口是否已增大。这些从发送方发出的报文段称为窗口探查 (window probe)。

3、保活计时器

keeplive timer 每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段(每75秒发送一个)还没收到响应，则终止连接。 补充： 保活定时器更加的简单，还记得FTP或者Http服务器都有Sesstion Time机制么?因为TCP是面向连接的，所以就会出现只连接不传送数据的“半开放连接”，服务器当然要检测到这种连接并且在某些情况下释放这种连接，这 就是保活定时器的作用。其实现根据服务器的实现不同而不同。另外要提到的是，当其中一端如果崩溃并重新启动的情况下，如果收到该端“前生”的保活探察，则 要发送一个RST数据报文帮助另一端结束连接。

4、（时间等待计时器）2MSL定时器

Time_Wait Timer 在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以使重复的 FIN 报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。 补充： 2MSL定时器：MSL是报文段最大生存时间(Maximum Segment Lifetime),设置这个定时器有两个目的： 其一是为了测量连接处于TIME_WAIT状态的时间.这样可以让TCP再次发送最后的ACK以防止这个ACK丢失(如果丢失，另一端会重传FIN)。 其二，为允许老的重复分节在网络中消逝。具体可以解释为，如果一个TCP连接在断开之前有迷途分节尚未消逝，在断开该TCP连接之后立刻重启一个同样的连接(双方的IP地址和端口port相同)，这时之前的迷途的老分节可能对新的TCP连接接收，从而造成未定义的错误。为了避免这种情况，TCP 规定在TIME_WAIT状态，不能启动一个连接的化身。既然TIME_WAIT状态维持2MSL，这就保证了一个连接上的分组及其应该在 2MSL内都会消失。