最近复习计算机网络，发现TCP协议中的几个计时器不是很了解，写一篇文章供自己查阅理解
TCP中有四种计时器（Timer），分别为：
- 重传计时器：Retransmission Timer
- 坚持计时器：Persistent Timer
- 保活计时器：Keeplive Timer
- 时间等待计时器：Timer_Wait Timer
重传计时器（Retransmission Timer）
TCP的可靠传输是通过带确认的重传机制实现的。在滑动窗口中，接受窗口会在连续收到的包的最后一个序列发送一个ACK，但是在发生网络拥塞的时候，数据包和ACK有可能丢失。TCP为了防止这种情况发生，规定在重传的“时间片”到了以后。如果还没有收到客户端的ACK，就重发此包，以免陷入无限长的等待，也就是“死锁”状态中
-
目的：为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
-
创建时间：在TCP发送报文段时，会创建对次特定报文段的重传计时器。
-
可能发生的两种情况：
- 在截止时间（通常为60秒）到之前，已经收到了对此特定报文段的确认，则撤销计时器；
- 在截止时间到了，但未收到对此特定报文段的确认，则重传报文段，并且将计时器复位。
-
重传时间：2*RTT（Round Trip Time，为往返时间）通常是设置为2小时
坚持计时器（Persistent Timer）
在滑动窗口技术中，如果接收端的接受窗口满了，就会告诉发送端接受窗口满了，停止发送，这个时候，发送端和接收端的窗口都是置为0，这个状态称为“零窗口”状态。直到接受窗口收到了非零窗口大小的通知，但是这个通知有可能会丢失，如果丢失了，发送端会认为自己发送了调整接受窗口的通知，就等待接收端发来确认，两者由会永远等待对方。
-
解决方案：为了解决零窗口问题引起的死锁问题，TCP为每一个连接设置了坚持计时器。
-
目的：主要解决零窗口大小通知可能导致的死锁问题
-
工作原理：当发送端TCP收到接收端发来的零窗口通知时，就会启动坚持计时器。当计时器的期限到达时，发送端就会主动发送一个叫做探测报文段的特殊的报文段，这个报文段只有一个字节的数据。测报文段有一个序号，但它的序号永远不需要确认；甚至在计算机对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接受TCP：确认已丢失，必须重传。
-
坚持计时器值的设置：设置为重传时间的值。但如果没有收到接收端的响应，则会发送另一个探测报文段，并将计时器的值加倍并复位，直到大于门限值（一般为60秒）。在此之后，发送端会每隔60秒发送一个探测报文段，直到窗口重新打开。
保活计时器（Keeplive Timer）
如果客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远的处理打开状态。这个时候就要用到保活计时器
-
目的：主要是为了防止两个TCP连接出现长时间的空闲。
-
工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。
时间等待计时器（Timer_Wait Timer）
时间等待计时器是在四次挥手的时候使用的。
在第四次挥手的时候，客户端还要等待2MSL（MSL=maxinum segment lifetime最长报文生存时间，2MSL就是两倍的MSL）才能真正的关闭连接。
TCP的四次挥手
-
MSL(Maximum Segment Lifetime)即报文段最大生存时间
-
等待2MAL时间的目的：如果服务器端没有收到最后一个ACK字段，则会在超时后重发第三次挥手的FIN字段，主动关闭方接到重传的FIN字段会重新发送ACK。
-
处在TIME_WAIT状态的两端端口都不能使用，等到2MSL时间结束后才能继续使用。
-
当连接处于2MSL等待阶段时，有两个好处：一是任何迟到的报文段将会被丢弃。二是会有更大的机会让丢失的ACK字段再次被发送出去，让“四次挥手”更加可靠。
-
该状态设计在主动关闭方的理由：由主动关闭方发送最后一次ACK字段；只要由一方保持TIME_WAIT（时间等待）状态，就能起到避免连接在2MSL内重新建立，不需要双方都有
网友评论