窗口缩放是什么
net.ipv4.tcp_window_scaling 控制是否启用 TCP 窗口缩放选项，默认开启。TCP 头部窗口字段只有 16 位，最大只能表示 65535 字节；窗口缩放把通告窗口按 2 的幂次放大，使接收方可以声明远大于 64KB 的窗口。它由双方在三次握手中交换缩放因子协商，任一侧不支持则该连接按 64KB 封顶。高带宽时延积链路（跨地域、卫星链路）上，窗口大小直接决定单连接能跑多快。
基本信息
| 参数 | net.ipv4.tcp_window_scaling |
|---|---|
| 默认值 | 1（开启） |
| 协商时机 | 三次握手时交换 wscale 值，只影响后续新建连接 |
| 上限关系 | 窗口实际大小还受接收缓冲制约，与 tcp_rmem 上限相关 |
| 吞吐关系 | 吞吐上限约等于窗口大小除以往返时延 |
| 观测方式 | ss -ti 显示连接的 wscale 值 |
典型使用场景
- 跨地域传输跑不满带宽：确认双方 wscale 是否都生效，排除窗口封顶
- 理解「越快越慢」现象：RTT 大而窗口小时，单连接吞吐被数学关系限制
- 兼容性验证：老设备不支持该选项时，需要确认对性能的实际影响
- 结合缓冲调优：窗口与接收缓冲要同步规划，只调其中一端无效
- 压测结果解读：单连接吞吐上不去时，先确认是窗口限制还是链路拥塞
查看与验证
查看与验证
sysctl net.ipv4.tcp_window_scaling # 读开关
ss -ti | grep -m5 wscale # 看连接的缩放因子（收发各一个值）
sysctl net.ipv4.tcp_rmem # 接收缓冲上限决定窗口天花板
# 吞吐上限 ≈ 窗口大小 / RTT；例如 6MB 窗口、100ms 时延约 480Mbps
sysctl net.ipv4.tcp_timestamps # 同为握手协商的常见选项，可一并核对现象与原因
| 现象 | 可能原因 | 验证方式 |
|---|---|---|
| 单连接吞吐上不去 | 窗口小于链路 BDP | 用 ss -ti 看 wscale 与缓冲使用情况 |
| wscale 一侧为零 | 对端不支持或禁用该选项 | 抓包看握手是否交换了该选项 |
| 窗口有余量但速度仍慢 | 瓶颈在丢包或拥塞控制 | 观察重传计数与拥塞窗口变化 |
| 短连接无改善 | 选项只在大窗口场景起作用 | 小请求场景瓶颈通常在延迟而非窗口 |
只有收发双方都声明缩放，连接才会真正使用大窗口；任一侧为零时窗口按 64KB 封顶。排查高延迟链路吞吐问题时，把双方的 wscale 都确认一遍是最快的排除步骤。
窗口大小并不等于实际传输量：它受接收缓冲上限与对端读取速度双重约束。窗口通告得大而应用读取慢时，数据仍然堆在接收侧缓冲里，最终表现为延迟增加而不是吞吐提升。