前言
在有关TCP的章节中，介绍了四种定时器，它们体现了TCP的可靠性，其中最重要的 就是重传定时器了，剩下的定时器都是为了解决TCP的理解上的一些问题而设置的。
四种定时器：
- 2MSL定时器，出现在 TCP连接的建立与终止。
- 重传定时器，出现在 TCP的超时与重传。
- 坚持定时器。
- 保活定时器。
相关随笔：
2MSL定时器
出现：TCP连接的建立与终止 教材P183
四次挥手客户端一共有三次状态：应用程序关闭，发送完第一个FIN之后进入 FIN_WAIT1，之后接收到来自服务器的ACK进入 FIN_WAIT2。接收到来自服务器的FIN进入 TIME_WAIT 状态(又称2MSL等待状态)，使用2MSL定时器进行计时。
MSL：TCP实现选择的 一个报文段最大生存时间MSL。与IP的TTL类似。
RFC 793 指出MSL为2分钟，但是实际中常用值一般为 30s，1min，或者2min。
主要作用：在 TIME_WAIT状态 停留的时间为2倍的MSL。这样如果最后的ACK丢失 -> 另外一端(被动关闭)超时 重新发送FIN -> 可以让TCP重发最后一个ACK。
重传定时器
出现：TCP的超时与重传 教材P226-232
它对RTT和RTO的计算是整个 TCP超时与重传 中最重要的部分。
重传定时器，以RTO(Retransmission Timeout 重传超时时间)的时间来计时，一旦溢出超时即重发数据报。
这时就涉及到了RTT和RTO的计算了，这里有不同的策略：
正常接收到数据报：使用公式法计算RTT和RTO。
超时：采用指数退避策略。
公式法需要注意的是：采用了 被平滑的RTT估计器 和 均值偏差，降低了计算的误差。
主要作用：是TCP可靠性的体现，超时之后重传数据报，从而保证接收方能够接收到完整的数据。
坚持定时器
出现：TCP的坚持定时器 教材P245-250
当通知窗口为0的时候，发送方停止发送数据，等待接收方发送的非0的窗口更新。但是，如果这个非0的窗口更新丢失，会造成一种死锁的现象：发送方等待这个窗口更新的出现，而接收方等待发送方发送的数据。
为了防止这种死锁现象的发生，发送方使用一个 坚持定时器 来周期性地向接收方询问，以便发现窗口是否增大。这些发送的报文段称为 窗口探查。
在通告窗口设置为0之后，客户设置了 坚持定时器，在该定时器时间到时客户还没有接收到一个窗口更新，它就探查这个空的窗口以决定这个窗口更新是否丢弃。
计算坚持定时器使用了TCP指数退避策略。TCP从不放弃发送窗口探查，这些探查每隔60s发送一次。
主要作用：防止窗口更新造成的死锁现象。
保活定时器
出现：TCP的保活定时器 教材P251-255
一个比较让人惊讶的事实是：可以没有任何数据通过一个空闲的TCP连接，如果TCP连接的双方都没有向对方发送数据，那么在两个TCP模块之间不交换任何信息。
两个应用进程 -客户进程 和 服务器进程 都没有使用应用级的定时器来检测 非活动状态：这种非活动状态 可以导致应用程序中的任何一个 终止其活动。
许多时候，一个服务器希望知道客户主机是否 崩溃并关机，或者 崩溃又重新启动。许多实现提供的保活定时器可以提供这个能力。
优点：
(1)激活应用程序中的保活选项 通常比 编写应用程序探查报文 更简单。
(2)通过探查可以使服务器知道客户主机是否崩溃又重新启动。
(3)探查报文 比 应用程序探查报文 耗费更少的带宽。
缺点：
(1)在出现短暂错误的情况下，这可能会使一个非常好的连接释放掉。
(2)它们耗费不必要的带宽。
(3)在按分组计费的情况下，会在互联网花掉更多的钱。
主要作用：通过探查，使服务器知道另外一端的客户主机的运行状况。
具体实现参阅我之前的笔记。
2016/8/19