为什么我收到缩小窗口的 tcp 段？答案

【问题标题】：Why I receive tcp segment that shrink the window?为什么我收到缩小窗口的 tcp 段？
【发布时间】：2019-04-14 04:07:31
【问题描述】：

我在笔记本电脑上使用 Wireshark 捕获数据包，发现服务器发送的数据包缩小了其接收窗口。这是从我的 ubuntu18.04 到“connectivity-check.ubuntu.com”的连接。

我阅读了 rfc793 和 TCPIP Illustrated volumn1，都说“强烈建议不要缩小窗口”。

这是 Wireshark 的输出。我在 Wireshark 中禁用 HTTP 解析以防止分心。

   4198 0.026547255    2019-04-03 12:27:48.870761715 192.168.3.141         35.222.85.5           TCP      74     53846 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=3960112411 TSecr=0 WS=128
   4199 0.281380222    2019-04-03 12:27:49.152141937 35.222.85.5           192.168.3.141         TCP      74     80 → 53846 [SYN, ACK] Seq=0 Ack=1 Win=28160 Len=0 MSS=1412 SACK_PERM=1 TSval=2281826280 TSecr=3960112411 WS=128
   4200 0.000092140    2019-04-03 12:27:49.152234077 192.168.3.141         35.222.85.5           TCP      66     53846 → 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=3960112693 TSecr=2281826280
   4201 0.000191823    2019-04-03 12:27:49.152425900 192.168.3.141         35.222.85.5           TCP      153    53846 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=87 TSval=3960112693 TSecr=2281826280
   4202 0.306769219    2019-04-03 12:27:49.459195119 35.222.85.5           192.168.3.141         TCP      66     80 → 53846 [ACK] Seq=1 Ack=88 Win=26112 Len=0 TSval=2281826585 TSecr=3960112693
   4203 0.000076022    2019-04-03 12:27:49.459271141 35.222.85.5           192.168.3.141         TCP      214    80 → 53846 [PSH, ACK] Seq=1 Ack=88 Win=26112 Len=148 TSval=2281826586 TSecr=3960112693
   4204 0.000028644    2019-04-03 12:27:49.459299785 192.168.3.141         35.222.85.5           TCP      66     53846 → 80 [ACK] Seq=88 Ack=149 Win=30336 Len=0 TSval=3960113000 TSecr=2281826586
   4205 0.000045328    2019-04-03 12:27:49.459345113 35.222.85.5           192.168.3.141         TCP      66     80 → 53846 [FIN, ACK] Seq=149 Ack=88 Win=26112 Len=0 TSval=2281826586 TSecr=3960112693
   4206 0.000183562    2019-04-03 12:27:49.459528675 192.168.3.141         35.222.85.5           TCP      66     53846 → 80 [FIN, ACK] Seq=88 Ack=150 Win=30336 Len=0 TSval=3960113000 TSecr=2281826586
   4207 0.245163856    2019-04-03 12:27:49.704692531 35.222.85.5           192.168.3.141         TCP      66     80 → 53846 [ACK] Seq=150 Ack=89 Win=26112 Len=0 TSval=2281826890 TSecr=3960113000

正如捕获的结果所示，来自服务器的第 4199 帧广告了一个大小为 28160 的窗口，但是在 4201 中接收到 87 个字节的数据后，窗口在 4202 中缩小到 26112，正好等于 2048（这是因为服务器只是换出了一个内存页？）

我想知道服务器缩小其 TCP 接收窗口的原因是什么？ RFC 非常不鼓励这种行为，我认为这种行为不会在操作系统的 TCPIP 堆栈中实现。

【问题讨论】：

可能是rfc1323中定义的窗口缩放选项。我没有详细阅读。
不，这不是窗口缩放的意思。
好吧，我想如果在 3WHS 期间就窗口缩放达成一致，则在完成 3WHS 后窗口可能会发生变化。 syn/ack 中的第一个通告窗口可能是未缩放的，然后 4201 中的第二个窗口被缩放。不鼓励某事并不意味着不允许。 IW10 是标准的，但许多使用更高的 IW。
@FormerNcp 不，这不是窗口缩放的工作原理。一旦同意缩放，所有窗口都会被缩放。对于一个问题，这已经足够猜测了。

标签： tcp

【解决方案1】：

这是正常行为。当服务器在其缓冲区中接收到数据并且无法立即将其发送到应用层时，它会减小通告窗口大小以防止丢弃接收到的数据包。 您将此预期行为与窗口缩小问题混淆了，当我们将发送方缓冲区的右边缘向左移动时会发生这种问题。

你可以参考这个以获得更多关于窗口收缩问题的指导：http://www.tcpipguide.com/free/t_TCPWindowManagementIssues.htm

【讨论】：

感谢您的回答:)。但我并不混淆这两个概念。在我展示的捕获结果中，窗口大小减少了“2048”，但服务器只收到了“87”字节的数据。所以右边缘确实向左移动。
哦...我明白了.. 我误解了这个问题。看起来你是正确的，右边缘向左移动。