网络基础回顾：带宽、延迟、抖动、丢包率

做推流诊断这些年，我见过太多人一卡顿就盯着编码参数猛调。其实很多时候，问题出在网络身上。你想想看，编码器输出的数据再漂亮，网络要是扛不住，观众看到的照样是马赛克和转圈圈。

今天咱们就把四个最基础的网络指标掰开揉碎讲清楚。带宽、延迟、抖动、丢包率——这四个家伙是怎么联手搞垮你的推流质量的？

一句话总结：带宽决定你能不能推，延迟决定观众多久看到，抖动和丢包决定画面是否流畅。四个指标缺一不可。

带宽说白了就是单位时间内能传输多少数据。我习惯把它想象成水管——水管越粗，单位时间流过的水就越多。

推流时，编码器产出的码率必须小于可用带宽。否则就会发生“拥塞”，数据包排队等发送，最终被丢弃。

注意：运营商给的带宽是“最大”值，不是“保证”值。晚高峰时实际可用带宽可能只有标称值的一半。我曾经在直播演唱会时遇到过，标称 100M 的家宽，实际上行只有 8M，推 1080p 直接崩了。

带宽不足时，推流端会怎么做？要么主动降码率（画质变差），要么丢帧（画面卡顿）。我建议你在推流软件里开启“带宽自适应”功能，让编码器根据实时带宽动态调整码率。

延迟就是数据从发送端到接收端所花的时间。单位是毫秒。

推流场景下，延迟包括：采集延迟 + 编码延迟 + 网络传输延迟 + 解码延迟 + 渲染延迟。网络传输延迟只是其中一环。

很多人有个误区：觉得延迟越低越好。其实不然。低延迟意味着缓冲区小，网络稍有波动就会卡顿。高延迟则能提供更好的抗抖动能力。

我的经验：做游戏直播时，我习惯把延迟控制在 2-3 秒。太低了观众看到画面撕裂，太高了弹幕和画面对不上。这个区间是大多数观众的“舒适区”。

抖动是延迟的变化量。举个例子：第一个包延迟 50ms，第二个包 150ms，第三个包又回到 60ms——这种波动就是抖动。

抖动比高延迟更可怕。为什么？因为播放器可以容忍稳定的高延迟（比如 500ms），但无法容忍忽快忽慢的延迟。抖动会导致播放器缓冲区频繁“饥饿”或“溢出”，画面就会一卡一卡的。

我遇到过最典型的案例：某客户推流到海外，平均延迟只有 120ms，但抖动高达 80ms。观众反馈画面每隔几秒就卡一下。后来加了 500ms 的 jitter buffer，问题解决了。

关键公式：抖动 = 延迟的标准差。一般要求抖动 < 30ms 才算健康。超过 50ms 就需要加缓冲区来平滑。

丢包率就是发送的数据包中，没有到达接收端的比例。单位是百分比。

丢包对推流的影响最直接：

丢包率在 0.1% 以下基本无感。超过 0.5% 就开始影响体验。超过 2% 基本没法看了。

避坑指南：我曾经遇到一个案例，丢包率只有 0.3%，但观众反馈卡得不行。排查后发现是“突发丢包”——0.3% 的丢包集中在 1 秒内，导致连续丢了 3 个关键帧。所以不仅要看平均丢包率，还要看丢包的分布模式。

单独看任何一个指标都不够。它们之间会互相影响：

我习惯用一张图来理解它们的关系：

做推流诊断时，我有一套固定的排查顺序：

小技巧：我习惯在推流软件里同时开启“实时网络统计”面板。OBS 和 vMix 都有这个功能。一边推流一边看四个指标的变化，比事后分析日志直观得多。

记住一个原则：先保证不卡，再追求低延迟。观众可以接受画面晚到 2 秒，但无法接受画面每隔 5 秒卡一次。这个优先级排序，是我踩过无数坑之后总结出来的。