当TCP数据流的接收器关闭其接收窗口时（或者更确切地说，窗口由发送器填满它关闭窗口），将会有一堆数据包，Wireshark将其识别为 TCP ZeroWindow 和 TCP Keep-Alive （重复使用相同的ACK）序列号） . 一段时间后，接收器将发送新的ACK以重新打开窗口（ TCP Window Update ），数据将再次开始流动 .
什么TCP计时器机制确保如果数据没有开始流动，则重新传输窗口更新数据包？
以下是我在连接结束时看到的数据包序列（需要更多数据）：
No. Time Source Destination Protocol Length Info
122160 21:24:37.421824 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2984241 Win=5152 Len=0
122162 21:24:37.445528 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122163 21:24:37.445796 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122164 21:24:37.446087 72.21.81.253 192.168.15.121 TCP 1514 [TCP segment of a reassembled PDU]
122171 21:24:37.481802 192.168.15.121 72.21.81.253 TCP 60 41200 > http [ACK] Seq=462 Ack=2988621 Win=784 Len=0
122184 21:24:37.744838 72.21.81.253 192.168.15.121 TCP 838 [TCP Window Full] [TCP segment of a reassembled PDU]
122185 21:24:37.745048 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122190 21:24:38.014841 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122191 21:24:38.014993 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122232 21:24:38.534437 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122233 21:24:38.534599 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122314 21:24:39.564525 72.21.81.253 192.168.15.121 TCP 60 [TCP Keep-Alive] http > 41200 [ACK] Seq=2989404 Ack=462 Win=15872 Len=0
122315 21:24:39.564680 192.168.15.121 72.21.81.253 TCP 60 [TCP ZeroWindow] 41200 > http [ACK] Seq=462 Ack=2989405 Win=0 Len=0
122361 21:24:43.403052 192.168.15.121 72.21.81.253 TCP 60 [TCP Window Update] 41200 > http [ACK] Seq=462 Ack=2989405 Win=119904 Len=0
122892 21:25:45.161896 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122902 21:25:45.373289 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122927 21:25:45.813267 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122936 21:25:46.693275 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
122956 21:25:48.453337 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123009 21:25:51.983392 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123061 21:25:59.033566 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123262 21:26:13.153852 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
123460 21:26:41.394469 192.168.15.121 72.21.81.253 TCP 60 41200 > http [FIN, ACK] Seq=462 Ack=2989405 Win=186720 Len=0
接收器在21:24:43重新打开窗口，听到发送者的更多信息 . 一分钟后，接收器超时连接（关闭由应用程序启动）并发送一系列仍未确认的FIN-ACK .
看起来简单地丢失了与发送者的通信（捕获是在接收者的网络上进行的） . 如果没有，那么即使经过一段足够长的时间让对等方忘记连接，我们是否应该总是期望对FIN-ACK进行确认？
尽管RFC1122可能会就此问题发表意见，但大型互联网服务器在这方面采取不同的做法（通常）是否可以作为反DoS措施？
1 回答
如您所述，一旦接收窗口中有空间可用，接收器就会发送一个具有更新窗口大小的新ACK .
为了处理ACK丢失的情况，发送方保留一个“持久定时器”，偶尔会重新发送一个数据包（“窗口探测器”），以便测试水域并查看是否确实存在未报告的接收空间 .
持久定时器的值未明确指定，而是计算的往返时间和一些指数退避的函数 . 有关详细信息，请参阅第4.2.2.14节中的RFC1122，此处：http://tools.ietf.org/html/rfc1122#page-92
提供的跟踪看起来像是阻止来自服务器的返回流量 . 我的猜测是你的NAT网关（192.168 ..不是互联网上的有效地址，所以介于两者之间正在进行网络地址转换）已经决定连接已经消失，并且拒绝从服务器转发其他数据包 .