窗口缩放是什么
TCP 报头里的窗口字段只有 16 位，最大 65535 字节；在高时延大带宽链路上这个上限会直接限制吞吐，于是引入了窗口缩放选项：双方在握手中各自声明一个移位值，之后的窗口字段要乘以 2 的该次幂才是真实窗口。未协商成功时，窗口就封顶在 64KB 以内。
基本信息
| 标准依据 | RFC 7323 |
|---|---|
| 抓包字段 | tcp.options.wscale.shift，取值 0 到 14 |
| 换算关系 | 实际窗口 = 窗口字段值 × 2 的移位次幂 |
| 吞吐关系 | 可达吞吐上限约等于实际窗口除以往返时延 |
| 协商时机 | 只在握手阶段交换一次 |
典型使用场景
- 长距离链路上吞吐上不去，确认窗口是否被封顶
- 核对两端声明的移位值是否一致
- 评估接收缓冲是否与窗口放大倍数匹配
- 排查中间设备阻断该选项导致两侧行为不一致
- 为跨地域传输调优提供依据
换算与观察
换算与观察
实际窗口 = 窗口字段值 × 2^shift
例：字段 65535 × 2^7 约等于 8MB
可达吞吐上限 约等于 实际窗口 ÷ RTT
tcp.options.wscale.shift # 查看握手声明的移位值
tcp.window_size # 查看窗口字段观察项与说明
| 观察项 | 含义 | 说明 |
|---|---|---|
| 握手含缩放选项 | 双方支持放大窗口 | 缺失时窗口封顶 64KB |
| 移位值较大 | 适配高时延链路 | 接收缓冲需同步加大 |
| 显示窗口数值很大 | 通常已按缩放还原 | 换算时不要重复相乘 |
| 窗口够大但吞吐仍低 | 瓶颈在丢包或拥塞 | 继续查重传情况 |
缩放只在握手阶段协商，中间设备阻断该选项会造成两侧行为不一致。
调大窗口需要接收缓冲同步支持，否则零窗口会更早出现。
补充要点
- 先确认窗口是否真的受限，再考虑调整缓冲，顺序反了会白费功夫
- 把窗口与往返时延相乘，判断现有配置能否覆盖链路带宽时延积
- 窗口放大后若出现零窗口，说明接收缓冲没跟上窗口设置
- 两端移位值不一致时，判读窗口数值要格外小心
分析脚本中换算窗口时，务必确认数据来源是否已经按缩放还原，避免重复计算。