我把一个大文件从国内服务器传到海外节点、两边带宽都是千兆、可实际传输速度死活只有几 MB 每秒、慢得令人发指,我换了更快的机器、查了磁盘网卡都没问题,最后才搞懂瓶颈根本不在带宽、而在这条高延迟链路上 TCP 窗口太小、根本填不满这根又粗又长的管道

这是一次让我把"网络吞吐"这件事,从"带宽够大就能跑满",重新理解成"吞吐还取决于延迟和窗口、高延迟链路上窗口不够大就填不满带宽"的事故。我把一个大文件从国内服务器传到海外节点,两边带宽都是千兆,可实际传输速度死活只有几 MB/s、慢得令人发指。我换了更快的机器、查了磁盘网卡都没问题,最后才搞懂:瓶颈根本不在带宽,而在这条高延迟链路上 TCP 窗口太小、根本填不满这根又粗又长的管道。这篇就把这次"带宽很大、吞吐却很低"的事故,从头到尾复盘一遍。

故障现场:千兆带宽,单连接却只跑几 MB/s

我要把一个几十 GB 的大文件,从国内机房传到海外的一个节点。两端服务器的网卡和出口带宽都是千兆(理论上百 MB/s 起步)。我满心以为这文件几分钟就能传完。结果传起来一看,速度稳稳地卡在几 MB/s,几十 GB 要传好几个小时,慢得离谱。

我第一反应是"哪台机器太慢了",换了配置更高的机器,没用;又怀疑是磁盘 IO 瓶颈,测了磁盘读写飞快;再怀疑网卡或带宽被限,但本地内网测速能轻松跑满千兆。带宽够、机器够、磁盘够,可这条跨国链路上的单个连接,就是只能跑几 MB/s。我百思不得其解,直到我注意到这条链路有一个突出的特点——它的延迟(RTT)很高,有两三百毫秒(国内到海外,绕了半个地球)。这时我才把 TCP 的吞吐原理捡了起来,彻底明白根因——TCP 是"发一批数据 → 等对方确认(ACK) → 再发下一批"的:在任意时刻,它"已经发出去、但还没收到确认"的数据量,受限于窗口大小(发送窗口和对方接收窗口的较小值)。也就是说,每过一个 RTT,最多只能发送"一个窗口"那么多的数据。于是单连接的吞吐上限,大约是 窗口大小 / RTT。在 RTT 高达两三百毫秒的跨国链路上,如果窗口只有默认的几十 KB,那吞吐就被死死摁在"几十 KB ÷ 0.25 秒 ≈ 几百 KB 到几 MB/s"——和带宽有多大毫无关系!带宽决定的是"管道有多粗",但要真正填满这根管道,你必须有足够多的"在途数据"(发出去还没被确认的数据);而高延迟意味着管道"很长"、能容纳的在途数据(带宽时延积)很大,默认那点小窗口根本填不满它,大部分时间链路其实是空着的、在等 ACK 往返。我以为带宽就是一切,却忘了在又粗又长的管道里,窗口不够大,就只能让数据稀稀拉拉地走、白白浪费了带宽。

单 TCP 连接的吞吐上限 ≈ 窗口大小 / RTT

本地内网: RTT ≈ 0.5ms, 窗口几十KB → 吞吐轻松跑满千兆
跨国链路: RTT ≈ 250ms, 窗口 64KB → 吞吐 ≈ 64KB / 0.25s ≈ 256 KB/s
                                     (和你有多少带宽无关!)

要填满"管道"需要的在途数据量 = 带宽时延积(BDP):
  BDP = 带宽 × RTT
  千兆(125 MB/s) × 0.25s ≈ 31 MB   ← 管道里要同时有 31MB 在途数据才跑满
  可默认窗口才几十KB → 远远填不满 → 带宽大量闲置

形象比喻:
  带宽 = 管道有多【粗】(单位时间能过多少水)
  RTT  = 管道有多【长】(水从这头到那头要多久)
  窗口 = 你一次往管道里灌了多少水
  管道又粗又长(高带宽高延迟), 你却只灌一小股水(小窗口)
  → 管道大部分是空的, 水流稀稀拉拉, 远没跑满它能过的量

