TCP的计时器

TCP在建立连接后会启动四个定时器：

重传计时器：Retransmission Timer 
坚持计时器：Persistent Timer 
保活计时器：Keeplive Timer 
2MSL定时器：Time_Wait Timer

1、重传计时器 
TCP的发送方没有在规定的时间内收到确认就要重传已发送的报文段。这种重传概念很容易理解，但重传时间的选择却不简单。 
如果吧超时重传的时间这是的太短，就会引起很多报文段不必要的重传，是网络负荷量增加。但若设置的太长，使网络的空闲时间增大，降低了传输效率。 
TCP采用了一种自适应算法，它记录每一个报文段发出的时间，以及收到相应的确认的时间，这两个时间差就是豹纹的往返时间RTT。 
重传时间 = 2*RTT； 
RTT是动态计算的： 
RTT=旧的 RTT*i + (1-i)*当前RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10% 
Kam算法：在计算加权平均RTTs时，只要报文重传了，就不在采用其往返时间样本。 
2、坚持计时器 
坚持定时器是使用在一方滑动窗口为0之后，另外一方停止传输数据，进入坚持定时器的轮询，直到滑动窗口不再为0了。 
首先是滑动窗口，可以简单理解为缓冲区剩余空间大小。不管是写缓冲还是读缓冲，一旦一方通告了自己的滑动窗口大小，另外一方就会根据滑动窗口大小传递窗口大小的数据了。但是，当被通告，一方的滑动窗口大小为0的时候，另外一方就会启动坚持定时器，基本也是使用TCP指数退避方法，第一次1.5秒，第二次1.5x2秒，第三次1.5x4… 
其次是糊涂窗口综合症。这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。 
糊涂窗口综合症有解决办法，还不止一种，在接收方或者发送方都可以解决。大致就是如果接收方解决，那么接收方在接收窗口小于一定大小的时候，对所有的接收请求都返回窗口为0的包，来触发另外一方的坚持定时器。同样发送方也是，在可以发送的数据大于一定窗口的时候才发送。

3、保活计时器 
每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段(每75秒发送一个)还没收到响应，则终止连接。

4、2MSL定时器 
MSL是报文段最大生存时间(Maximum Segment Lifetime),设置这个定时器有两个目的其一是为了测量连接处于TIME_WAIT状态的时间.这样可以让TCP再次发送最后的ACK以防止这个ACK丢失(如果丢失，另一端会重传FIN)。其二，为允许老的重复分节在网络中消逝。具体可以解释为，如果一个TCP连接在断开之前有迷途分节尚未消逝，在断开该TCP连接之后立刻重启一个同样的连接(双方的IP地址和端口port相同)，这时之前的迷途的老分节可能对新的新的TCP连接接收，从而造成未定义的错误。为了避免这种情况，TCP规定在TIME_WAIT状态，不能启动一个连接的化身。既然TIME_WAIT状态维持2MSL，这就保证了一个连接上的分组及其应该在2MSL内都会消失。