2. 网络带宽不足：带宽概念、上行带宽不足的表现、如何测试上行带宽
说到推流卡顿，十次里有七八次都跟带宽有关。我刚开始做直播那会儿，总觉得编码参数调好了就万事大吉，结果上线第一天就被用户骂到怀疑人生。后来才明白——你本地编码再漂亮，网络这个水管不够粗，数据一样送不出去。
这一节我们就来聊聊带宽，尤其是上行带宽。说白了，推流就是你的机器不停地往服务器发数据，上行带宽决定了你每秒能发出去多少东西。
2.1 带宽到底是什么？
带宽不是「网速」，它更像一根水管的粗细。水管越粗，单位时间内能流过的水就越多。带宽的单位是 bps（bit per second），也就是每秒能传输多少比特。
这里有个常见的坑——大B和小b。运营商说的 100M 宽带，其实是 100 Mbps（兆比特每秒）。而我们推流时设置的码率，比如 5000 kbps，也是千比特每秒。换算成你平时下载文件看到的 MB/s，要除以 8：
100 Mbps ÷ 8 = 12.5 MB/s嗯，这个换算一定要刻在脑子里。我见过不止一个同事，拿着 100M 的宽带觉得推 10 Mbps 的流绰绰有余，结果卡成幻灯片——因为他忘了上行和下行是两回事。
核心概念速记：
- 下行带宽：你从互联网下载数据的速度。看视频、刷网页用的就是它。
- 上行带宽：你往互联网发送数据的速度。推流、上传文件、视频通话用的就是它。
- 运营商通常只保证下行，上行往往只有下行的 1/10 甚至更少。
2.2 上行带宽不足的表现
上行带宽不够，推流端会有什么症状？我总结了几条，你可以在自己的推流日志里对照着看：
| 表现 | 具体现象 | 严重程度 |
|---|---|---|
| 推流端上传抖动 | OBS 或编码器面板上的「上传速率」曲线频繁掉到 0 | ⚠️ 常见 |
| 编码器丢帧 | 日志中出现大量 "dropped frames due to network" | ⚠️ 常见 |
| 推流端 CPU 正常但画面卡 | 编码器没满载，但推出去的画面一帧一帧地跳 | ⚠️ 常见 |
| 观众端频繁缓冲 | 播放器一直在转圈，或者画面突然变模糊后又恢复 | 🔴 严重 |
| 推流端 RTMP 断连 | 日志报 "Failed to connect to RTMP server" 或 "Connection timed out" | 🔴 严重 |
我曾经在一个户外直播项目里遇到过这种情况：现场 4G 信号满格，但推流就是每隔 30 秒卡一次。后来一测上行，实际可用带宽只有 1.2 Mbps，而我们的推流码率设了 3 Mbps。你说能不卡吗？
避坑指南： 不要只看「信号格数」。4G/5G 信号满格只代表你离基站近，不代表基站给你分配了足够的上行资源。尤其是在演唱会、体育场这种人多的场景，基站的上行资源会被大量用户共享，实际可用带宽可能只有理论值的十分之一。
2.3 如何测试上行带宽？
测试上行带宽，我建议分三步走。别只信一个工具的结果，多角度验证才靠谱。
2.3.1 方法一：Speedtest 类工具（快速摸底）
打开 speedtest.net 或 fast.com，选一个离你推流服务器最近的节点。注意看 Upload 那一项。
但这里有个问题——Speedtest 测的是「尽力而为」的带宽，它会用多线程、大包去压满你的线路。而推流是单线程、持续小包的传输模式。所以 Speedtest 的结果往往比实际推流可用带宽 高 20%~50%。
我的习惯： Speedtest 测出来上行是 10 Mbps，那我推流码率就只设 6~7 Mbps，留 30% 的余量。别贪，贪了必卡。
2.3.2 方法二：iPerf3 测试（精准测量）
如果你有服务器权限，iPerf3 是最准的。它模拟的就是真实的 TCP/UDP 数据传输场景。
在服务器端启动：
iperf3 -s在推流端启动：
iperf3 -c 你的服务器IP -t 30 -i 1 -P 1参数说明：
-t 30：测试 30 秒，别太短，10 秒以内的测试波动太大-i 1：每秒输出一次结果，方便看稳定性-P 1：单线程，模拟推流的真实场景
看输出里的 Sender 那一行的带宽值。如果这个值波动超过 20%，说明你的上行线路不稳定，即使平均值够高，推流也可能会间歇性卡顿。
2.3.3 方法三：真实推流测试（最可靠）
工具测完，最后一步永远是拿真实推流跑一遍。我建议这样做：
- 用 OBS 或 FFmpeg 推一个固定画面的测试流（比如一张静态图 + 静音音频）
- 码率设为你目标码率的 80%
- 推 5 分钟，观察 OBS 面板的「丢帧率」和「上传速率」曲线
- 如果丢帧率 < 0.1%，且上传速率曲线平稳，说明带宽够用
- 如果丢帧率 > 1%，或者曲线频繁掉到 0，说明带宽不足，需要降码率
一句话总结： 上行带宽不足，最直接的解法就是降码率。从 8 Mbps 降到 6 Mbps，从 6 Mbps 降到 4 Mbps，直到丢帧率归零。别觉得降码率就是降画质——稳定流畅的 4 Mbps 比卡成狗的 8 Mbps 体验好一百倍。
2.4 带宽与推流参数的关系图
下面这张图帮你理清带宽、码率、分辨率、帧率之间的关系。我每次给团队新人培训都会画一遍：
这张图想表达的核心逻辑很简单：上行带宽是天花板。你的码率、分辨率、帧率这三项加起来的总数据量，绝对不能超过这个天花板。超过一点，卡顿；超过太多，断流。
我个人习惯在项目初期就先跑一遍 iPerf3 测试，拿到真实上行带宽后，再反推编码参数。这样后面出问题的概率会小很多。嗯，说白了就是——别等用户骂了才想起来测带宽，提前测好，省心省力。