问题被钉死在这个认知错位上:我以为"带宽大 = 传得快",但单连接的吞吐其实约等于"窗口大小 / RTT";在高延迟链路上,如果窗口不够大,吞吐就被 RTT 死死限制,和带宽多大根本没关系。带宽只是"管道的粗细",而要把这根管道填满跑满,需要有足够的"在途数据"——这个量等于"带宽 × 延迟"(带宽时延积);管道又粗又长(高带宽 × 高延迟)时,需要的在途数据非常大,而默认那点小窗口远远填不满,于是链路大部分时间空着、在干等 ACK 往返。我把全部注意力放在了"带宽够不够大"上,却忽略了"延迟有多高"和"窗口够不够大去填满这个延迟带来的容量"。我以为水管够粗水就一定流得快,却没想到管子又粗又长时,我一次只灌那么一小股水,管子大半截是空的。

第一件事:想明白吞吐 = 窗口/RTT,容量不只看带宽

把这次事故彻底想清楚,关键是理解单个 TCP 连接的吞吐量,不只由带宽决定,而是约等于"窗口大小 ÷ RTT"。TCP 靠"发送—确认"驱动:在收到确认前,能发出去的未确认数据量受窗口限制;每个 RTT 周期最多发一个窗口的数据。所以要跑满带宽,窗口必须大到能容纳"一个 RTT 内带宽能传输的全部数据",也就是 带宽时延积(BDP = 带宽 × RTT)。低延迟链路 BDP 小,默认窗口就够;但高延迟链路 BDP 很大,默认那点窗口远远不够,吞吐就被卡死在 窗口/RTT 这个远低于带宽的值上。

这就引出了"长肥管道(LFN,Long Fat Network)"的优化要点:在高带宽 × 高延迟的链路上跑满吞吐,核心是把"在途数据量"提上去到接近 BDP——具体手段有:开启 TCP 窗口缩放(window scaling)(让窗口能突破 64KB 的旧上限)、调大 socket 的发送/接收缓冲区、用支持大窗口的现代拥塞控制算法(如 BBR);如果单连接仍受限,就用多个并行连接同时传(把数据分片、N 条连接的吞吐叠加,这也是各种下载加速、传输工具的常用手段)。关键认知是:一条通道的"实际传输能力",不只取决于它的"带宽(粗细)",还取决于它的"延迟(长度)"以及你"一次投入多少在途数据(窗口)";要跑满一条又粗又长的通道,必须按它的"带宽 × 延迟"准备足够多的在途数据,光有大带宽、却只投入一点点,通道大部分容量都是闲置的。

# 正解1: 开启 TCP 窗口缩放 + 调大缓冲区(Linux 内核参数)
sysctl -w net.ipv4.tcp_window_scaling=1          # 允许窗口超过 64KB(默认已开)
sysctl -w net.core.rmem_max=33554432             # 接收缓冲区最大 32MB
sysctl -w net.core.wmem_max=33554432             # 发送缓冲区最大 32MB
sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'
sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'
# 让窗口能涨到能容纳 BDP(带宽×RTT)那么大, 才填得满长肥管道

# 正解2: 用支持大窗口/高带宽时延积的拥塞控制算法 BBR
sysctl -w net.ipv4.tcp_congestion_control=bbr    # 高延迟链路上吞吐更好

# 正解3: 单连接仍受限 → 多连接并行传输(吞吐叠加)
#   rsync 没有并行, 大文件跨国传可换:
#   - aria2c -x 16 -s 16 URL        # 16 个连接并行下载
#   - 把文件分片, 多个 scp/连接同时传, 再合并
#   - 用专门的传输加速工具(基于 UDP 的如 UDT/fasp, 或多路并发)

# 诊断: 先确认是不是 BDP 限制 —— 看 RTT 和单连接吞吐
ping target                                      # 看 RTT(延迟)
iperf3 -c target                                 # 测单连接吞吐, 远低于带宽就是它
iperf3 -c target -P 16                           # 16 并行, 若总吞吐上去了 → 实锤

