第22章 TCP的坚持定时器
22.2 一个例子
为了观察到实际中的坚持定时器，我们启动一个接收进程。它监听来自客户的连接请求，接受该连接请求，然后在从网上读取数据前休眠很长一段时间。
s o c k程序可以通过指定一个暂停选项 - P使服务器在接受连接和进行第一次读动作之间进入休眠。我们以这种方式调用服务器：
svr4 % sock -i -s -P100000 5555
该命令在从网络上读数据之前休眠 100 000秒（2 7 . 8小时）。客户运行在主机 b s d i上，并向服务器的5 5 5 5端口执行1 0 2 4字节的写操作。图2 2 - 1给出了t c p d u m p的输出结果（我们已经在结果中去掉了连接的建立过程）。
报文段1 ~ 1 3显示的是从客户到服务器的正常的数据传输过程，有 9 2 1 6个字节的数据填充了窗口。服务器通告窗口大小为 4 0 9 6字节，且默认的插口缓存大小为 4 0 9 6字节。但实际上它一共接收了9 2 1 6字节的数据，这是在S V R 4中T C P代码和流子系统(stream subsystem)之间某种形式交互的结果。
在报文段1 3中，服务器确认了前面 4个数据报文段，然后通告窗口为 0，从而使客户停止发送任何其他的数据。这就引起客户设置其坚持定时器。如果在该定时器时间到时客户还没有接收到一个窗口更新，它就探查这个空的窗口以决定窗口更新是否丢失。由于服务器进程处于休眠状态，所以T C P缓存9 2 1 6字节的数据并等待应用进程读取。
请注意客户发出的窗口探查之间的时间间隔。在收到一个大小为 0的窗口通告后的第 1个（报文段1 4）间隔为4 . 9 4 9秒，下一个（报文段1 6）间隔是4 . 9 9 6秒，随后的间隔分别约为 6, 12,24, 48和6 0秒。
为什么这些间隔总是比5、6、1 2、2 4、4 8和6 0小一个零点几秒呢？因为这些探查被T C P的500 ms定时器超时例程所触发。当定时器时间到时，就发送窗口探查，并大约在4 ms之后收到一个应答。接收到应答使得定时器被重新启动，但到下一个时钟滴答之间的时间则约为5 0 0减4 ms。
计算坚持定时器时使用了普通的 T C P指数退避。对一个典型的局域网连接，首次超时时间算出来是1 . 5秒，第2次的超时值增加一倍，为 3秒，再下次乘以 4为6秒，之后再乘以 8为1 2秒等。但是坚持定时器总是在 5 ~ 6 0秒之间，这与我们在图2 2 - 1中观察到的现象一致。
窗口探查包含一个字节的数据（序号为 9 2 1 7）。T C P总是允许在关闭连接前发送一个字节的数据。请注意，尽管如此，所返回的窗口为 0的A C K并不是确认该字节（它们确认了包括9 2 1 6在内的所有数据），因此这个字节被持续重传。
坚持状态与第 2 1章中介绍的重传超时之间一个不同的特点就是 T C P从不放弃发送窗口探查。这些探查每隔 6 0秒发送一次，这个过程将持续到或者窗口被打开，或者应用进程使用的连接被终止。
