10G 链路只跑到 5.8G：TCP 接收窗口小于带宽延迟积，一次跨机房吞吐瓶颈的定位与调参

结论先行：跨机房 / 高 RTT 场景下「链路明明是 10G、实测却只跑到 5~6G、丢包 0、CPU 不高、换 BBR 也没用」，十有八九不是网络问题，而是 TCP 接收窗口（rwnd）小于带宽延迟积（BDP）——吞吐被 窗口 / RTT 这个公式从天花板压死了。这类故障 ping 全绿、iperf 单流测不出带宽、抓包看不到丢包，最容易骗过所有人。本文是一次真实的跨城大文件同步吞吐排查，从「以为是链路慢」一路挖到 net.ipv4.tcp_rmem 的 max 值。

一、现象：10G 链路，单流只跑到 5.6G，怎么都上不去

3 月我们做异地灾备，把一套 120GB 的数据集从 A 城同步到 B 城（跨城专线 10Gbps，实测 RTT 稳定 8.2ms）。要求「1 小时内传完」，但实测：

• iperf3 -c <peer> -t 30 -P 1 单流稳定 5.6 Gbps，离 10G 差了近一半；
• ethtool eth0 | grep Speed → 10000Mb/s，链路协商没问题；
• 两端 sar -n DEV 1 看网卡，发送侧没打满、没丢包、没错包；
• 换 CUBIC → BBR 重测，吞吐一个字节没变；
• 并发 -P 4 一下冲到 9.1G —— 这一下让我意识到问题不在「带宽」。

关键反直觉点：4 并发能跑到 9G，单并发却只有 5.6G。这说明链路有带宽，是「单条流」被某个上限卡住了。

二、原理：吞吐 = 窗口 / RTT，窗口小于 BDP 就封顶

TCP 的吞吐上限由在途字节数（窗口）决定：最大吞吐 ≈ 窗口 / RTT。要把链路跑满，在途字节数必须 ≥ 带宽 × RTT，这个量叫带宽延迟积 BDP：

• BDP = 10 Gbps × 8.2 ms = 82 Mbit ≈ 10.25 MB
• 而 cat /proc/sys/net/ipv4/tcp_rmem 输出 4096 131072 6291456，第三个值 max = 6 MB
• 单流上限 = 6 MB / 8.2 ms ≈ 730 MB/s ≈ 5.8 Gbps

理论值 5.8G 和实测 5.6G 严丝合缝。根因清楚了：接收窗 max 只有 6MB，而这条链路要跑满需要 ≥10MB 的窗口，差了近一倍，所以无论拥塞控制怎么调、链路多快，单流都被 5.8G 封顶。BBR 之所以没用，是因为它只在「窗口够大」时才谈得上发挥，窗口本身没给足，算法再聪明也突破不了物理上限。

三、具体做法：把 max 调到 BDP 的 10 倍，实测从 5.6G 到 9.5G

# 1. 先量链路和 RTT（确认不是链路问题）
ethtool eth0 | grep Speed                 # 10000Mb/s
ping -c 20 <peer>                          # RTT ~8.2 ms

# 2. 看当前 TCP 缓冲三值：min default max
cat /proc/sys/net/ipv4/tcp_rmem           # 4096 131072 6291456  ← max 仅 6MB

# 3. 算 BDP = 10Gbps × 8.2ms ≈ 10MB，max 取 BDP 的 10 倍留足余量（100MB）
sysctl -w net.ipv4.tcp_rmem="4096 131072 104857600"

# 4. 确认窗口缩放开启（否则窗口封顶 64KB，直接废掉）
sysctl net.ipv4.tcp_window_scaling        # 必须为 1

# 5. 重测单流
iperf3 -c <peer> -t 30 -P 1               # 5.6G → 9.5G，逼近线速

# 6. 验证接收窗口确实放大了
ss -ti dst <peer> | grep -o 'rwnd:[0-9]*' # rwnd 从 6MB 量级涨到几十 MB

# 7. 固化
echo 'net.ipv4.tcp_rmem = 4096 131072 104857600' > /etc/sysctl.d/99-tcp-window.conf
sysctl --system

调完后单流 9.5 Gbps，120GB 数据集同步时间从「约 3 小时」压到 22 分钟，达标。

四、踩过的坑（都是反直觉的）

1. 只调发送侧 tcp_wmem 完全没用——瓶颈在接收窗 rwnd，发送缓冲给再大，对端窗口收不下照样堵。
2. max 不是「越大越好」。max 是单连接上限，100MB × 1000 并发连接理论内存上限 100GB（虽然按需分配、默认只占 default 的 128KB），内存紧张的机器要掂量。按 BDP 的 1~2 倍设就够，10 倍是为了高 RTT 留余量。
3. -P 4 并发是「土办法」：用 4 倍连接数换吞吐，能跑但挤占其它业务、放大连接开销，能用调窗口就别用。
4. 先排除应用消费慢导致的零窗口：如果接收端 read() 不及时，rwnd 会收缩到 0，这时 max 调到天上去也没用——先确认用户态读速跟得上。
5. 别误判成 MTU：MTU 1500 也能跑满，MTU 是小包场景的杀手（见社区 MTU 黑洞那篇），吞吐封顶是窗口问题，抓包里看到大包正常收发就是窗口。
6. tcp_window_scaling=0 是最隐蔽的坑：一旦为 0，窗口字段封顶 64KB，64KB / 8.2ms ≈ 8MB/s，链路直接废掉。

五、结论与可复用清单

跨机房 / 高 RTT 大流量传输，排查吞吐上不去按这个顺序走：

• 先算 BDP = 带宽 × RTT，这是单流能跑满的窗口下限；
• 先验公式：单流上限 ≈ 窗口 / RTT，用它反推「当前窗口能跑到多少」，和实测对上就锁定窗口问题；
• 确认 tcp_rmem 的 max ≥ BDP（高 RTT 取 1~10 倍），并核对 tcp_window_scaling=1；
• 用 ss -ti 看 rwnd / 抓包看 window scale 验证窗口真放大了；
• 先排除应用消费慢（零窗口）再调内核参数；
• 并发 -P N 是应急土办法，长期靠调窗口；
• 最后固化到 /etc/sysctl.d/，避免重启回退。

一句话：链路快慢看 ethtool，吞吐快慢看窗口，别拿拥塞控制当万能药。