4. 网络基础
RTMP 推流本质上是在互联网上搬运实时视频数据。很多推流问题——卡顿、花屏、断流——表面上是编码器或服务器配置问题，但根源往往在网络传输层。理解 TCP/IP、UDP、带宽、延迟、丢包这五个核心概念，是排查推流故障的第一道门槛。
4.1 核心原理：TCP 与 UDP 的分工
RTMP 协议建立在 TCP（传输控制协议） 之上。TCP 提供可靠的、有序的字节流传输，它通过确认应答（ACK）、超时重传、滑动窗口等机制保证数据完整到达。但可靠性是有代价的：一旦发生丢包，TCP 会暂停后续数据的发送，等待重传，这会导致传输延迟增加，甚至引发接收端缓冲区饥饿。
与之相对的是 UDP（用户数据报协议），它无连接、不保证可靠交付，数据报发出后不管是否到达。UDP 的头部开销小（8 字节 vs TCP 的 20 字节），没有拥塞控制，因此延迟更低，但数据可能丢失或乱序。RTMP 不使用 UDP，但理解 UDP 有助于对比理解 TCP 的“重传阻塞”问题。
关键认知：RTMP 推流使用 TCP 端口 1935。TCP 的“可靠”特性在弱网环境下反而成为实时性的敌人——因为视频数据具有时效性，迟到的重传数据对播放器已经没有意义，却会阻塞后续关键帧的发送。
4.2 带宽、延迟与丢包：推流的三维约束
推流质量由三个网络指标共同决定，它们相互影响，任何一个恶化都会导致画面异常。
| 指标 | 定义 | 对推流的影响 | 典型阈值 |
|---|---|---|---|
| 带宽 | 单位时间内网络能传输的最大数据量（Mbps） | 上行带宽不足 → 编码器缓冲堆积 → 延迟增大或断流 | 推流码率 × 1.5 以上 |
| 延迟（RTT） | 数据从发送端到接收端的往返时间（ms） | 高延迟 → TCP 握手慢、重传恢复慢、首帧出现慢 | < 100ms 优秀，< 300ms 可用 |
| 丢包 | 传输过程中丢失的数据包比例（%） | 丢包 → TCP 重传 → 延迟抖动、画面卡顿、花屏 | < 0.5% 良好，> 2% 明显劣化 |
4.3 方法流程：推流前的网络体检
在正式推流前，建议按以下流程对网络进行体检，避免开播后才发现问题。
- 测上行带宽：使用 speedtest 或 iperf3 测试实际上行带宽，而非只看运营商标称值。
- 测 RTT 与抖动：持续 ping RTMP 服务器地址 100 次，记录平均延迟、最大延迟和抖动（延迟标准差）。
- 测丢包率：使用
ping -c 100 -i 0.2统计丢包率，或使用mtr工具查看每一跳的丢包情况。 - 计算所需带宽：根据编码码率预留 30%~50% 余量。
# 使用 ping 测试到 RTMP 服务器的延迟与丢包
ping -c 100 -i 0.2 rtmp.example.com
# 使用 iperf3 测试上行带宽（服务器端需运行 iperf3 -s）
iperf3 -c rtmp.example.com -u -b 10M -t 30经验公式：所需上行带宽 ≈ 视频码率 + 音频码率 + 10% 协议开销。例如推 1080p、6Mbps 码率，加上 128kbps 音频，建议上行带宽不低于 7Mbps，实际预留 8~10Mbps 更稳妥。
4.4 案例：一次典型的“上行带宽不足”故障
某主播使用 4G 网络推流，设置视频码率 8Mbps。开播后画面频繁卡顿，编码器提示“发送缓冲区满”。排查过程如下：
- 使用 speedtest 测得上行带宽仅 5.2Mbps，远低于设置的 8Mbps 码率。
- ping 服务器延迟 45ms，丢包率 0.3%，网络质量尚可。
- 结论：上行带宽不足是根因。
解决方案：将视频码率降至 4Mbps，同时将分辨率从 1080p 降至 720p，卡顿立即消失。这个案例说明，码率设置必须与实测上行带宽匹配，而不是与理论带宽匹配。
4.5 误区与复盘：常见网络认知偏差
误区一：只看下行带宽。推流是上行流量，很多用户只关注下载速度，忽略了上行带宽往往只有下行的一半甚至更低。
误区二：忽略 Wi-Fi 信号波动。Wi-Fi 的丢包和抖动在有遮挡或干扰时急剧恶化，即使信号格数显示满格。推流建议优先使用有线网络。
误区三：把 TCP 重传当作“没问题”。TCP 重传虽然能保证数据到达，但重传期间视频帧已经过期，播放端会直接丢弃，表现为画面跳帧或花屏。
复盘要点：当推流出现卡顿时，不要急于调整编码参数。先通过 ping 和带宽测试确认网络三要素（带宽、延迟、丢包）是否达标。如果网络本身不满足推流要求，任何编码器优化都只是治标不治本。建议每次开播前记录网络基线数据，便于后续对比排查。