3、带宽测量与估算：可用带宽、瓶颈带宽、Packet Pair 方法、SLoPS 方法、带宽探测工具
带宽测量这事儿，说白了就是搞清楚你的网络管道到底有多粗、现在还剩多少空位。我在流媒体项目里踩过最大的坑，就是以为服务器带宽够用，结果高峰期用户一多，画面全卡成幻灯片。从那以后，我养成了一个习惯——上线前必须做带宽探测，而且不能只测一次。
这一章我们聊三个核心概念：可用带宽、瓶颈带宽，以及两种经典测量方法——Packet Pair 和 SLoPS。最后我会带你看几个实战工具。
3.1 三个关键概念
先搞清楚定义，不然后面容易乱。
| 概念 | 英文 | 一句话解释 |
|---|---|---|
| 瓶颈带宽 | Bottleneck Bandwidth | 整条路径上最窄的那段管道的容量 |
| 可用带宽 | Available Bandwidth | 瓶颈带宽减去当前交叉流量后剩下的空位 |
| 突发带宽 | Burst Bandwidth | 短时间内能抢到的最大速率，通常不可持续 |
举个例子。你家水管最细的地方是瓶颈带宽，假设是 100 Mbps。现在有人在看 4K 视频占了 40 Mbps，那可用带宽就是 60 Mbps。突发带宽呢？就像你突然把水龙头拧到最大，那一瞬间可能冲到 120 Mbps，但几秒后就会掉回来。
核心要点：流控算法真正需要的是可用带宽，不是瓶颈带宽。瓶颈带宽告诉你上限，可用带宽告诉你现在能发多少。
3.2 Packet Pair 方法
Packet Pair 是最经典的带宽探测方法之一。原理很简单：发送端连续发出两个大小相同的数据包（背靠背），接收端根据它们到达的时间间隔来推算瓶颈带宽。
公式长这样：
瓶颈带宽 = 包大小 / 到达时间间隔举个例子。我发两个 1500 字节的包，接收端看到它们间隔 0.12 毫秒到达。那么：
1500 * 8 / 0.00012 = 100,000,000 bps = 100 Mbps嗯，这就是瓶颈带宽。
实战技巧：Packet Pair 对交叉流量非常敏感。我建议你连续发 10~20 对，取中位数或最小值，别用平均值。平均值容易被大间隔拉偏。
不过 Packet Pair 有个硬伤——它只能测瓶颈带宽，测不了可用带宽。为什么呢？因为它只关心两个包之间的间隔，不关心路径上有没有其他流量在挤占。
3.3 SLoPS 方法
SLoPS（Self-Loading Periodic Streams）就不一样了。它能直接测可用带宽。原理也很有意思：发送端以某个速率发送一串探测包，然后观察单向延迟的变化趋势。
- 如果延迟持续上升 → 说明发送速率超过了可用带宽，网络开始排队
- 如果延迟基本稳定 → 说明发送速率低于可用带宽，网络没压力
通过二分查找，反复调整发送速率，最终收敛到可用带宽的近似值。
注意：SLoPS 的探测过程本身就会注入流量，可能干扰正在进行的流媒体传输。我在生产环境里一般把探测速率控制在预估可用带宽的 60% 以下，或者只在会话建立阶段做一次。
SLoPS 的典型实现是 pathChirp，它用指数递增的 chirp 包序列来加速收敛。我个人觉得 pathChirp 比纯二分查找快得多，适合对实时性要求高的场景。
3.4 两种方法的对比
| 维度 | Packet Pair | SLoPS |
|---|---|---|
| 测量目标 | 瓶颈带宽 | 可用带宽 |
| 探测流量 | 低（2 个包） | 中高（一串包） |
| 对交叉流量的敏感度 | 高 | 中等 |
| 收敛速度 | 快（单次测量） | 慢（需要多次迭代） |
| 适用场景 | 链路容量探测 | 实时可用带宽估计 |
3.5 带宽探测工具
理论说完了，上点实战的。我常用的工具就这几个：
3.5.1 iperf3
最基础的带宽测试工具。它能测 TCP 和 UDP 的吞吐量，但不适合在线流媒体场景，因为测试流量太大。
# 服务端
iperf3 -s
# 客户端（测 10 秒 TCP 吞吐）
iperf3 -c 192.168.1.100 -t 103.5.2 pathChirp
实现了 SLoPS 方法的开源工具。它用 chirp 包序列探测可用带宽，对网络干扰小。
# 发送端
pathchirp -s
# 接收端
pathchirp -c 192.168.1.1003.5.3 Spirent / Ixia
商业测试仪表，精度高但贵。我在做 CDN 选型时用过 Spirent 来对比各家节点的瓶颈带宽，数据很可靠。
3.5.4 自研探测模块
很多流媒体系统会内嵌轻量级探测模块。我参与过的一个项目，在推流 SDK 里嵌了一个简化版 Packet Pair，每 30 秒发一对探测包，用来动态调整编码码率。
我的建议：生产环境别用 iperf3 做在线探测。它太粗暴了。用 pathChirp 或者自研的轻量探测模块，控制好探测频率和包大小。
3.6 知识体系总览
下面这张图把本章的核心逻辑串起来了。你可以看到从基础概念到测量方法，再到工具落地的完整链路。
3.7 避坑指南
最后分享几个我踩过的坑，希望能帮你省点时间。
- 别在高峰期做探测：我曾经在晚高峰用 SLoPS 测可用带宽，结果探测流量本身把链路挤爆了，导致线上用户集体卡顿。后来我改成只在会话建立时测一次，之后用被动测量。
- Packet Pair 的包大小要选对：太小的包容易被交换机合并处理，测出来的带宽偏高。我一般用 1500 字节（标准 MTU）。
- 单向延迟比 RTT 更可靠：SLoPS 依赖单向延迟变化。如果你只有 RTT，结果会被反向链路的排队干扰。能部署 NTP 就部署，精度要求高的话用 PTP。
- WiFi 环境要降权：无线链路的带宽波动大，单次测量结果不可信。我通常取 5 次测量的中位数，并且把置信区间拉宽。
一句话总结：瓶颈带宽用 Packet Pair 快速摸清上限，可用带宽用 SLoPS 精确探测空位。工具选 pathChirp 或自研轻量模块，别在生产环境用 iperf3 硬怼。