TCP/IP详解-坚持定时器和保活定时器

1 坚持定时器
ACK的传输并不可靠。TCP不对ACK报文段进行确认，只确认那些包含有数据的ACK报文段

当接收窗口大小为0，并且接收方发送的窗口通告确认丢失了，那接收方等待接收数据，而发送方在等待允许它继续发送数据的窗口更新，这样就形成了死锁。

对该情况的解决方案：发送方使用一个坚持定时器来周期性地向接收方发送窗口探测报文，以便发现窗口是否已增大

上图这些探查被500ms的定时器超时例程所触发。当定时器到了，就发送窗口探查，并大约在4ms之后收到应答，然后定时器被重新启动，但下一个时钟滴答之间的时间约为500减4ms

计算坚持定时器使用普通的TCP指数退避

坚持定时器与重传超时之间的不同特点是TCP从不放弃发送窗口探查，这些探查每隔60秒发送一次，持续到窗口被打开或应用进程使用的连接被终止

2 糊涂窗口综合症
基于窗口的流量控制方案，会导致”糊涂窗口综合症”，从而少量数据通过连接进行交换，而不是满长度的报文段

在接收端和发送端采取的措施：
1)接收方不通告一个比当前窗口大的窗口，除非窗口可以增加一个报文段大小或可以增加接受缓冲空间的一半，不论实际有多少
2)发送端满足以下条件之一才发送报文:a)发送一个满长度的报文段 b)发送至少是接收通告窗口大小一半的报文段 c)可以发送任何数据并且不希望接收ACK或者改连接上不能使用Nagle算法

bsdi在第一次读数据前暂停4秒，之后每次读之前暂停2秒，而且接收方进行的是256字节的读操作

报文段13通告窗口为509字节，这看起来与
之前提到的策略不相符。之所以发发生这种情况，报文段11通告1533字节窗口，而发送方只使用了其中的1024字节。如果报文段13中的ACK通告窗口为0，就违反窗口的右边不能像左边沿移动而导致窗口收缩的TCP原则

报文段20发送原因：接受缓存中的可用空间从767变为2816，增加了2049字节，即接受缓存增加了其空间的一半，此时接收方发送窗口更新

3 保活定时器
许多时候一个服务器希望知道客户主机是否崩溃并关机或崩溃又重新启动，保活定时器就提供这个功能

在连接两个端系统的网络出现临时故障的时候，保活选项会引起一个实际上很好的连接终止。例如，如果在一个中间路由器崩溃并重新启动时发送保活探查，T P会认为客户的主机已经崩溃，而实际上所发生的并非如此。

一个说明现在需要使用保活功能的常见例子是当个人计算机用户使用TCP/IP向一个使用Telnet的主机注册时。如果在一天结束时，他们仅仅关闭了电源而没有注销，那么便会留下一个半开放的连接。通过一个半开放连接发送数据会导致返回一个复位，但那是在来自正在发送数据的客户端。如果客户已经消失了，使得在服务器上留下一个半开放连接，而服务器又在等待来自客户的数据，则服务器将永远等待下去。保活功能就是试图在服务器端检测到这种半开放的连接。

如果一个连接在两个小时之内没有任何动作，则服务器向客户发送探查报文。客户必须处于以下4中状态:
1)客户机依然正常运行，并从服务器可达。客户TCP响应正常，两小时内保活定时器复位。如果两小时内有数据交换，则在数据交换后的未来2小时再复位
2)客户机已经奔溃，并且关闭或正在重新启动，客户TCP没有响应。服务器收不到探查的响应，然后每隔75秒发送探查报文，总共发送10个，如果服务器没有收到一个响应，认为客户端已经关闭并终止连接
3)客户主机崩溃并已经重新启动，。这是服务器收到对其保活探查的响应，但是这个响应是一个复位，服务器终止连接
4)客户主机正常运行，但是从服务不可达，等同情况2

另一端崩溃：
返回给客户端额差错码为”连接超时”

tcpdump输出：

关机arp缓存情况

另一端奔溃并重新启动：
返回客户端的差错码为”连接被对端复位”

tcpdump输出：

另一端不可达：
可能是某个中间路由器崩溃
返回客户端的差错码为”没有到达主机的路由”

tcpdump输出：

最后

以上就是合适彩虹为你收集整理的TCP/IP详解-坚持定时器和保活定时器的全部内容，希望文章能够帮你解决TCP/IP详解-坚持定时器和保活定时器所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。