有一次我在压测一个接口服务，顺手看了一眼带宽使用情况。
标称 50Mbps 的 VPS，结果实际跑起来，一直在 20 多上下晃，怎么压都上不去。当时第一反应是配置不够，后来换了测试方式才发现，问题没那么简单。
同样一台机器，换个工具、换个节点，带宽表现完全不一样。
带宽能不能跑满，很多时候不取决于你想不想，而是环境允不允许。
这次我专门做了一轮极限测试，把不同方式都跑了一遍，结果还挺有意思。
我这次测试是怎么做的
这次我选了三台配置接近的 VPS，都是标称 50Mbps 带宽，分别在亚洲不同节点。
测试环境是同一个网络出口，避免干扰。每台机器我都做了三轮测试，分别在白天、晚高峰、凌晨跑了一遍。
测试方式主要分三种：单线程下载测、多线程下载测试、持续压带宽测试（跑10分钟以上）
每次测试都记录平均值，而不是只看瞬时峰值。
单线程测试，基本都会被限制
先说最简单的一种测试。
我用 curl 和 wget 分别拉一个 1GB 的测试文件，结果基本都差不多。
- 最低的在 12Mbps 左右
- 稳定一点的在 18–25Mbps
- 很少有超过 30Mbps 的情况
而且波动比较明显，有时候还会掉到 10Mbps 以下。
这个结果其实挺正常的，因为单连接本身就有限制，再加上网络延迟，吞吐很难拉满。
所以如果你用浏览器或者单线程工具测速，基本都会觉得带宽不够。
多线程测试，差距开始明显
接下来我用多线程工具压了一下，比如开 5–10 个并发下载。
这时候情况就完全不一样了。
其中一台机器可以稳定跑到 45Mbps 左右，基本接近标称带宽。
另外一台机器最高能冲到 40Mbps，但波动比较大，经常在 30–40 之间来回跳。
还有一台表现最差，基本卡在 25–30Mbps，很难再往上。
这一步就能看出来，带宽不是不能跑满，而是看环境能不能撑住。
持续压测，才是最真实的结果
很多人只看瞬时速度，但我更关心的是稳定性。
我让每台机器持续压带宽 10 分钟以上，观察曲线变化。
结果很有意思.
第一台机器可以稳定在 40–45Mbps，波动很小。
第二台一开始能冲到 40Mbps，但几分钟后掉到 30 左右。
第三台基本全程在 25Mbps 左右徘徊。
而且在晚高峰测试时，整体表现明显下降，有一台甚至掉到 20Mbps 出头。
也就是说，能不能跑满，不只是瞬时能力，还和持续稳定性有关。
不同时间段，差距非常明显
这一点是我这次测试最直观的感受。
同一台 VPS在凌晨基本可以接近满速，但是到白天略有波动，晚上高峰期明显下降。
有一台机器凌晨可以稳定 45Mbps，到了晚上直接掉到 30Mbps 左右。
这说明带宽不仅是资源问题，还和网络拥堵强相关。
节点和线路的影响，比我想的还大
三台机器中，表现最好的那台，不是配置更高，而是线路更稳定。
路径更短，波动更小，所以多线程更容易把带宽拉满。
表现差的那台，即使开更多线程，也上不去，说明瓶颈在链路而不是本地。
这一点其实和之前说的延迟、绕路问题是一样的，本质都是线路差异。
我现在怎么看带宽这件事
经过这次测试，我基本不会再只看标称带宽了。
如果需要测试，我会先多开几个节点对比，比如用 LightNode 快速起不同地区的机器，把带宽实际跑一轮再决定。
同样是50Mbps，实际表现可能差很多。
如果是长期使用，我更看重稳定性，比如用 萤光云，带宽不一定每次都拉满，但整体波动更小。
稳定输出，比偶尔满速更有价值。
一个很容易踩的坑
我一开始也犯过一个错误，就是看到测速截图就下结论。
后来才发现，瞬时速度没有太大意义，关键是：
能不能稳定跑
高峰期表现怎么样
不同测试方式是否一致
如果只看一张测速图，很容易被误导。
常见问题
为什么测速只有一半带宽？
大多数是单线程限制，不代表真实带宽能力。
多线程一定能跑满吗？
不一定，如果线路或节点有限制，还是会卡住。
带宽跑满说明服务器很好吗？
不完全，还要看稳定性和波动。
为什么晚上速度明显下降？
网络高峰期，链路拥堵更严重。
怎么测最接近真实情况？
多线程加持续压测，比单次测速更靠谱。
写完这一轮测试，我最大的感受其实很直接。
带宽不是一个固定值，而是一个在不同环境下会变化的能力。
如果你发现带宽跑不满，不一定是你方法不对，很可能是环境本身就限制了上限。
