TCP 四种定时器（重传定时器，坚持计时器，保活定时器，时间等待计时器）
<p><strong>TCP 四种定时器</strong></p><p><strong>重传定时器</strong></p>
<p>主要为了防止报文丢失或者阻塞。当A向B发送报文时，就会启动重传定时器，若在定时器到达之后，仍没有收到B的确认报文，则A会重新发送上次发送的报文。同时，令重传定时器复位。继续计时。</p>
<p><strong>坚持计时器</strong></p>
<p>此计时器针对下面场景： <br />
</p>
<p>当B向A发送了0窗口报文，B此时已经没有空间接受A发送的数据了，通知A停止发送。A在收到后即停止发送，等待一段时间后，B有了一些空间，可以继续接收了。此时再向A发送非0窗口报文。如果此非0窗口报文在网络中阻塞或者丢失了,那么A将永远以为B没有空间接收数据，B也永远在等待A发来的数据。这样就会造成死锁的局面。 <br />
</p>
<p>在A接收到B发送的0窗口报文后，就设立坚持定时器，当定时器到达后，A就像B发送一个探测报文。B收到探测报文后会给出A确认报文。</p>
<p>* 确认报文中的窗口值不是0，则死锁局面打开。<br />
* 确认报文中的窗口值是0，则重置坚持定时器，并将时间翻倍，但是最大不能超过60秒。（到达60后，以后都是60秒）<br />
* A在发送探测报文后，启动重传定时器，若没有收到B的确认报文，则重传探测报文。<br />
</p>
<p><strong>保活定时器</strong></p>
<p>应用场景：客户机因为某些故障退出，而服务器并不知道，还在一直等待客户机发来的数据，这样就白白浪费了计算机资源。</p>
<p>在服务器端设置保活计时器，服务器每收到客户机的一次消息，就重置保活计时器，时间通常为2小时。若2个小时都没有收到客户机发来的消息，服务器就像客户机发送一个探测报文，以后每隔75分钟发送一次。若连续发送了10个探测报文后客户机仍无响应，则服务器就会认为客户机故障，并断开这次连接。</p>
<p><strong>时间等待计时器</strong></p>
<p>时间等待及时器用于TCP“四次挥手”阶段。当客户端向服务器发送最后一次确认报文时，就设定一个时间等待及时器，等待2MSL时间后再结束连接。 <br />
</p>
<p>MSL：最长报文段寿命，大小为30s~2分钟。根据不同的应用有不同的设置。</p>
<p><strong>客户机为什么要等待2MSL时间？</strong></p>
<p>①为了保证服务器能够收到客户机发送的最后一个确认报文。 <br />
</p>
<p>因为这个最后报文可能丢失，服务器收不到客户机的确认信息，就无法进入CLOSED状态。就会在重传定时器到达后重新发送上一次的报文（此时会重置时间等待计时器，再次等待2MSL时间），这样客户机在等待2MSL时间过程中就可以收到这个重传报文，并重新发送确认报文。 <br />
</p>
<p>②防止出现“已失效的连接请求报文”再次出现的情况。 <br />
</p>
<p>客户机在等待的这2MSL时间中，就可以使此次连接的所有报文都从网络中消失，这样在下一次新的连接中就不会出现旧的连接请求报文。</p>
<p>感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！</p>
<div class="art_xg">
<b>您可能感兴趣的文章:</b><ul><li>Android进程保活之提升进程优先级</li><li>C# 定时器保活机制引起的内存泄露问题解决</li><li>Android 后台运行白名单实现保活</li><li>node后端服务保活的实现</li><li>详解Android 8.0以上系统应用如何保活</li><li>Android应用保活实践详解</li><li>详解Android进程保活的方法</li><li>详解App保活实现原理</li></ul>
</div>
</div>
<!--endmain-->
頁:
[1]