tcp - 什么定时器阻止TCP窗口更新丢包

当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措施？

如您所述，一旦接收窗口有空间，接收方就会发送一个更新窗口大小的新ACK。

为了处理ACK丢失的情况，发送者保留一个＆＃34;持久定时器＆＃34;偶尔会重新传输数据包（＆＃34;窗口探测器＆＃34;）以测试水域并查看是否确实存在未报告的接收空间。

未明确指定持久定时器的值，而是计算的往返时间和某些指数退避的函数。有关详细信息，请参阅第4.2.2.14节中的RFC1122，此处：http://tools.ietf.org/html/rfc1122#page-92

提供的跟踪看起来像是阻止来自服务器的返回流量。我的猜测是你的NAT网关（192.168。。不是因特网上的有效地址，因此介于两者之间的网络地址转换）已经决定连接已经消失并且拒绝转发其他数据包从服务器返回。

什么定时器阻止TCP窗口更新丢包

1 个答案: