📚 课程目录第2章推流基础概念

2. 推流基础概念

推流卡顿，十有八九是网络在搞鬼。我排查过上百个卡顿案例，真正出在编码器或推流软件本身的，其实不到两成。剩下的，全是网络基础没打牢。

这一章，咱们就把网络的三项基本功——带宽、延迟/抖动、丢包率——彻底讲透。你想想看，如果连水管有多粗、水流稳不稳、有没有漏水都不知道，那排查卡顿就是瞎蒙。

  核心原则：网络排查必须按顺序来。先测带宽，再看延迟和抖动，最后分析丢包率。跳步是大忌。

2.1 带宽测试方法

带宽，说白了就是你家到推流服务器之间的「水管粗细」。我见过太多人拿 100M 的宽带跑 8M 码率，觉得绰绰有余。结果一测，上行带宽只有 2M。为什么？运营商给的宽带，下行和上行往往不对称。

常见误区：很多人只看下行带宽。推流用的是上行带宽，这两个概念完全不同。100M 下行 ≠ 100M 上行。

2.1.1 测试工具与命令

我个人习惯用 iperf3，轻量、准确、跨平台。当然，Speedtest 的 CLI 版本也行，但 iperf3 能直接测到推流服务器的链路质量。

# 服务端（在推流服务器上启动）
iperf3 -s -p 5201

# 客户端（在推流端执行，测试上行）
iperf3 -c 推流服务器IP -p 5201 -t 30 -u -b 10M

# 参数说明：
# -t 30    : 测试时长30秒
# -u       : UDP模式（推流走UDP）
# -b 10M   : 目标带宽10Mbps

我在项目中遇到过一件事：客户说推流卡，我让他跑 iperf3，结果他跑了 5 秒就停了，说「测完了」。嗯，这里要注意——测试时长至少 30 秒，才能看到带宽波动。5 秒的数据，参考价值不大。

2.1.2 带宽测试的黄金标准

测试项	推荐值	说明
上行带宽	≥ 推流码率 × 1.5	留出 50% 余量应对波动
测试时长	≥ 30 秒	短时测试无法反映真实情况
测试次数	≥ 3 次	取平均值，排除偶然因素
测试时段	高峰期 + 空闲期	晚 8-10 点必须测一次

我的经验：如果上行带宽刚好等于推流码率，那卡顿几乎是必然的。网络一波动，带宽一降，立刻丢帧。我建议至少留出 50% 的余量。比如推 6M 的流，上行带宽最好有 9M 以上。

2.2 网络延迟与抖动检测

带宽够了，不代表不卡。延迟和抖动，才是影响推流「实时性」和「稳定性」的关键。

延迟，是数据包从 A 到 B 的单程时间。抖动，是延迟的变化幅度。你想想看，如果延迟稳定在 50ms，那还好办。但如果延迟在 20ms 到 200ms 之间来回跳，推流端和播放端都会疯掉。

2.2.1 延迟检测方法

最常用的就是 ping。但 ping 测的是 ICMP 协议的延迟，和实际推流的 UDP 延迟有差异。我建议用 iperf3 的 UDP 模式来测，更贴近真实场景。

# 基础 ping 测试
ping -c 100 推流服务器IP

# 重点关注：
# - min/avg/max 延迟
# - mdev（平均偏差，就是抖动）

# iperf3 UDP 延迟测试
iperf3 -c 推流服务器IP -p 5201 -t 30 -u -b 1M --get-server-output

我曾经遇到一个案例：ping 延迟只有 10ms，但推流就是卡。后来用 iperf3 一测，UDP 延迟平均 80ms，抖动高达 60ms。为什么？因为中间某个路由器对 ICMP 和 UDP 的优先级处理不一样。ping 骗了你。

2.2.2 抖动的影响与阈值

抖动范围	对推流的影响	建议措施
< 10ms	几乎无影响	正常推流
10ms - 30ms	偶发卡顿，可感知	增大推流缓冲
30ms - 50ms	频繁卡顿，影响观看	排查中间链路
> 50ms	严重卡顿，无法正常推流	更换网络或线路

  关键指标：抖动比延迟更致命。延迟 100ms 但抖动 5ms，推流依然可用。延迟 30ms 但抖动 40ms，画面会一卡一卡的。

2.3 丢包率分析

丢包率，是网络排查的「终极大招」。带宽再大、延迟再低，只要丢包率超标，推流必卡。

为什么会丢包？说白了，就是网络设备处理不过来，把数据包扔了。路由器缓存满了、线路质量差、Wi-Fi 信号干扰，都可能导致丢包。

2.3.1 丢包率测试方法

# 使用 iperf3 测试 UDP 丢包率
iperf3 -c 推流服务器IP -p 5201 -t 30 -u -b 5M

# 输出示例：
# [ ID] Interval       Transfer     Bitrate         Jitter    Lost/Total Datagrams
# [  5]  0.00-30.00  sec  18.8 MBytes  5.26 Mbits/sec  12.345 ms  125/15000 (0.83%)

# 重点关注 Lost/Total 和括号内的百分比

我建议至少测三次，每次间隔 5 分钟。如果某次丢包率突然飙升，那说明网络存在间歇性问题。这种问题最难排查，但也最常见。

2.3.2 丢包率阈值与应对

丢包率	严重程度	推流表现	应对方案
< 0.1%	正常	几乎无影响	无需处理
0.1% - 0.5%	轻度	偶发花屏或卡顿	启用 FEC 前向纠错
0.5% - 1%	中度	频繁卡顿，影响体验	降低码率 + 启用 ARQ
> 1%	重度	无法正常推流	必须更换网络

注意：Wi-Fi 环境下的丢包率通常比有线高 0.5%-1%。如果你用 Wi-Fi 推流，丢包率在 0.5% 以内都算正常。但超过 1%，就必须排查干扰源或换有线。

2.3.3 丢包率与码率的联动关系

丢包率和码率是「跷跷板」关系。码率越高，单位时间发送的数据包越多，丢包的概率就越大。反过来，降低码率可以显著降低丢包率。

我在项目中遇到过最典型的场景：客户用 8M 码率推流，丢包率 2.3%，卡得没法看。我让他降到 4M，丢包率直接降到 0.2%。画面清晰度虽然降了，但至少不卡了。这就是「保流畅、舍画质」的权衡。

避坑指南：我曾经在排查一个直播卡顿问题时，连续测了 10 次丢包率，结果都正常。后来才发现，我测的是到 CDN 边缘节点的链路，而实际推流走的是另一个节点。记住：一定要测到实际推流服务器的链路，不要偷懒。

2.4 综合排查清单

好了，三项基本功讲完了。最后给一张排查清单，你照着做就行。

测上行带宽：用 iperf3 测 30 秒，确保 ≥ 推流码率 × 1.5
测延迟：ping 100 个包，看 avg 和 mdev
测抖动：重点关注 mdev，超过 30ms 就要警惕
测丢包率：UDP 模式测 30 秒，丢包率超过 0.5% 必须处理
交叉验证：换一台机器、换一个网络环境再测一次

这三项指标，就像人的血压、心率和体温。任何一个异常，都说明身体（网络）出了问题。别急着调编码参数，先把网络基础打牢。