TCP 吞吐量计算器

Q: BBR 和 CUBIC 对吞吐的影响？

CUBIC（Linux 默认）是丢包驱动：见到丢包就砍窗口，高丢包链路吞吐被 Mathis 方程锁死。BBR（Google 提出）是模型驱动：主动测量带宽与 RTT，按 BDP 定速发送，不看丢包脸色——在 1-2% 丢包的跨境链路上吞吐可达 CUBIC 的数倍。BBR 的代价是对同链路 CUBIC 流的「不友好」争议，以及浅缓冲队列下的高重传。

Q: 怎么测链路的真实可用带宽？

iperf3 是标准答案：一台起 server、一台起 client，用 -P 参数并发多流模拟真实场景，-t 30 跑足时长避开慢启动干扰。注意 iperf3 默认单流——单流测的是「TCP 健康度」，多流测的才是「链路容量」。配合本工具先算 BDP，设置 -w 窗口参数大于 BDP，才能测出物理上限而不是协议上限。

Q: 为什么千兆宽带单线程下载只有几十 MB？

服务器或客户端窗口过小、RTT 较大时单连接被窗口公式锁死；另受硬盘写入速度、无线协商速率、服务器限速约束。多线程下载工具（如 IDM）靠并发多个 TCP 连接绕开单窗口上限。

Q: 什么是带宽时延积（BDP）？

BDP = 带宽 × RTT，表示「在途」数据量，窗口至少要达到 BDP 才能跑满带宽。1000Mbps × 150ms 的 BDP 约 18.75MB——这正是跨洋链路需要大窗口的原因。

Q: 丢包对 TCP 吞吐影响有多大？

极大。经典 Mathis 公式显示吞吐与丢包率平方根成反比：RTT 100ms、丢包 0.01% 时单连接约 130Mbps，丢包升至 1% 仅剩约 13Mbps。BBR 等新算法对丢包不敏感，跨境场景优势明显。

Q: BBR 和 CUBIC 有什么区别？

CUBIC 以丢包为拥塞信号（丢包才降速），在 buffers 大的设备上主动填满缓冲区造成延迟膨胀；BBR 测量带宽与 RTT 主动控制发送速率，高丢包跨境链路吞吐常高出数倍，Google 全系服务已默认启用。

Q: UDP 比 TCP 快吗？

单看传输机制 UDP 无拥塞控制确实能「硬塞」，但会挤占同链路其他流量并被运营商限速；QUIC（基于 UDP）实现了比 TCP 更现代的拥塞控制与多路复用，实际吞吐与 TCP 相当甚至更好，这才是「快」的正解。

Q: 如何实测单连接 TCP 吞吐？

用 iperf3 对测：iperf3 -c 目标 -t 30 默认单流，加 -P 8 测 8 并发。单流与多流的差距直接反映窗口/拥塞控制瓶颈；同时观察重传率（Retr）判断丢包影响。

Q: Wi-Fi 下 TCP 吞吐为什么打折？

无线半双工（同一信道收发不能同时进行）+ 重传机制使实际吞吐通常只有协商速率的 50-60%；2.4GHz 干扰严重时更低。RTT 抖动大还导致 TCP 误判拥塞频繁降速，5GHz/6GHz 与 Wi-Fi 6 的 OFDMA 能显著改善。

什么是TCP 吞吐量计算器？

TCP 是停等协议的流水线版：未确认数据不能超过窗口大小（Window），所以单连接吞吐上限 = 窗口 ÷ RTT。经典窗口上限 65535 字节（TCP 头窗口字段只有 16 位），在 RTT 50ms 的跨国链路上：65535 × 8 ÷ 0.05 ≈ 10.49 Mbps——物理带宽再大也没用。这就是「长肥网络」（LFN，Long Fat Network，带宽时延积很大的链路）的经典困境。

解法写在 RFC 1323：窗口扩大选项（Window Scaling）把窗口字段左移最多 14 位，理论上限 1GB——Linux 默认开启，Windows Vista 后也默认启用。公式随之更新：吞吐 = min（接收窗口，拥塞窗口） ÷ RTT。另一个公式来自 Mathis 方程，给出丢包率约束：吞吐 ≈ (MSS ÷ RTT) × (C ÷ √p)，p 是丢包率——1% 丢包在 100ms 链路上只有约 1.5Mbps，这就是为什么跨洋专线拼命压低丢包。本工具同时给出窗口上限、Mathis 丢包上限与所需 BDP 对照。

