39

  通过前面的窗口收缩和糊涂窗口综合征的学习，我们知道，当接收方不想接收数据时，可以发送为rwnd为0的报文段来暂时关闭窗口，如图1中所示。

  此时，发送方实际上并没有真的把窗口收缩了，只是暂停发送数据，直到收到一个新的报文（rwnd大于0）通告，才会开始发送数据。当接收方发送了一个rwnd = 10的ACK确认报文，但是在传输过程中丢失了，（注意：此时接收方不会重传，因为tcp规定对于没有携带数据的ACK确认报文段不会进行重传），而接收方却并不知道这个ack确认报文丢失了，还一直等待发送方发送数据过来，这时发送方由于没有收到对方rwnd大于0的报文，也会一直等待接收方发送。这样双方就都在一直傻傻的等待，陷入了一个死锁的状态。

  为了避免图1中这种不必要的等待，而导致tcp连接终止。tcp使用了一个持续计时器，当发送方收到了窗口为0的确认，就会启动一个持续计时器，如果在计时器规定的时间内没有收到窗口更新的报文（持续计时器超时后），就会发送一个探测报文，这个报文只有一个字节的数据（报文中的序号）。这个探测报文的作用是用于探测接收方的窗口，并以此判断窗口更新的报文是否丢失。

  另外，持续计时器的超时时间是设置为重传时间的值，然后每次持续计时器超时后还没收到对方窗口更新的报文，就发送一个探测报文，同时持续计时器的超时时间将加倍。也就是说，持续计时器的超时时间设置采用了超时计时器的指数退避算法策略，当然这个值并不会无限增加下去，当超时时间达到门限值（一般为60秒）就不会再增长了，而是每隔60秒再发送一次探测报文。

关于实验环境如下图所示：

  下面我们把client和server之间交互的数据包，通过wireshark软件抓取下来，并分析数据包，图中黑色部分的数据包是标记出来要重点分析的。

  这里我们直接从330数据包开始分析，我们发现server向client发送了一个TCP ZeroWindow的报文，且通告的窗口大小为0字节。这个报文的意思就是，server告诉发送方：“接收缓存满了，不要再发送数据了”，当client接收到这个报文时就应该停止发送数据，并启动持续计时器开始计时。在持续计时器超时后，client会发送一个TCP ZeroWindowPro的探测报文（这个探测报文中的序号会消耗一个字节数据）。

  前面我们说过，持续计时器的超时时间的设置就是重传时间（RTO），因此我们可以计算一下持续计时器第一次超时时间为：超时时间 = 18.948669000 - 18.650208000 = 0.298461000 s，大概是298ms。

  client接着又发送了一个探测报文（334报文），那么再计算持续计时器第二次超时时间为：超时时间 = 19.549089000 - 18.950338000 = 0.598751 s，大概是598ms，这说明了持续计时器的超时时间设置确实是采用了指数退避算法策略。

  另外在图5中可以发现，client在发送一个TCP ZeroWindowPro的探测报文时，同时也会诱导server发送一个探测报文的确认报文（也就是TCP ZeroWindowProACK报文），在这个确认报文中携带了当前的接收窗口大小，下面我们来看一下332这个确认报文的具体信息，重点关注TCP Analysis选项。

   在图6中可知，当server的应用进程从缓存中读走了数据时，server的缓存就会腾出一些空余的空间出来，这时server会发送一个窗口更新的报文，即TCP Window Update报文，然后client接收到这个TCP Window Update报文就会设置发送窗口大小并发送数据。

特别说明：   关于本篇中介绍的持续计时器本来是没有对应的实验，后来是得到一位大神的启发，才把这个实验加了进来。这里大家也可以思考一下：应该怎么设计这个实验，然后复现出来。

  关于TCP ZeroWindow，TCP ZeroWindowProACK，TCP Window Update的详细说明，资料参考自：（https://blog.csdn.net/dog250/article/details/51865031）