› TCP 带宽·延迟积 BDP 窗口优化 返回
网络·TCP

TCP 带宽·延迟积 BDP 窗口优化

即使是 10 Gbps 的宽带，如果 RTT 很长，默认的 TCP 窗口也无法充分利用。本工具在一个屏幕上计算 BDP、所需窗口、Mathis 上限、TCP 变种和 OS 调优，瞬间识别瓶颈是窗口不足还是数据包丢失。

参数设置
链路带宽
Mbps
链路物理带宽。1 Gbps=1000，10 Gbps=10000
往返延迟 RTT
ms
ping 往返时间。国内 10～30，日美 80～130，卫星 500～800
TCP 变种
拥塞控制算法。Linux 默认为 CUBIC
MSS（最大分段大小）
B
标准 1460，巨型帧 9000
TCP 窗口大小
KB
发送侧套接字缓冲。小于 BDP 时链路会闲置
数据包丢失率
%
广域链路 0.01～0.1%，WiFi 1～5%
OS 调优
sysctl rmem/wmem 或 qdisc 优化等级
计算结果
—
BDP (KB)
—
BDP (MB)
—
窗口使用率 (%)
—
Mathis 上限 (Mbps)
—
有效吞吐量 (Mbps)
—
拥塞窗口 (packets)
—
TCP 管道可视化 — 带宽·窗口·ACK 往返

管道粗细表示链路带宽，长度表示 RTT。发送窗口内的数据包流动，接收侧 ACK 返回后发送下一个窗口。如果窗口小于 BDP，管道会出现间隙。

吞吐量灵敏度 — 窗口大小对有效速度的影响
TCP 变种对比 — CUBIC / Reno / BBR / Vegas
理论·主要公式

$$\text{BDP} = \text{Bandwidth} \times \text{RTT}$$

带宽延迟积。链路上同时可传输的比特数上限。RTT 单位为秒。

$$\text{Throughput}_{\text{Mathis}} \approx \frac{\text{MSS}}{\text{RTT}} \cdot \frac{1}{\sqrt{p}}$$

Mathis 公式的吞吐量上限。p 为数据包丢失率（小数）。丢失率的平方根倒数起效，微小丢失也会大幅降低上限。

$$\text{Throughput} \le \min(\text{Bandwidth},\ \tfrac{W}{\text{RTT}},\ \tfrac{\text{MSS}}{\text{RTT}\sqrt{p}})$$

有效吞吐量由「物理带宽·窗口律速·丢失律速」的最小值决定。W 为 TCP 窗口大小（字节）。

TCP BDP 带宽·延迟积 窗口大小优化 — 高速广域通信

🙋
我们在东京到圣何塞之间申请了 10 Gbps 专线，但文件传输时只有 100 Mbps 的速度。链路是不是坏了？
🎓
链路没问题，这是典型的「BDP 不足」问题。BDP 是带宽延迟积，TCP 需要等 ACK 才能发下一个数据包，所以「链路上能持续飞行的数据量」决定了吞吐量上限。10 Gbps × 80 ms ≈ 100 MB 是 BDP，但 Linux 默认的发送缓冲只有 4 MB 左右，这意味着理论上限就只有 400 Mbps。100 Mbps 可能还有其他因素，但先从这里开始优化。
🙋
明白了！我把左边「TCP 窗口大小」改到 65535 KB，发现「窗口使用率」升到了 64%。这样是不是就能跑满 10 Gbps？
🎓
好方向，但 65535 KB = 64 MB 实际上是 TCP 生窗口大小的上限。超过这个值需要窗口扩展选项 (RFC 1323)。Linux 默认已启用 net.ipv4.tcp_window_scaling=1，所以你需要用 sysctl 把 rmem_max / wmem_max 改到 134217728（128 MB）才能塞进 100 MB 的 BDP。本工具选择「OS 调优 = 已优化」时，约计 1.3 倍的效果。
🙋
我还注意到数据包丢失率。从 0.01% 改到 0.1% 时，Mathis 上限就大幅下降了。仅仅 0.1% 丢失真的有这么大影响？
🎓
Mathis 公式里丢失率的平方根倒数起效，所以 p 增加 10 倍时，上限约下降 1/√10 ≈ 1/3.16。这就是「长距离链路速度上不去」的最大元凶。WiFi 上有 1～5% 丢失率的话，CUBIC 只能跑几个 Mbps。Google 就是因为这个才开发了 BBR，BBR 不靠丢失而是直接估计带宽和 RTT，所以丢失容忍度强悍。本工具选 BBR 时会乘以 1.5 倍系数。
🙋
CUBIC、Reno、BBR、Vegas 应该怎么选用呢？从图上看 BBR 最快，但…
🎓
基本原则是「广域高带宽用 BBR，公司内网用 CUBIC，低延迟优先用 Vegas」。BBR 快，但和 CUBIC 共存时会「吃掉」CUBIC 的带宽，有不公平性问题，所以骨干网和 CDN 都在往 BBRv2/v3 迁移。Reno 在教材里还有，但生产环境已经不用了。Vegas 通过监测延迟增加来判断拥塞，在游戏、语音这些对抖动敏感的场景有意义。追求吞吐就用 BBR，求稳定用 CUBIC，要低延迟就用 Vegas。
🙋
最后问一个，「拥塞窗口 (cwnd)」是什么？和「TCP 窗口大小」不一样吗？
🎓
好问题！TCP 有「接收窗口 rwnd」（接收侧告知的空闲缓冲）和「拥塞窗口 cwnd」（发送侧估计的链路余裕）两个，实际能发送的是 min(rwnd, cwnd)。本工具显示的「拥塞窗口 (packets)」是窗口大小除以 MSS 的「同时在飞的数据包数」。比如 64 KB ÷ 1460 B = 44 个包。对于 100 MB 的 BDP，44 包太少了，链路会很稀疏。如果能飞 100 MB ÷ 1460 B ≈ 71800 包的话，才能充分填满 10 Gbps。

