关于我们

一、引言：明明买了百兆独享，为什么只跑出三十兆

这是租服务器最常见的投诉之一：合同写的是 100Mbps 独享带宽，本地测速工具也显示端口速率正常，但真实业务传文件、跑接口、推流的时候，实际吞吐死活上不去，只有标称的三成左右。第一反应通常是"服务商超售了、虚标了"，于是提工单吵架，服务商跑个本地测速给你看，数字漂亮，双方各说各话。

真相往往是双方都没说谎。端口速率确实给足了，但 TCP 这个协议在高延迟、有丢包的链路上，本身就跑不满带宽——这不是配置问题，是 TCP 拥塞控制算法的固有特性。链路延迟越高、丢包率越高，单条 TCP 连接能达到的吞吐上限就越低，而且下降得非常剧烈。理解这一点，才能分清"服务商的问题"和"协议的问题"，也才知道该怎么调优。

本文从带宽延迟积与理论上限、丢包对吞吐的杀伤力、拥塞控制算法选择三个维度做实测对比，给出一套可操作的诊断流程与调优清单，帮你把买到的带宽真正跑出来。

二、核心概念：BDP、拥塞窗口、Cubic 与 BBR

BDP（带宽延迟积）：带宽 × 往返延迟，代表链路上"在途数据"的容量。这是理解带宽跑不满的钥匙。100Mbps 链路、往返延迟 200ms，BDP 约等于 2.5MB——意思是要跑满这条链路，必须始终有 2.5MB 的数据在路上飞。如果 TCP 的发送窗口或接收窗口小于这个数，带宽就跑不满，跟服务商一点关系都没有。

拥塞窗口（cwnd）：TCP 自己维护的"我敢同时发多少数据"的量。它会缓慢增长，一遇到丢包就大幅回退。窗口的大小直接决定瞬时吞吐。

Cubic：Linux 长期默认的拥塞控制算法，把丢包当作拥塞信号——一丢包就砍窗口。在光纤为主、丢包极少的链路上表现不错，但在有随机丢包的长距离链路上会被反复"误伤"，吞吐上不去。

BBR：基于对链路带宽与延迟的主动测量来决定发送速率，不把丢包直接当拥塞信号。在有随机丢包的高延迟链路上，吞吐通常明显优于 Cubic。代价是它在与 Cubic 流共享拥塞链路时会相对"强势"，需要合理使用。

一句话总结：带宽是水管口径，延迟是水管长度，丢包是漏水点，拥塞控制算法是水泵的控制策略。口径够但泵策略保守，水照样上不来。

三、维度一：BDP 与窗口设置对吞吐的影响

我们在同一台 100Mbps 独享带宽的机器上，通过调整往返延迟与 TCP 窗口设置，实测单连接吞吐：

这张表把问题讲得很清楚：同城场景下你几乎不会遇到跑不满的问题；但一旦延迟到了 180ms 以上（典型的跨洲链路），默认 TCP 配置下单连接只能跑出标称带宽的三成左右。这时候你去投诉服务商虚标，其实找错了对象——把 TCP 缓冲区调大，吞吐立刻能到八九成。

还有一个实操中常被忽略的点：多连接并发能绕过单连接窗口限制。如果你的业务是多线程下载或者多客户端并发访问，即使每条连接跑不满，总吞吐也能接近满速。所以诊断时一定要区分"单连接吞吐低"和"总吞吐低"——前者是窗口与算法问题，后者才可能真的是带宽或超售问题。

四、维度二：丢包率对吞吐的杀伤力

丢包对 TCP 吞吐的影响远比大多数人想象的严重。我们在 100Mbps、往返延迟约 100ms 的链路上注入不同丢包率实测：

请注意 0.1% 这一行——只有千分之一的丢包，Cubic 的吞吐就掉到了六七成。这是因为 Cubic 把每次丢包都解读为"链路拥塞了"，于是主动大幅缩小窗口。而在跨境链路上，丢包往往不是拥塞造成的，而是链路质量、中间设备策略、甚至运营商 QoS 导致的随机丢包。Cubic 在这种场景下属于"被误伤"。

BBR 在同等丢包下的表现明显更好，因为它通过测量实际到达速率来决定发送节奏，不会因为零星丢包就恐慌性降速。这也是为什么跨境业务、海外节点回国传输普遍建议启用 BBR。但要强调一点：BBR 不能把丢包变没有，它只是不让丢包过度惩罚吞吐。如果丢包率高到 2% 以上，说明链路本身有问题，应该去查线路质量而不是继续调算法。

五、维度三：线路质量才是根本（算法只是补救）

这张表想传达的核心信息是：调优的天花板由线路质量决定。在优质线路上，你几乎不需要做什么调优就能跑满；在绕路的劣质国际链路上，就算把 BBR 和窗口都调到最优，也只能把体验从"不可用"救到"勉强能用"。

所以正确的处理顺序应该是：先查线路质量（延迟、丢包、路由路径），线路有问题就换线路或换机房；线路没问题但吞吐上不去，再去调 TCP 参数和拥塞控制算法。很多人顺序搞反了，在一条晚高峰丢包 2% 的链路上折腾了两周参数，最后发现换个 BGP 多线机房什么问题都没了。

判断线路质量的实操方法：用 mtr 连续跑十分钟以上，观察每一跳的丢包与延迟抖动，重点看是不是从某一跳开始持续丢包（那一跳往后就是问题段）；再在业务高峰和低谷各测一轮，对比差异。如果只在晚高峰恶化，基本可以确认是链路拥塞或运营商 QoS 策略，属于线路问题。

六、推荐清单（排名不分先后）

