我想我可能遇到了窗口缩放(RFC 1323)的问题,希望有人可以告诉我发生了什么。
- 服务器:FreeBSD 9,apache22,提供静态 100MB zip 文件。192.168.18.30
- 客户:Mac OS X 10.6,火狐 192.168.17.47
- 网络:它们之间只有一个交换机 - 子网是 192.168.16/22(在这个测试中,我还使用了虚拟网络过滤,模拟所有 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)
答案1
1.) 512 并不是真正的高窗口比例 - 它只是表示将提供的窗口大小向左移动 9 位。将窗口大小设置为 130(否则是一个非常非常低的值),然后应用比例因子 512 可得到 66560(130<<9)。
2.) 100M 可能太小了。事实上,规模已经协商好了,这表明一切正常。尝试更大的文件以更好地观察行为。如果没有其他选择,您将更好地了解实际吞吐量。
3.) 还要记住,特定客户端的行为实际上可以明确地覆盖操作系统的行为 - 例如,Solaris 中的内置 FTP 客户端用于将窗口大小限制为 64K,而不管操作系统如何配置。
答案2
我从系统管理员团队那里得知,这个问题是由 VMWare 网络驱动程序不尊重/不很好地执行 sysctl 可调参数而引起的。在物理硬件上使用相同设置的吞吐量具有合理的管道百分比,而不是我们在 VMware 上看到的 1/10 或更少。