TCP定时器

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

    重传计时器：Retransmission Timer

    坚持计时器：Persistent Timer

    保活计时器：Keeplive Timer

    时间等待计时器：Time_Wait Timer

1）重传定时器

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

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

2）坚持定时器

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

    就是首先是滑动窗口，可以简单理解为缓冲区剩余空间大小。不管是写缓冲还是读缓冲，一旦一方通告了自己的滑动窗口大小，另外一方就会根据滑动窗口大小传递窗口大小的数据了。但是，当被通告，一方的滑动窗口大小为0的时候，另外一方就会启动坚持定时器，基本也是使用TCP指数退避方法，第一次1.5秒，第二次1.5x2秒，第三次1.5x4...
    其次是糊涂窗口综合症。这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。

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

3）保活定时器

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

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

4）时间等待定时器

    在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。