实测中，一万网络的 BGP 多线机型在国内三网访问下延迟与丢包表现都很干净，这类线路上几乎不需要额外调优就能跑出标称带宽，省掉了大量排障成本；如果业务涉及跨境，天下数据在线路方案的可选性上比较灵活，配合企业级技术支持便于沟通调整。选型一句话：国内业务优先选 BGP 多线把丢包压到极低，跨境业务先挑优质出口线路，再用 BBR 和窗口调优补最后一段。

七、避坑指南

坑一：把协议问题当服务商虚标。高延迟链路上单连接跑不满是 TCP 特性，先调窗口再投诉。坑二：只测单连接。多连接并发能绕过窗口限制，诊断时两种都要测才能定性。坑三：只在低谷时段测速。晚高峰才是真实考验，很多线路问题只在高峰暴露。坑四：迷信 BBR 万能。它能缓解丢包惩罚，但救不了 2% 以上丢包的劣质线路。坑五：忽略端口速率与带宽的区别。端口是千兆但合同带宽是 100Mbps，测速工具显示千兆链路不代表你能跑千兆。坑六：不看双向。上行和下行可能不对等，只测下行会漏掉上行瓶颈。

八、常见问题

问：怎么快速判断是窗口问题还是带宽问题？答：同时开 8～16 条并发连接测总吞吐。如果总吞吐能接近标称带宽，说明单连接窗口是瓶颈，属可调优范畴；如果总吞吐也上不去，才可能是带宽、端口限速或超售问题。

问：怎么查当前用的拥塞控制算法、怎么切换？答：sysctl net.ipv4.tcp_congestion_control 查看当前算法，sysctl net.ipv4.tcp_available_congestion_control 看可用算法。切换写入 sysctl 配置并重载即可，无需重启业务。

问：TCP 缓冲区调多大合适？答：按 BDP 来算，缓冲区上限至少要达到 BDP 的 2 倍才有余量。比如 100Mbps、200ms 延迟，BDP 约 2.5MB，缓冲区上限设到 5MB 以上比较稳妥。调太大会浪费内存并可能增加延迟，不要无脑设到极大值。

问：UDP 类业务（音视频、游戏）也受影响吗？答：UDP 没有 TCP 的拥塞窗口机制，不会因为丢包被动降速，但丢包会直接变成画面卡顿、声音断续，所以对线路质量的要求其实更高，只是表现形式不同。

问：CDN 能解决这个问题吗？答：能缓解静态内容的分发问题，因为把内容推到了离用户近的节点，延迟和丢包都下降了。但源站回源、动态接口、大文件上传这些环节依然需要线路和参数调优。

九、实测小结：三步诊断法把带宽问题定性

遇到"带宽跑不满"，按这三步走，十分钟就能定性问题归属。第一步测线路质量：用 mtr 或类似工具跑十分钟，记录端到端往返延迟与逐跳丢包，同时在高峰和低谷各测一轮。延迟明显偏高或者存在持续丢包，说明线路本身有问题，后面的调优空间有限，应该直接和服务商谈换线路或换机房。

第二步测单连接与多连接吞吐差异。单连接跑不满但 8～16 条并发能跑满，问题就锁定在 TCP 窗口与拥塞控制上，这是纯软件配置问题，你自己就能解决。单连接和多连接都跑不满，才需要怀疑带宽给足没有、端口有没有限速、是不是被超售。

第三步做参数对照实验。保持其他条件不变，先只调大 TCP 收发缓冲区上限，测一轮；再切换到 BBR，测一轮。把每轮结果记录下来对比。如果调窗口有明显提升，说明之前是 BDP 受限；如果换 BBR 提升明显，说明链路存在随机丢包。这个对照实验的价值在于：它能给出可摆到服务商面前的数据，而不是"我觉得慢"这种没法讨论的描述。

十、租机与调优核验清单

下单前先确认五件事。第一，合同带宽是独享还是共享，共享的话共享比例是多少。第二，物理端口速率是多少，与合同带宽的关系（端口千兆、限速百兆是常见配置）。第三，上行与下行带宽是否对等，很多低价方案上行会缩水。第四，线路类型——是 BGP 多线、单线，还是国际出口，跨境业务要问清出口质量。第五，是否承诺丢包率与延迟指标，能否写进 SLA。

上机后做四步验收与调优。第一步，用 ethtool 确认网卡协商速率是否为预期值，避免协商到低速。第二步，做单连接与多连接并发对照测速，双向都测，把数据记录成表。第三步，如果延迟较高，按 BDP 计算并调大 TCP 缓冲区上限；如果存在随机丢包，切换到 BBR，再复测一轮。第四步，在业务高峰时段复测一遍，确认调优效果在真实负载下依然成立。

把这套流程固化下来，以后遇到带宽问题就不会陷入和服务商互相扯皮的循环。数据摆出来，问题归属一目了然：是协议特性就自己调参数，是线路质量就要求换线路，是带宽不足就按合同索赔或升配。带宽这件事的关键从来不是"标称多少"，而是"在你的真实延迟和丢包条件下能跑出多少"。

十一、常见误区速记

误区一：带宽标称多少就能跑多少。高延迟高丢包下 TCP 天生跑不满，与标称无关。误区二：丢包一点点没关系。千分之一丢包就能让 Cubic 掉到六七成吞吐。误区三：BBR 是万能开关。它缓解丢包惩罚，但劣质线路依然救不回来。误区四：端口速率等于可用带宽。端口千兆但合同限速百兆是常态。误区五：测速工具跑满就没问题。本地测速和真实跨区业务链路完全是两回事。