TCP的定时器

TCP的定时器

在TCP协议中有的时候需要定期或者按照某个算法对某个事件进行触发，那么这个时候，TCP协议是使用定时器进行实现的。在TCP中，会有四种定时器：

• 重传定时器
• 坚持定时器
• 保活定时器
• 2MSL定时器

这四个定时器都有各自的具体作用。

重传定时器

TCP是可靠的，因此，它对于发出去的信息，没有得到正常ACK反馈的，都会启动一个重传机制。这个重传机制使用一个重传定时器，当发现在规定时间内，没有收到ACK，那么，重新发送消息，如果还没有收到ACK，继续重新发送消息...当然，这每次继续重新发送消息的时间间隔是不一样的。一般默认，第一次重传是发现超时后1s，第二次重传是第一次重传后3s，第三次是6s...

说回术语，重传定时器最重要的计算数值叫RTO(Retransmission Timeout, 重传超时时间)。这个重传超时时间又是根据RTT(Round Trip Time, 连接往返时间)计算出来的。然后呢，这个RTT不是固定设置的，是计算机根据不同的网络情况和机器情况测量出来的。在RFC中，对RTT，RTO的算法有详细的说明。

坚持定时器

坚持定时器是使用在一方滑动窗口为0之后，另外一方停止传输数据，进入坚持定时器的轮询，直到滑动窗口不再为0了。

说说术语，首先是滑动窗口，可以简单理解为缓冲区剩余空间大小。不管是写缓冲还是读缓冲，一旦一方通告了自己的滑动窗口大小，另外一方就会根据滑动窗口大小传递窗口大小的数据了。但是，当被通告，一方的滑动窗口大小为0的时候，另外一方就会启动坚持定时器，基本也是使用TCP指数退避方法，第一次1.5秒，第二次1.5x2秒，第三次1.5x4...

其次是糊涂窗口综合症。这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。

糊涂窗口综合症有解决办法，还不止一种，在接收方或者发送方都可以解决。大致就是如果接收方解决，那么接收方在接收窗口小于一定大小的时候，对所有的接收请求都返回窗口为0的包，来触发另外一方的坚持定时器。同样发送方也是，在可以发送的数据大于一定窗口的时候才发送。

保活定时器

这个就是我们经常说的tcp的keepalive了。实际使用场景是在应用层没有数据进行传输的时候，一定时间（tcp_keepalive_time，默认每2个小时）发送一次保持心跳的包，如果发送成功，则继续保持端口活跃，如果没有正常返回，则在指定次数内（tcp_keepalive_probes，默认是9次），指定间隔（tcp_keepalive_intvl，默认是17s）发送心跳包。如果最后都没有获得正常的ACK，那么才算连接失败。

当然，tcp是否需要提供keepalive机制，是有争议的，我们可以为每个tcp连接设置是否启用keepalive和启用keepalive的各个指标设置。参考大话keepalive

2MSL定时器

这个定时器用在TCP四次挥手之后，主动发起TCP断开的一方需要保持2MSL的TIME_WAIT的状态。这个保持的一方就会开启2MSL定时器来计算TIME_WAIT的状态保持时间。

至于为什么会有2MSL的TIME_WAIT，主要是考虑到四次挥手的最后一个ACK包对方没有收到，那么对方会重发FIN包，这么一来一回就是2倍的MSL时长。具体参考再叙TIME_WAIT

参考文章：

TCP/IP详解
TCP/IP详解学习笔记(13)-TCP坚持定时器，TCP保活定时器
TCP 的那些事儿（下）
TCP/IP重传超时--RTO