wireshark 和 tcpdump -r：奇怪的 tcp 窗口大小
我正在使用 tcpdump 捕获 http 流量，并且对 TCP 慢启动以及窗口大小如何增加感兴趣：
$ sudo tcpdump -i eth1 -w wget++.tcpdump tcp and port 80
当我使用 Wireshark 查看转储文件时，窗口大小的进展看起来很正常，即 5840、5888、5888、8576、11264 等。 ..
但是当我通过查看转储文件时，
$ tcpdump -r wget++.tcpdump -tnN | less
我得到了似乎无意义的窗口大小（为简洁起见，省略了IP地址）：
: S 1069713761:1069713761(0) win 5840 <mss 1460,sackOK,timestamp 24220583 0,nop,wscale 7>
: S 1198053215:1198053215(0) ack 1069713762 win 5672 <mss 1430,sackOK,timestamp 2485833728 24220583,nop,wscale 6>
: . ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . 1:1419(1418) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: P 1419:2002(583) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . ack 1419 win 133 <nop,nop,timestamp 2485833824 24220604>
: . ack 2002 win 178 <nop,nop,timestamp 2485833830 24220604>
有没有办法在命令行上获取正常/绝对窗口大小？
I'm capturing http traffic with tcpdump and am interested in TCP slow start and how window sizes increase:
$ sudo tcpdump -i eth1 -w wget++.tcpdump tcp and port 80
When I view the dump file with Wireshark the progression of window sizes looks normal, i.e. 5840, 5888, 5888, 8576, 11264, etc...
But when I view the dump file via
$ tcpdump -r wget++.tcpdump -tnN | less
I get what seem to be nonsensical windows sizes ( IP addresses omitted for brevity ):
: S 1069713761:1069713761(0) win 5840 <mss 1460,sackOK,timestamp 24220583 0,nop,wscale 7>
: S 1198053215:1198053215(0) ack 1069713762 win 5672 <mss 1430,sackOK,timestamp 2485833728 24220583,nop,wscale 6>
: . ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . 1:1419(1418) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: P 1419:2002(583) ack 1 win 46 <nop,nop,timestamp 24220604 2485833728>
: . ack 1419 win 133 <nop,nop,timestamp 2485833824 24220604>
: . ack 2002 win 178 <nop,nop,timestamp 2485833830 24220604>
Is there a way to get normal / absolute window sizes on the command line?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
窗口大小是正确的 - 它们只是未缩放。
连接发起者已将
wscale（窗口缩放因子）设置为 7，因此其后续的win值必须乘以 128 才能获得以字节为单位的窗口大小。因此，win 46表示 5888 字节的窗口。连接接收方已将
wscale设置为 6，因此其win值必须乘以 64。因此win 133表示 8512 字节的窗口，win 178表示 11392 字节。The window sizes are correct - they're just unscaled.
The connection initiator has set a
wscale(window scaling factor) of 7, so its subsequentwinvalues must be multiplied by 128 to get the window size in bytes. Thus thewin 46indicates a window of 5888 bytes.The connection recipient has set a
wscaleof 6, so itswinvalues must be multiplied by 64. Thuswin 133indicates a window of 8512 bytes, andwin 178indicates 11392 bytes.另外，如果工具（wireshark或tcpdump，没关系）没有看到syn，它必须打印未缩放的值，这可能会欺骗你
Also, if the tool (wireshark or tcpdump, it doesn't matter) doesn't see the syn, it has to print the unscaled value, which can fool you