实时音视频中的 QoS

实时音视频中的 QoS

让每一帧都准时到达

科普性质技术文章 | 2026 年 4 月 | WebRTC 技术团队

引言：视频电话/云桌面远程访问背后发生了什么？

你可能每天都在用视频会议、远程桌面、在线游戏——画面流畅、声音清晰似乎理所当然。但如果有一天网络突然变差，你会发现画面卡顿、声音断断续续、鼠标点了没反应。

为什么会这样？因为实时音视频对网络的要求极其苛刻：

QoS（Quality of Service，服务质量）就是一系列技术手段的总称，目的是在不完美的网络环境下，尽可能保证用户体验。

第一章：网络世界的三大"敌人"

1.1 丢包（Packet Loss）

什么是丢包？ 数据在网络传输过程中"走丢了"，到不了目的地。

原因：路由器缓冲区满、无线干扰（Wi-Fi、4G/5G）、网络拥塞。

影响：视频马赛克/花屏、音频断续、操作丢失。

�� 类比：就像寄快递，100 个包裹发出去只有 97 个到了，3 个在路上丢了。

1.2 延迟（Latency）

什么是延迟？ 数据从发送端到接收端所花的时间。

总延迟 = 编码延迟(5-15ms) + 网络传输(2-50ms) + 排队(0-100ms) + 抖动缓冲(0-200ms) + 解码(2-10ms)

�� 类比：就像点外卖：商家做菜（编码）→ 骑手送餐（传输）→ 等电梯（排队）→ 你去拿（解码），每个环节都有等待。

1.3 抖动（Jitter）

什么是抖动？ 数据包到达的时间间隔不均匀。理想情况下每个包间隔 20ms，但实际可能 10ms、40ms、5ms、60ms 交替出现，导致画面一卡一卡。

�� 类比：就像等公交，虽然平均 10 分钟一班，但有时 2 分钟来一辆，有时 20 分钟才来。

第二章：对抗丢包 — FEC & NACK

2.1 FEC：前向纠错 —— "提前多寄几份"

原理：发送端在发出原始数据包的同时，额外发一些"冗余包"。接收端即使丢了部分包，也能靠冗余包恢复丢失内容。

发送端: [包1] [包2] [包3] [包4] [FEC冗余]

假设包3丢失 → 接收端用 FEC 冗余恢复包3 ✓

优点：0ms 额外延迟；缺点：持续消耗带宽（+10%~30%）

WebRTC 实现：FlexFEC —— 动态调整冗余率，丢包多时加保护，丢包少时节省带宽。

�� 类比：考试时除了正式答题纸，你还多写了一份备份。万一正式那份丢了，老师还能用备份打分。

2.2 NACK：丢包重传 —— "丢了就再寄一份"

原理：接收端发现丢包后，向发送端请求重新发送丢失的包。

流程：发送端发包 → 网络传输(包3丢失) → 接收端发现缺包3 → 发NACK请求 → 发送端重传包3 → 序列完整

优点：精准恢复，不浪费带宽；缺点：需要一个来回时间（RTT），增加延迟。

2.3 FEC vs NACK 对比

实际策略：FEC 和 NACK 通常同时使用——FEC 负责"快速兜底"对抗随机丢包，NACK 负责"精准补救"恢复 FEC 覆盖不到的丢包。

第三章：对抗延迟和抖动

3.1 抖动缓冲（Jitter Buffer）

在接收端设一个小缓冲区，先攒几帧，按照均匀的节奏播放。网络到达不均匀的数据包经过缓冲后，输出变得均匀稳定。

�� 类比：就像水库调节水流。河水有时多有时少（抖动），但水库缓冲后，下游出水量稳定。

3.2 Pacer：发送端节奏控制

编码器可能一次产出一大帧（关键帧 ~100KB），瞬间发出会造成网络突发。Pacer 把要发的包排成队列，按照均匀速率发送，减少拥塞。

3.3 全链路延迟优化

端到端延迟 = 编码(5-15ms) + Pacer(1-5ms) + 网络(2-50ms) + JitterBuffer(0-50ms) + 解码(2-10ms)