想通这一层,我才明白自己错在哪:我把"传输快不快"完全等同于"带宽大不大",而忽略了"延迟"和"窗口"——单连接吞吐其实是 窗口/RTT,在高延迟链路上,窗口不够大,带宽再大也跑不起来。我盯着带宽、机器、磁盘查了一圈,唯独没看那条链路高达两三百毫秒的 RTT,以及默认那点小得可怜、根本填不满 BDP 的窗口。根治之道,是按"带宽 × 延迟"把窗口/缓冲区调大、用 BBR、或多连接并行,让在途数据足够多去填满这根又粗又长的管道。不是只看通道有多粗,而是按它的粗细和长度,准备足够多的在途数据去把它填满。

第二件事:正解——按带宽时延积调大窗口缓冲、用 BBR、必要时多连接并行

找到根因,正解就清晰了:在高带宽×高延迟的"长肥管道"上跑满吞吐,核心是把"在途数据量"提到接近带宽时延积(BDP=带宽×RTT)——开启 TCP 窗口缩放、把 socket 发送/接收缓冲区调大到能容纳 BDP、用 BBR 这类适配高 BDP 的拥塞控制算法;单连接仍受限就用多连接并行把吞吐叠加起来。先用 ping 看 RTT、用 iperf3 单连接 vs 多连接对比,确认是不是 BDP 限制。

# 第一步: 诊断 —— 确认瓶颈是不是带宽时延积(BDP)限制
ping target                       # 看 RTT(比如 250ms = 高延迟)
iperf3 -c target                  # 单连接吞吐, 远低于带宽 → 疑似 BDP 限制
iperf3 -c target -P 16            # 16 并行, 总吞吐明显上去 → 实锤是单连接窗口限制
# 估算需要的窗口: BDP = 带宽 × RTT, 如 1Gbps × 0.25s ≈ 31MB

# 第二步: 调大窗口/缓冲区到能容纳 BDP(两端都要调)
sysctl -w net.core.rmem_max=33554432
sysctl -w net.core.wmem_max=33554432
sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'
sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'
sysctl -w net.ipv4.tcp_window_scaling=1     # 窗口缩放(突破 64KB 上限)

# 第三步: 换适配高 BDP 的拥塞控制算法
sysctl -w net.ipv4.tcp_congestion_control=bbr

# 第四步: 单连接仍不够 → 多连接并行(吞吐叠加)
aria2c -x 16 -s 16 https://host/bigfile        # 16 连接并行下载
# 或把文件分片用多个连接同时传再合并, 或用基于 UDP 的传输加速工具

这套做法的精髓,是认清"跑满一条通道"需要的不是更大的带宽,而是足够多的"在途数据"去填满它的带宽时延积——通道又粗又长,就要按它的"粗×长"备足在途数据。调大窗口/缓冲区,是让单连接能容纳更多在途数据、逼近 BDP;BBR 等算法更善于把高 BDP 链路喂满;多连接并行,则是当单连接窗口仍受限(或有中间设备限制)时,用 N 条连接的在途数据之和去填满管道。诊断的关键是分清"瓶颈是带宽还是 BDP":单连接慢、多连接快,就是 BDP 限制。不是一味追求更大带宽,而是按带宽和延迟算出 BDP、备足在途数据去填满它。

【跨地域/高延迟传输跑不满带宽, 我现在认死的几条】

1. 单 TCP 连接吞吐 ≈ 窗口大小 / RTT, 不只由带宽决定

2. 高延迟链路上窗口不够大, 带宽再大也跑不起来(被 RTT 摁死)

3. 填满管道需要的在途数据 = 带宽时延积 BDP = 带宽 × RTT

4. 长肥管道(高带宽×高延迟)BDP 很大, 默认小窗口远填不满

5. 调大: 窗口缩放 + socket 发送/接收缓冲区(两端都调)到容纳 BDP

