问题[tcp-window-scaling](server)

在 3 次握手期间，发送方 (10.16.0.128) 和接收方 (10.16.0.5) 分别通告其窗口大小为 42340 和 65535。

从第 3 个数据包 (syn+ack+ack) 开始，发送方再次通告窗口大小为 166，而接收方通告为 512。

您能否告诉我为什么窗口大小在不发送任何段的情况下减小了？每次确认时它都会不断变化吗？为什么他们在谈判期间没有承诺窗口大小。

    10.16.0.128.59570 > 10.16.0.5.22: Flags [S], cksum 0x7da0 (incorrect -> 0xf0a5), seq 2355031382, win 42340, options [mss 1460,sackOK,TS val 4284732064 ecr 0,nop,wscale 8], length 0

09:50:58.661172 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [S.], cksum 0x2d67 (correct), seq 1148159519, ack 2355031383, win 65535, options [mss 1460,sackOK,TS val 216174882 ecr 4284732064,nop,wscale 7], length 0

09:50:58.661229 IP (tos 0x0, ttl 64, id 49621, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.128.59570 > 10.16.0.5.22: Flags [.], cksum 0x7d98 (incorrect -> 0x5b8c), seq 1, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 0

09:50:58.661455 IP (tos 0x0, ttl 64, id 49622, offset 0, flags [DF], proto TCP (6), length 98)
    10.16.0.128.59570 > 10.16.0.5.22: Flags [P.], cksum 0x7dc6 (incorrect -> 0x5b5f), seq 1:47, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 46

09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0

09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
    10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0```

我之前问过类似的问题，但我相信我不清楚细节。

由于地理距离，我的服务器基本上存在一些与服务器和客户端之间的高延迟有关的问题。并进行了研究，结果证明我可以通过增加 TCP 窗口大小来解决这个问题。

问题是我真的不知道该怎么做，按照我在网上找到的说明根本没有帮助。

所以我希望有人可以分享一些文档/命令/说明或任何可以进一步改善这个问题的东西。

这是一些信息：

• 操作系统：Ubuntu 20.04 (LTS) x64
• 服务器：Apache/2.4.41
• 应用程序类型：Python - Flask
• 托管公司：数字海洋

编辑：在几个回复告诉我调整窗口大小不会解决问题之后，我想我还不够清楚。

在告诉我更改窗口大小不起作用之前，请参阅此答案。 https://networkengineering.stackexchange.com/a/2297/71565

如果您认为我误解了上面链接中的答案，请告诉我我特别出错的地方，不要只分享“它不起作用”等神秘回复。

我想我可能在窗口缩放 (RFC 1323) 方面遇到问题，希望有人能告诉我发生了什么事。

• 服务器： FreeBSD 9，apache22，提供一个 100MB 的静态 zip 文件。192.168.18.30
• 客户端： Mac OS X 10.6、Firefox 192.168.17.47
• 网络：它们之间只有一个开关——子网是 192.168.16/22（在这个测试中，我也有 dummynet 过滤模拟所有 IP 流量的 80ms ping 时间。我已经看到几乎相同的痕迹与“真实”设置，也有真实的互联网流量/延迟）

问题：

• 这看起来正常吗？
• 数据包 #2 是否指定了 65535 的窗口大小和 512 的比例？
• 数据包 #5 是否正在缩小窗口大小，以便它可以使用 512 比例并仍然保持总体计算窗口大小接近 64K？
• 为什么窗口比例这么高？

这是来自 wireshark 的前 6 个数据包。对于数据包 5 和 6，我包含了显示用于数据传输的窗口大小和比例因子的详细信息。

No. Time Source Destination Protocol Length Info

108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1

115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http > 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489

116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 > http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338

117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1

118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU]

细节：

Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309
Source port: http (80)
Destination port: 49190 (49190)
[Stream index: 4]
Sequence number: 1 (relative sequence number)
[Next sequence number: 310 (relative sequence number)]
Acknowledgement number: 425 (relative ack number)
Header length: 32 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 130
[Calculated window size: 66560]
[Window size scaling factor: 512]
Checksum: 0xd182 [validation disabled]
Options: (12 bytes)
No-Operation (NOP)
No-Operation (NOP)
Timestamps: TSval 2617517423, TSecr 945617490
[SEQ/ACK analysis]
TCP segment data (309 bytes)