xmlns="http://www.w3.org/2000/svg"

style="display:

none;">

前言

来自于网友的一个问题，是有关《TCP

Analysis

ZeroWindowProbe》一个案例的讨论，话说当时我也没有注意这么细微的地方，因此简单讨论并进一步验证了下，算是一个新的小知识点。

问题背景

回顾一下

TCP

零窗口相关的实际上有三种信息，分别是：TCP

ZeroWindowProbe、TCP

ZeroWindowProbeAck。

实际运行环境中，有时是单独出现的，譬如TCP

ZeroWindow，有时是一起出现的，也就是出现了零窗口，之后就会出现需要为恢复窗口而进行的零窗口探测和零窗口探测确认。

其中一个案例如下：首先客户端发送数据，发现服务器接收窗口满了，则在

No.4

ZeroWindow]，之后陷入等待，大概

No.8[TCP

ZeroWindowProbe]用于确认服务器端接收窗口是否恢复，服务器紧接着回复确认

No.9，表示仍处于零窗口未恢复，标识为[TCP

ZeroWindowProbeAck]

14600，表示接收窗口已恢复，标识成[TCP

Window

Update]，至此完成一次完整的零窗口出现、探测及恢复过程。

No.8

秒+，是如何得来的，也就是什么时候会发送

TCP

零窗口探测包，自然是本端有数据需要发送，但如果发送失败，则需要检查是否需要启动零窗口探测定时器，而在满足一定条件下，会启动零窗口探测定时器，如果发生了超时则发送零窗口探测包，用来检查接收端的窗口大小是否仍为

或者是其他一个更新值，反之想如果本端一直没有数据需要发送，那额外关心接收端窗口是否为

Window

数据包进行通知。

所以答案也就比较明显了，第一次发送

TCP

数据包，实际上是发送端有需要发送的数据，但由于接收端零窗口所以发送失败，之后启动零窗口探测定时器，在超时后发送零窗口探测包，这个间隔时间就是应用写入数据的时间再加上零窗口探测定时器第一次超时的时间，和超时重传定时器一样，零窗口探测定时器也使用

RTO

和指数退避来计算超时时间。

验证时间，首先验证如果发送端一直没有数据发送，是否会存在一个定时器，在超时的时候就发送

TCP

#

执行脚本，同时通过

tcpdump

抓取数据包，现象如下，在客户端发送

Win

秒程序结束的时候，服务器端也就是发送端没有任何数据包发送。

#
packetdrill
/>
然后验证我们之前的结论，在零窗口数据包间隔
cat
#

执行脚本，同时通过

tcpdump

抓取数据包，现象如下，在客户端发送

Win

后服务器端也就是发送端发送了零窗口探测包，因为没有模拟零窗口探测确认包，所以不断超时不断重传。

#
packetdrill
尝试写入数据，再加上发送失败后，所启动的零窗口探测定时器发生超时的
/>
零窗口探测数据包，在
Wireshark
ZeroWindowProbe》有所提及。