常见问题

BDP (Bandwidth-Delay Product) 是「链路带宽 × 往返延迟 (RTT)」，表示网络上同时可以传输的数据量上限。例如 10 Gbps 的链路，RTT 为 80 ms，则 BDP = 10000 Mbps × 0.08 s = 800 Mbit ≈ 100,000 KB ≈ 97.66 MB。如果 TCP 发送窗口小于 BDP，会因等待 ACK 而导致链路闲置，即使购买了宽带也无法达到满速。在广域、高带宽网络中，BDP 感知的窗口设计至关重要。
Mathis 公式是从 MSS、RTT、数据包丢失率 p 估算吞吐量上限的经典公式，表达式为 Throughput ≈ MSS · 8 / RTT / sqrt(p)。丢失率的平方根的倒数起效，所以 p 从 0.01% 增加到 0.1% 时，上限约降至 1/3。在广域网中，「BDP 充足但速度仍然不快」通常是由微小丢失率引起。本模拟器结合 Mathis 上限、BDP 约束、OS 调优和 TCP 变种来估算实际吞吐量。
Reno 是最早的 AIMD（增加 1/RTT、丢失时减半），对丢失的容忍度低，在高带宽广域网上表现较差。CUBIC（Linux 默认）使用三次函数增加拥塞窗口，相比 Reno 对广域链路的支持更好。BBR（Google 开发）直接估计带宽和 RTT，而非依赖丢失，因此即使丢失较小也能保持速度，通常比 CUBIC 快 1.5 倍，但共存性存在问题。Vegas 将延迟增加视为拥塞前兆，适合低延迟场景。本工具可以对比各变种的系数。
典型的 sysctl 参数包括 net.core.rmem_max / wmem_max（套接字缓冲上限）、net.ipv4.tcp_rmem / tcp_wmem（自动调优范围）、net.ipv4.tcp_window_scaling（必须为 1）、net.ipv4.tcp_congestion_control（cubic / bbr）。对于 10 Gbps × 80 ms 的 BDP=100 MB 链路，默认的 4 MB 缓冲远远不足，需要扩大到 16～128 MB。使用 BBR 时需配合 net.core.default_qdisc=fq 启用。在修改实机之前，先用本工具的「OS 调优」确认效果数量级可以减少失败。

实际应用

跨数据中心长距离备份：东京～新加坡（RTT 70 ms）、东京～伦敦（RTT 240 ms）这样的国际线上复制 TB 级数据，BDP 会达到 100 MB～2 GB。用默认套接字缓冲，1 Gbps 链路也只能跑 50 Mbps。把 rmem_max/wmem_max 设为 BDP 的 2～3 倍，选 CUBIC 或 BBR，用 UDT / FASP / Multipath TCP 替代 aspera / scp，可以把有效吞吐提高 10～20 倍。