每个环节都是优化点：减小 Pacer holdback、使用拥塞控制避免排队、减小缓冲区大小。

第四章：带宽估计与拥塞控制

4.1 为什么需要带宽估计？

网络带宽不是固定的——同事下载大文件、Wi-Fi 信号波动、运营商限速，都会让可用带宽随时变化。如果发送速率超过网络承载能力，就会造成拥塞——丢包飙升、延迟暴涨。

4.2 GCC 拥塞控制算法

WebRTC 使用 GCC（Google Congestion Control）算法，通过两种信号判断网络状况：

信号一：丢包率 — 接收端定期报告丢包统计（RTCP Receiver Report），丢包率上升则降速。

信号二：延迟趋势 — 通过 TWCC 反馈分析延迟是否增大，延迟持续增大意味着拥塞，提前降速。

决策流程：收集反馈 → 分析趋势 → 网络正常(保持码率) / 拥塞(降速~30%) / 空闲(探测加速)

4.3 自适应码率（ABR）

拥塞控制决定降速时，编码器配合的三种策略：

硬件编码器场景：分辨率由硬件固定，只能降码率+降帧率。WebRTC 通过 SetRates(bitrate, fps) 回调通知硬件编码器。

第五章：音频质量保障

5.1 NetEQ：音频的"瑞士军刀"

NetEQ 是 WebRTC 中专门处理音频接收的模块，集成了：

• 抖动缓冲 — 平滑播放

• 丢包隐藏 (PLC) — 用算法"猜"出丢失的帧，人耳基本听不出

• 加速播放 — 延迟累积时略微加速 (1.05×-1.2×)，人耳不易察觉

• 减速播放 — 缓冲不够时略微拉伸，等新数据到达

• 自适应缓冲 — 根据网络动态调整缓冲区大小

5.2 低延迟 vs 稳定性

缓冲区大 → 稳定但延迟高；缓冲区小 → 低延迟但容易断续。低延迟场景（远程桌面、实时通话）倾向于减小缓冲区 + 开启快速加速。

第六章：数据通道 — 键鼠实时性

6.1 SCTP 协议

DataChannel 底层使用 SCTP 协议，介于 TCP 和 UDP 之间——支持可靠传输（可选）、有序传输（可选）、多流复用、消息边界保持。

6.2 延迟瓶颈与优化

SCTP 默认参数对键鼠传输太保守，核心瓶颈是延迟确认（Delayed ACK）：收到数据后等 200ms 再确认。

优化效果：键鼠操作延迟从 200-400ms 降至 20-40ms (10× 提升)。

第七章：各技术如何协同工作

QoS 不是单一技术，而是多个机制的协同配合。完整流程：

1. 正常传输：编码 → Pacer 平滑 → FEC 保护 → 网络传输 → 接收解码播放

2. 发生丢包：FEC 先尝试恢复 → 恢复不了 → NACK 请求重传 → 发送端重发

3. 网络变差：RTCP 反馈丢包率/延迟上升 → GCC 降低估计带宽 → 编码器降码率/帧率 → FEC 提高冗余率

4. 网络恢复：GCC 探测到空余带宽 → 逐步提升码率 → 恢复画质

全链路协作示意：

第八章：QoS 指标与质量衡量

8.1 关键指标

8.2 MOS 分（Mean Opinion Score）

MOS 是衡量通话质量的主观评分标准（1-5 分）：

• 5 ★★★★★ 优秀 — 听/看起来完美

• 4 ★★★★☆ 良好 — 有微小瑕疵但不影响

• 3 ★★★☆☆ 一般 — 能接受但有明显问题

• 2 ★★☆☆☆ 较差 — 勉强能用

• 1 ★☆☆☆☆ 极差 — 完全无法使用

通常视频会议要求 MOS ≥ 3.5，远程桌面更关注延迟和清晰度。

总结：QoS 的核心思想

QoS 不是某一个技术，而是一整套"在不完美网络中追求完美体验"的方法论。

没有"银弹"可以同时解决所有问题，QoS 的艺术在于根据具体场景，在各种矛盾之间找到最佳平衡点。

附录：术语表