0

当 TCP 数据流的接收者关闭其接收窗口（或者，更准确地说，窗口被发送者填充它而关闭）时，会有一连串的数据包被 Wireshark 识别为TCP ZeroWindow和TCP Keep-Alive（重复的具有相同序列号的 ACK ）。一段时间后，接收方将发送一个新的 ACK 以重新打开窗口 ( TCP Window Update)，数据将再次开始流动。

如果数据没有开始流动，什么 TCP 计时器机制确保重新传输窗口更新数据包？

这是我在连接结束时看到的数据包序列（预计会有更多数据）：

编号 时间 源 目的地 协议 长度 信息
 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 [重组 PDU 的 TCP 段]
 122163 21:24:37.445796 72.21.81.253 192.168.15.121 TCP 1514 [重组 PDU 的 TCP 段]
 122164 21:24:37.446087 72.21.81.253 192.168.15.121 TCP 1514 [重组 PDU 的 TCP 段]
 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 窗口已满] [重组 PDU 的 TCP 段]
 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 窗口更新] 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 可能在这件事上说了什么，大型 Internet 服务器在这方面做一些不同的事情是否（常见）做法，也许作为反 DoS 措施？

4

1 回答 1

3

正如您所指出的，一旦接收窗口中有可用空间，接收器就会发送一个新的 ACK 并更新窗口大小。

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

持久计时器的值没有明确指定，而是计算的往返时间和一些指数退避的函数。完整的细节在 RFC1122 的 4.2.2.14 部分，这里：https ://www.rfc-editor.org/rfc/rfc1122#page-92

提供的跟踪看起来像中间的东西正在阻止来自服务器的返回流量。我的猜测是您的 NAT 网关（192.168. . . .不是 Internet 上的有效地址，因此介于两者之间的某些东西正在进行网络地址转换）已决定连接已断开并拒绝从服务器转发其他数据包。

于 2013-10-31T20:25:09.163 回答