云上传 / CDN 源同步：S3 / Cloud Storage / Azure Blob 的大文件上传内部用多个并行 TCP 会话来绕过 BDP 约束。AWS 推荐 8～16 并行正是这个原因，用并行来突破单会话窗口上限。CDN 源同步也一样，HTTP/2 的流多重复用或 QUIC 采用都是根本解决 BDP 不足的办法。

卫星 / 无线链路（Starlink·LEO·5G）：卫星链路 RTT 500～800 ms，Starlink（LEO）也要 30～50 ms，比地面 4G/5G 长得多。用 CUBIC 时往往跑不满带宽的一半。Starlink 采用 BBR 就是这个原因，BBR 能在丢失率波动时保持带宽。船舶、航空通信和灾难应急网络现在都用 BBR + 大缓冲作标准配置。

金融交易 / 低延迟 HPC：反过来说，交易所委托、互联互通的目标是「RTT 缩短哪怕 1 微秒」而不是吞吐。这里用 Vegas 或 DCTCP 这样的延迟优先型，故意把缓冲设小。Cisco / Mellanox 的 HFT 网卡用 TCP 卸载 + 内核旁路（DPDK / Solarflare OpenOnload）来达到微秒级延迟。

常见误区和注意事项

最大的坑是「窗口越大速度越快」的固定观念。确实窗口小于 BDP 是瓶颈，但超过 BDP 后继续加大窗口会导致「缓冲膨胀 (Bufferbloat)」。路由器的队列堆积过多数据包，RTT 膨胀数倍，VoIP、游戏、双向通信的质量大幅下降。必须配合 CoDel / FQ-CoDel / FQ 这样的 AQM（主动队列管理）才行，否则即使本工具选「已优化」也会反效果。BBR 重视 RTT 而不只看丢失，正是为了避免缓冲膨胀。

第二个常见错误是「绝对信 Mathis 上限」。Mathis 公式是 Reno 的数学模型，对 CUBIC 和 BBR 不完全适用。CUBIC 的丢失容忍度是 Reno 的 2～3 倍，BBR 根本不靠丢失，所以能远超 Mathis 上限计算的值。本工具用变种系数补正，但也只是一阶近似。必须要拿 iperf3 -P 8 / TCP_INFO 的实机测试数据来验证。

最后是「只优化一端就够」的误解。TCP 需要发送侧（sndbuf）和接收侧（rcvbuf）缓冲都配大才行。AWS EC2 只改一侧 rmem_max，对端（企业内网）的 wmem_max 还是小的话，会受对端限制，吞吐照样被压住。必须两端都调，或者用自动调优（tcp_rmem / tcp_wmem）上限都设到 BDP 的 2 倍以上。另外，巨型帧（MSS=9000）需要 L2 全程支持，否则 PMTUD 失败反而更慢，仅限企业内网使用。

使用指南

  1. 通过滑块或输入框设置带宽(Mbps)、RTT(ms)、MSS(字节)。例如：带宽 100 Mbps、RTT 50 ms、MSS 1460 字节是光纤的标准配置
  2. 选择 TCP 变种(CUBIC/Reno/BBR/Vegas)和 OS 设置(Linux/Windows/macOS)，拥塞窗口增长规律会自动切换
  3. 运行模拟后，检查 BDP 值、窗口使用率、Mathis 上限、有效吞吐量，判断是否需要 TCP 窗口调优

具体计算示例

假设带宽 1 Gbps、RTT 100 ms、MSS 1460 字节、数据包丢失率 0.1%，运行 CUBIC 算法：BDP ≈ 12.5 MB，窗口使用率 65%，有效吞吐量 ≈ 650 Mbps。Mathis 上限通过 MSS ÷ (RTT × √丢失率) 计算，同样条件下约为 920 Mbps。在 Linux 内核中设置 net.core.rmem_max=134217728 可以把窗口使用率改进到 90% 以上

实务中的注意点

  1. 国际线路（RTT 150 ms 以上）使用 CUBIC 时，如果窗口大小低于 BDP 的 80%，就无法充分利用链路带宽。改用 BBR 可以改善这个问题
  2. 数据包丢失率超过 1% 时，Mathis 上限会急速下降（例如 100 Mbps 带宽的上限可能降至 20 Mbps 以下），TCP 流的重传处理会变成主导，下层链路质量改善就成了首要任务
  3. Windows 服务器默认 RcvBuf 很小，如果不手动配置注册表的 TcpWindowSize（推荐值：带宽×RTT÷8），长距离通信的实际吞吐会降到 Mathis 上限的 50% 以下，大量生产环境有这样的问题报告