6. 换 BBR 等适配高 BDP 的拥塞控制; 单连接仍受限就多连接并行

7. 诊断: 单连接慢、多连接(iperf3 -P)快 → 实锤是 BDP/窗口限制

第三件事:其他"只看带宽/容量、忽略延迟与在途量"的同类坑

顺着"只盯着'通道有多粗/容量有多大'、忽略了'延迟'和'要投入多少在途量才能填满'"这条线,我把同类的坑都排查了一遍:

第一个,请求串行等待,被 RTT 拖死。一个个请求"发一个等一个",每个都吃一个 RTT,跨地域时总耗时被 RTT×次数主导;要批量/并发/管道化(pipelining)发请求。

第二个,数据库一条条查,网络往返成了瓶颈。和 N+1 同理,每条查询一个 RTT,跨网络时往返开销远超查询本身;要批量查、用 IN/JOIN 一次取回。

第三个,只扩带宽不降延迟,体验仍差。带宽翻倍但延迟没变,对"很多小请求"的场景体验提升有限;延迟敏感的要靠 CDN/就近接入降 RTT。

第四个,消息系统吞吐上不去因为没批量/没并发。一条条同步发消息、等 ack,吞吐被单条往返限制;要批量发送、增大并发/in-flight 数。

第四件事:带宽、延迟、窗口对吞吐的影响——一张对照表

我把影响单连接吞吐的几个因素摆在一起对比,核心看"它管什么、不够时会怎样":

看清这张表,排查就有方向了:带宽闲置却很慢,八成不是带宽问题,而是高延迟(管道长)+ 窗口太小(灌得少)导致填不满 BDP;解法是把窗口/缓冲调到≥BDP、用 BBR、或多连接并行。我这次踩坑,正是只盯着带宽(管道粗)、忽略了 RTT(管道长)和窗口(灌得少)——又粗又长的管道里只灌一小股水,自然跑不满。吞吐是这几个因素共同决定的,光有带宽远远不够。

第五件事:我曾经对网络吞吐想当然的几个误区

这次事故也把我对网络吞吐的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我把"通道的传输能力"简单等同于"带宽"这一个维度,而忽略了"延迟"和"在途数据量(窗口)"这两个同样关键的维度——一条通道能跑多快,是带宽、延迟、窗口共同决定的。带宽是"能过多少"的上限,但要真正逼近这个上限,你必须按"带宽×延迟"投入足够的在途数据;只看带宽、不看延迟和窗口,就会在又粗又长的管道前,守着大带宽却跑不动。把多维度的传输能力简化成单一的带宽,是这类"带宽够却很慢"困惑的共同根源。

第六件事:跨地域传输慢、排查"带宽够却跑不满"时,我现在的自检习惯

现在每当我遇到"带宽明明很大、传输/请求却很慢",我都会先按这张图问自己:

这张图的精髓,是"带宽闲置却很慢先看 RTT;高延迟+小窗口填不满带宽时延积, 调大窗口缓冲/用 BBR/多连接并行"。设计就按 BDP 调大窗口缓冲、跨地域大传输用 BBR 或多连接并行、排查就ping 看 RTT、iperf3 单连接 vs 多连接对比确认是不是 BDP 限制。这套习惯,让我从"慢就怪带宽不够"变成了"先看延迟和窗口"——核心始终是:单个 TCP 连接的吞吐量不只由带宽决定而是约等于窗口大小÷RTT:TCP 靠发送—确认驱动,在收到确认前能发出去的未确认数据量受窗口(发送窗口和对方接收窗口的较小值)限制、每个 RTT 周期最多发一个窗口的数据,所以单连接吞吐上限约为窗口/RTT;带宽决定的是管道有多粗,但要真正填满跑满这根管道你必须有足够多的在途数据(发出去还没被确认的数据),这个量等于带宽时延积 BDP=带宽×RTT;低延迟链路 BDP 小默认窗口就够,但高延迟链路(国内到海外 RTT 两三百毫秒)BDP 很大、默认那点小窗口远远填不满、吞吐就被死死摁在窗口/RTT 这个远低于带宽的值上、和带宽多大毫无关系、链路大部分时间空着在等 ACK 往返;这就是长肥管道 LFN 问题,优化要点是把在途数据量提到接近 BDP——开启 TCP 窗口缩放突破 64KB 上限、调大 socket 发送/接收缓冲区到能容纳 BDP(两端都要调)、用 BBR 这类适配高 BDP 的拥塞控制算法、单连接仍受限就用多个并行连接把吞吐叠加;诊断的关键是分清瓶颈是带宽还是 BDP——用 ping 看 RTT、用 iperf3 单连接对比多连接(-P N),单连接慢而多连接快就是 BDP/窗口限制;一句话,一条通道的实际传输能力不只取决于带宽(粗细)还取决于延迟(长度)和你一次投入多少在途数据(窗口),要跑满又粗又长的通道必须按带宽×延迟备足在途数据。

