2. 网络基础排查：带宽测试方法、延迟与抖动测量、丢包率检测、网络链路质量评估
推流出问题，很多人第一反应就是“服务器不行”或者“编码器太烂”。但我做了这么多年流媒体，可以负责任地告诉你：超过一半的卡顿，根源都在网络链路上。所以这一章，咱们先把网络底子摸清楚。
说白了，网络基础排查就是回答四个问题：
路够宽吗？（带宽）
路上堵不堵？（延迟）
路颠不颠？（抖动）
有没有掉坑里？（丢包）
下面我一个一个拆开讲。
2.1 带宽测试方法
带宽是推流的“水管粗细”。水管太细，数据流就过不去，卡顿是必然的。
上行带宽 vs 下行带宽
推流看的是上行带宽。很多人拿测速网站测出个 100Mbps，就以为推 4K 没问题。但测速网站测的往往是下行。上行带宽通常只有下行的 1/3 到 1/2。我见过一个客户，家里下行 500M，上行只有 8M，还非要推 1080p 60fps，不卡才怪。
怎么测上行带宽？
我个人习惯用这三种方法：
- iperf3 测真实吞吐
这是最准的方法。在服务器端开监听，客户端发数据，测的是端到端真实吞吐量。
# 服务端（接收端）
iperf3 -s -p 5201
# 客户端（发送端，模拟推流方向）
iperf3 -c 服务器IP -p 5201 -t 30 -u -b 100M注意加 -u 参数用 UDP 模式，因为推流本质是 UDP 或基于 UDP 的协议（SRT/QUIC）。TCP 测出来的带宽会偏高，因为 TCP 有拥塞控制和重传，掩盖了真实网络状况。
- 大文件上传测速
找一个不限速的对象存储（OSS/S3），上传一个 100MB 以上的文件，看上传耗时。这个方法简单，但受服务器端限速影响，只能做参考。 - 推流软件自带统计
OBS 的“统计”面板里有个“比特率”曲线。如果曲线经常掉到设定值以下，说明上行带宽不够。嗯，这个最直观，但已经是事后诸葛亮了。
2.2 延迟与抖动测量
带宽够，不代表不卡。延迟和抖动才是“隐形杀手”。
延迟（Latency）：数据包从 A 到 B 的单程时间。推流场景下，延迟 100ms 以内算优秀，200ms 以内可接受，超过 500ms 交互感就很差了。
抖动（Jitter）：延迟的变化幅度。抖动大，意味着网络不稳定，播放端缓冲区会频繁“空”或“满”，表现出来就是画面一顿一顿的。
我举个例子你就明白了：
延迟 200ms 但抖动 5ms，推流很稳。
延迟 50ms 但抖动 80ms，推流必卡。
怎么测？
用 ping 就能看个大概：
ping -c 100 -i 0.1 目标服务器IP看输出里的 min/avg/max/mdev。其中 mdev 就是抖动（标准偏差）。mdev 超过 20ms，就要警惕了。
更专业的做法是用 iperf3 的 UDP 模式，它会直接报告抖动：
iperf3 -c 服务器IP -u -b 5M -t 30输出末尾会有 Jitter 字段。我个人习惯：抖动超过 30ms，推流体验就会明显下降。
| 指标 | 优秀 | 良好 | 需优化 | 不可用 |
|---|---|---|---|---|
| 延迟（RTT/2） | < 50ms | 50-150ms | 150-300ms | > 300ms |
| 抖动（Jitter） | < 10ms | 10-20ms | 20-40ms | > 40ms |
2.3 丢包率检测
丢包是推流的“癌症”。一旦出现丢包，视频画面就会出现马赛克、花屏、甚至黑屏。
丢包率多少算正常？
- 0%：理想状态
- 0.1% - 0.5%：轻微丢包，FEC（前向纠错）可以修复
- 0.5% - 2%：中度丢包，画面开始出现瑕疵
- > 2%：重度丢包，推流基本不可用
检测方法：
方法一：iperf3 UDP 模式直接看丢包率
iperf3 -c 服务器IP -u -b 10M -t 60
# 输出末尾会显示 "Lost/Total Datagrams" 和丢包百分比方法二：mtr 逐跳检测
mtr 结合了 traceroute 和 ping，能告诉你丢包发生在哪一跳：
mtr -r -c 100 目标服务器IP输出里每一跳都有 Loss% 列。如果最后一跳丢包 0%，但中间某跳丢包 5%，说明问题出在运营商骨干网或某个中转节点上。
我记得有一次帮一个游戏直播平台排查，用户推流总是卡。用 mtr 一看，丢包全集中在某个省级运营商的出口节点上。最后让用户换了个 CDN 接入点，问题就解决了。
2.4 网络链路质量评估
前面几个指标都是“点”上的测量。链路质量评估，是把整条路串起来看。
评估维度：
- 带宽余量：当前占用带宽 vs 可用带宽。余量不足 20% 就是危险区。
- 延迟稳定性：看延迟曲线是否平缓。大起大落说明链路不稳定。
- 丢包分布：丢包是均匀分布还是突发性？突发丢包对推流伤害更大。
- 路径对称性：上行和下行路径是否一致？不一致可能导致单向延迟高。
我的评估流程：
- 先跑一次
iperf3 -u，拿到带宽、抖动、丢包三个基础值。 - 再跑
mtr，看丢包发生在哪一跳。 - 最后用
traceroute看路径，确认没有绕路。
如果这三步走完，链路质量基本就摸清了。
下面这张图是我自己总结的排查流程，你可以照着走一遍：
最后说一句：网络排查不是一次性的。网络状况会随时间变化，尤其是晚高峰时段。我建议你在不同时间段（早、中、晚、深夜）各测一次，取最差情况作为基准。这样推流方案才能扛得住最恶劣的网络环境。