linux tcp窗口缩放通过协商缩放因子（0–14）将64kb窗口上限扩展至最大1gb，精准匹配高带宽长距离网络的大bdp需求，避免因窗口过小导致吞吐量被锁死；其生效需客户端和服务端均启用tcp_window_scaling、三次握手成功协商wscale选项、且接收缓冲区配置充足。
Linux TCP窗口缩放对性能的提升主要体现在高带宽、长距离或高延迟网络中，它能突破传统64KB接收窗口上限，使实际窗口最大达1GB，从而匹配大带宽延迟积（BDP）需求，避免链路“空转”。没有它，再高的带宽也跑不满。
为什么64KB窗口在现代网络中严重拖后腿
TCP头部窗口字段只有16位，原始最大值为65535字节（≈64KB）。但真实网络的BDP常远超此值：
- 1Gbps带宽 + 100ms RTT → BDP ≈ 12.5MB
- 10Gbps带宽 + 50ms RTT → BDP ≈ 62.5MB
- 卫星链路（500ms RTT）+ 1Gbps → BDP ≈ 62.5MB
若窗口卡在64KB，链路利用率可能低于1%，发送方频繁等待ACK，吞吐量被硬性锁死。
窗口缩放如何把性能拉回来
它在三次握手时协商一个缩放因子（0–14），将通告窗口左移该位数，实际窗口 = 报文中的窗口值 × 2wscale：
- wscale=7 → 窗口放大128倍 → 64KB × 128 = 8MB
- wscale=14 → 最大放大16384倍 → 64KB × 16384 ≈ 1GB
- 内核自动完成协商和换算，应用层看到的是已缩放后的实际窗口（如ss -i显示的rwnd）
真正起效需要满足三个条件
仅开启参数远远不够，必须同时满足：
- 两端都启用：
net.ipv4.tcp_window_scaling = 1（客户端和服务端都要设） - SYN/SYN-ACK中成功携带Window Scale选项（可用tcpdump验证，防中间设备剥离）
- 接收缓冲区足够大：
net.core.rmem_max和net.ipv4.tcp_rmem的最大值需 ≥ 目标窗口（例如设为32MB）
不调优就开缩放，反而可能白忙活
常见失效场景包括：
- 抓包看到SYN有wscale但rwnd始终是65536 → 接收缓冲区上限（rmem_max）太小，窗口被截断
- ss -i显示wscale=0或rwnd未增长 → 一端未启用，或防火墙/NAT丢弃了TCP选项
- 应用用默认socket，未调大SO_RCVBUF → 内核受限于tcp_rmem[2]，无法分配足够缓冲
建议搭配显式设置应用级接收缓冲（如setsockopt(SO_RCVBUF)）与合理内核参数，才能让缩放真正落地。