我立下的几条规矩

这场"带宽够却跑不满"的事故,换来了我做跨地域传输时,刻进骨子里的几条铁律:

1. 单 TCP 连接吞吐 ≈ 窗口大小 / RTT,不只由带宽决定。
2. 高延迟链路上窗口不够大,带宽再大也跑不起来(被 RTT 摁死)。
3. 填满管道需要的在途数据 = 带宽时延积 BDP = 带宽 × RTT。
4. 长肥管道(高带宽×高延迟)BDP 很大,默认小窗口远填不满。
5. 调大窗口缩放 + 发送/接收缓冲区(两端)到容纳 BDP;用 BBR。
6. 单连接仍受限就多连接并行,吞吐叠加。
7. 诊断:带宽闲置却慢先看 RTT;单连接慢、多连接快 → 实锤 BDP 限制。

附:我现在跨地域传输前的"算 BDP + 调参 + 并行"骨架

这是我现在做跨地域/高延迟传输固定套的流程——把这次踩坑的教训(先算 BDP、按 BDP 调窗口缓冲、用 BBR、单连接不够就并行)固化成一套步骤,让"带宽够却跑不满"那种坑再不会埋进系统:

# 第一步: 测延迟、估带宽时延积 BDP
ping -c 5 target                      # 比如 RTT ≈ 250ms
# BDP = 带宽 × RTT, 例: 1Gbps(=125MB/s) × 0.25s ≈ 31MB
# → 单连接窗口/缓冲要能涨到约 31MB 才填得满这根管道

# 第二步: 诊断 —— 单连接 vs 多连接对比, 确认是不是 BDP 限制
iperf3 -c target                      # 单连接吞吐(远低于带宽 → 疑似 BDP)
iperf3 -c target -P 16                # 16 并行(总吞吐明显上去 → 实锤窗口限制)

# 第三步: 两端都按 BDP 调大窗口/缓冲 + 开窗口缩放 + 用 BBR
sysctl -w net.core.rmem_max=33554432
sysctl -w net.core.wmem_max=33554432
sysctl -w net.ipv4.tcp_rmem='4096 87380 33554432'
sysctl -w net.ipv4.tcp_wmem='4096 65536 33554432'
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_congestion_control=bbr

# 第四步: 实际传输 —— 单连接调好仍受限就并行(吞吐叠加)
# rsync 无并行, 大文件跨国可换并行下载/分片
aria2c -x 16 -s 16 -k 10M https://host/bigfile     # 16 连接、每段 10M 并行下载

# 或把文件切片、用多个连接同时传再合并(简化示意):
split -b 2G bigfile part_                            # 切成多片
ls part_* | xargs -P 8 -I{} scp {} target:/data/    # 8 路并行传
ssh target 'cat /data/part_* > /data/bigfile && rm /data/part_*'  # 合并

# 第五步: 传完复核吞吐是否接近带宽; 把调参固化到机器初始化脚本里
# 注意: 窗口/缓冲两端都要调; 中间设备(防火墙/LB)也可能限窗口, 一并排查