吞吐公式还有另一把制约：拥塞窗口（cwnd）增长受「慢启动 + 拥塞避免」控制，即使接收窗口足够大，发送端也要不断试探。RTT 每增大一点，探测新带宽所需的往返次数就变多，跨国、跨洋、卫星链路对小窗口尤其致命——这就是为什么 50ms RTT 下 65535 字节窗口只能跑到约 10Mbps，而 800ms 卫星链路连 1Mbps 都难达。测算时需同时给定 RTT 与窗口，缺一不可。

本工具的核心价值是「预判」而非实测：丢包率 p 下吞吐还会进一步打折（约 1.22 × MSS ÷ (RTT × √p)），高丢包网络吞吐断崖式下降。结合窗口扩大、丢包与 RTT 三项输入，可估算理论瓶颈，帮助判断是加大缓冲、启用 BBR、还是升级链路更有性价比。无论做跨国专线评估、CDN 调优还是数据中心内部带宽规划，先用本工具框定上限，再决定调优方向。

窗口受限吞吐 = Window × 8 ÷ RTT(s)；Mathis 上限 ≈ (MSS×8 ÷ RTT) × (1.22 ÷ √p)；BDP = 带宽 × RTT 是窗口需求的下限。

TCP 单连接吞吐量受窗口与往返时延（RTT）制约，理论上限公式：吞吐量 ≤ 窗口大小 ÷ RTT。示例：默认 64KB 窗口（65535 字节）在 RTT 50ms 的跨城链路上，上限 = 65535 × 8 ÷ 0.05 ≈ 10.5 Mbps——无论物理带宽多大，单连接都跑不满。开启窗口缩放（Window Scaling，因子最大 14）后窗口可达 1GB，千兆跨洋链路才能用满。本工具按此模型计算理论吞吐与所需窗口。

窗口与 RTT 组合下的单连接吞吐上限
RTT	64KB 窗口	1MB 窗口	16MB 窗口
1ms（同城机房）	524 Mbps	8.4 Gbps	134 Gbps
10ms（省内）	52 Mbps	839 Mbps	13.4 Gbps
50ms（跨城）	10.5 Mbps	168 Mbps	2.7 Gbps
150ms（跨洋）	3.5 Mbps	56 Mbps	895 Mbps
300ms（卫星）	1.7 Mbps	28 Mbps	447 Mbps

如何使用TCP 吞吐量计算器

1
输入 TCP 窗口大小（或选默认值）与链路 RTT。
2
可选输入丢包率估算 Mathis 上限。
3
点击「计算」，查看吞吐量上限与窗口扩大建议。

计算示例

例 164KB 窗口 + 50ms RTT

65535×8÷0.05 ≈ 10.49 Mbps——上世纪的默认值配不上今天的带宽。

例 21MB 窗口 + 100ms RTT

1048576×8÷0.1 ≈ 83.9 Mbps——窗口扩大 16 倍，吞吐同步放大 16 倍。

注意事项

实际吞吐取 min（应用缓冲，接收窗口，拥塞窗口） ÷ RTT——拥塞控制（CUBIC/BBR）往往是真正的瓶颈。
RTT 要用实测值（ping 平均），地理距离只是下限：路由绕行能让「同城」RTT 翻倍。
窗口扩大选项在握手时协商，中间老旧防火墙可能剥掉该选项导致回退 64KB。
多连接可以绕开单连接窗口限制——这就是下载工具「16 线程加速」的原理（以及 CDN 并发的价值）。

常见问题

按顺序排查：① 单位换算（千兆 = 1000Mbps ≈ 125MB/s 理论上限）；② TCP 窗口与 RTT（测速网站近端服务器 RTT 通常 <10ms，窗口够用；连境外服务器立刻现原形）；③ 丢包（Wi-Fi 干扰 1% 丢包就能砍掉一半吞吐）；④ 网卡/硬盘/CPU 瓶颈。用本工具输入实际 RTT 与窗口，先算理论上限再定位瓶颈层。