这套骨架把我这次的教训钉死在了流程里:动手前先 ping 测 RTT、按带宽×RTT 算出 BDP、用 iperf3 单连接 vs 多连接对比确认是不是 BDP 限制;然后两端都按 BDP 调大窗口/缓冲、开窗口缩放、用 BBR;单连接调好仍受限就多连接并行/分片传把吞吐叠加;最后把调参固化进机器初始化脚本。这样,又粗又长的跨国管道里始终有足够的在途数据去填满它,而不再是当初那个"千兆带宽、单连接只跑几 MB/s、守着大带宽干瞪眼"的局面。把"看清吞吐由容量延迟与在途量共同决定、按带宽时延积备足在途数据"这个道理,沉淀成跨地域传输的固定流程,这是我对这次"带宽够却跑不满"最实在的交代——毕竟,要让一根又粗又长的管子真正流满,得按它的粗细和长度,往里灌足够多的水。

写在最后

回头看,这场由"TCP 窗口太小"引发的"带宽够却跑不满"事故,真正教给我的,远不止"调大缓冲区"这一个技巧。它让我对"当我们评估'一条通道能传输多快'时,极容易只盯着一个最直观的维度——'它有多粗(带宽)',而忽略了另外两个同样关键的维度:'它有多长(延迟)' 和 '我们一次往里投入了多少(窗口/在途量)';一条又粗又长的通道,如果你每次只投入一小股,它绝大部分容量都是闲置的——不是它不够粗,而是你没按它的'粗×长'投入足够多的东西去填满它",有了一次刻骨的体会。我栽跟头,是因为我把"通道的传输能力"简化成了"带宽"这一个维度,忽略了"延迟"和"在途量"——我看见两端都是千兆带宽,就笃定"管道够粗、传输必然快";我没意识到这条跨国链路虽然粗(带宽大),却也极长(RTT 两三百毫秒),而我每次往里投入的在途数据(默认小窗口)少得可怜;于是这根又粗又长的管道,大半截是空的、水流稀稀拉拉,带宽白白闲置——问题从来不在管道不够粗,而在我没按它的粗细和长度,投入足够多的在途数据去填满它。这让我领悟到一个关于"容量、延迟与投入"的深刻认知:一个系统/通道的"实际吞吐能力",从来不是由单一的"容量(带宽)"决定的,而是由"容量"、"每一份投入从发出到被确认的往返延迟"、以及"同时投入了多少在途的、尚未被确认的量"三者共同决定的;当往返延迟很高时,要想跑满容量,就必须按"容量×延迟"投入足够多的在途量——投入少了,大量容量就在"等上一批的确认"中白白闲置;这个规律远不止于网络:任何"投入→处理→反馈"有延迟的流水线(异步任务、流水线作业、请求并发、资金周转),想跑满产能,都不能只投入一份、等它走完一整个往返再投下一份,而要让"在途的量"足够多,去填满"产能 × 往返时间"这个真正的容量。这给了我一种看待"一切'容量够却跑不满'之事"时的清醒:每当我发现一条通道/一个系统"容量明明够、实际却远没跑满"时,要追问"是不是每一份投入都要经历一段往返延迟,而我同时投入的在途量太少、填不满'容量×延迟'这个真实容量?我是不是只盯着容量(带宽),忘了延迟和在途量"——按"容量×延迟"备足同时在途的量去填满通道,而不是只看容量大就以为能跑满;"看清吞吐由容量、延迟、在途量共同决定、按带宽时延积备足在途数据",是跑满网络通道、也是用满一切有延迟的流水线的关键。认清单连接吞吐=窗口/RTT、高延迟下要按 BDP 调大窗口、容量不只看带宽——这,是我用一次"千兆带宽单连接只跑几 MB/s"的事故,换来的、关于网络、也关于如何用容量延迟与在途量三维看吞吐的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次遇到"带宽够却传得慢"时,先 ping 一下看看延迟、再想想窗口够不够填满这根管道,那我对着那个"千兆带宽、单连接却只跑几 MB/s"的跨国传输干瞪眼的那阵子,就值了。

—— 别看了 · 2026