4、丢包率与QoS：丢包率测量方法、QoS参数（延迟、抖动、丢包）、用户体验评估。
聊到WebRTC的抗丢包能力，有个问题绕不开——你连丢了多少包都不知道，怎么选策略？
我见过不少团队，一上来就堆FEC、开NACK，结果带宽炸了，延迟也上去了。说白了，没有测量就没有优化。这一章我们就来聊聊丢包率怎么测、QoS三个核心参数怎么理解，以及这些东西最终怎么影响用户的体验。
4.1 丢包率的测量方法
丢包率不是凭空猜的。WebRTC内部有一套成熟的测量机制。我个人习惯把它分成两类：接收端统计和发送端推断。
4.1.1 基于RTP序列号的接收端统计
这是最直接的方法。每个RTP包都有一个递增的序列号（Sequence Number）。接收端只要数一数：
丢包率 = (期望收到的包数 - 实际收到的包数) / 期望收到的包数举个例子：
- 上一包序列号是100，这一包是150，中间跳过了49个序号
- 实际收到了48个包（有一个可能乱序到了）
- 丢包率 ≈ (49 - 48) / 49 ≈ 2%
4.1.2 基于RTCP的发送端反馈
接收端会定期发送RTCP RR（Receiver Report）给发送端。里面包含了丢包率、累计丢包数、最高序列号等信息。发送端拿到这些数据，就能知道远端看到的网络质量。
RTCP的反馈周期默认是5秒一次。但5秒对于实时通信来说太慢了。所以WebRTC引入了Transport-CC（Transport-Wide Congestion Control），把反馈频率提升到了每帧甚至每个包组级别。
4.1.3 探测包法（Probe-based）
有时候你需要主动探测网络，而不是被动等待数据流。比如在通话建立初期，或者网络切换后。这时候可以发送一些探测包（Padding包或Dummy包），统计它们的丢失情况。
WebRTC的PacedSender模块就支持这种模式。它会以特定速率发送填充包，然后根据接收端的反馈来评估当前网络的丢包率。
4.2 QoS三大参数：延迟、抖动、丢包
QoS（Quality of Service）在实时通信里，核心就三个指标。我习惯把它们叫做「铁三角」——互相制约，一个变差往往会影响另外两个。
| 参数 | 定义 | WebRTC中的典型值 | 对体验的影响 |
|---|---|---|---|
| 延迟（Latency） | 数据从发送端到接收端的单向时间 | < 150ms 优秀；150-300ms 可接受；> 300ms 明显感知 | 延迟越高，对话越像「对讲机」，无法自然交流 |
| 抖动（Jitter） | 延迟的变化量，即包到达时间的不稳定性 | < 30ms 良好；30-60ms 需要抖动缓冲；> 60ms 容易卡顿 | 抖动导致播放不连续，声音忽快忽慢，画面跳帧 |
| 丢包（Packet Loss） | 传输过程中丢失的数据包比例 | < 1% 几乎无感；1-5% 可恢复；> 5% 明显劣化 | 丢包导致声音断续、画面花屏、马赛克 |
你想想看，这三个参数其实是联动的。比如网络拥塞时，路由器开始丢包，发送端检测到丢包后重传（NACK），重传又增加了延迟。延迟一高，接收端的抖动缓冲被迫增大，整体体验就下去了。
4.3 用户体验评估：从指标到感受
技术指标归指标，用户感受归感受。我见过很多团队，丢包率控制在1%以内，延迟50ms，但用户还是说卡。为什么？因为指标的测量粒度和用户的感知粒度不一样。
4.3.1 主观评估：MOS分
MOS（Mean Opinion Score）是ITU-T定义的语音/视频质量主观评分标准。1分最差，5分最好。虽然它需要真人打分，但业界总结了一些经验公式，可以用客观指标来估算MOS。
对于语音，一个常用的简化模型是：
MOS = 1 + 0.035 * R + 7 * 10^(-6) * R * (R - 60) * (100 - R)其中R值由延迟、丢包、编解码器类型等因素综合计算。嗯，这个公式看着复杂，但实际用起来，你只需要知道：R值低于70，用户就开始抱怨了。
4.3.2 客观评估：WebRTC Stats API
WebRTC原生提供了getStats()接口，可以拿到非常细粒度的QoS数据。我个人习惯关注这几个关键字段：
packetsLost：累计丢包数jitter：当前抖动值（秒）roundTripTime：RTT（往返时间）totalAudioEnergy/totalSamplesDuration：用于计算语音活动检测，辅助判断「静音丢包」还是「真丢包」
4.3.3 从指标到体验的映射
光看数字没用，你得知道这些数字在用户耳朵里、眼睛里是什么感觉。我整理了一个对照表：
| 用户感知 | 背后可能的指标 | 典型阈值 |
|---|---|---|
| 「声音断断续续」 | 丢包率 > 3% 且无有效恢复 | 丢包率 > 3% |
| 「我说完话对方半天才回」 | 单向延迟 > 300ms | 延迟 > 300ms |
| 「画面突然糊了又清晰」 | 抖动导致关键帧丢失，触发IDR请求 | 抖动 > 50ms |
| 「声音像机器人」 | 丢包恢复使用了PLC（丢包隐藏），但效果差 | 连续丢包 > 3个包 |
| 「视频卡住不动，但声音正常」 | 视频包大量丢失，解码器等待参考帧 | 视频丢包率 > 5% |
4.4 知识体系：丢包率与QoS全景图
下面这张图，我把本章的核心逻辑串起来了。从测量方法到QoS参数，再到用户体验评估，你可以看到它们之间的依赖关系。
4.5 实战建议：如何搭建你的QoS监控体系
说了这么多理论，最后给点实在的。如果你要在自己的WebRTC应用中搭建QoS监控，我建议按这个步骤来：
- 埋点：在发送端和接收端都开启
getStats()采集，每1秒拉一次数据 - 聚合：把原始数据按5秒窗口做滑动平均，消除瞬时波动
- 分级：设定三个等级——绿色（丢包<1%，延迟<150ms）、黄色（丢包1-3%，延迟150-300ms）、红色（丢包>3%，延迟>300ms）
- 联动：当指标进入黄色区域时，自动启用NACK；进入红色区域时，启用FEC并降低编码码率
- 记录：把每次策略切换的上下文（时间、指标值、策略类型）记录下来，方便事后分析
好了，这一章的内容就到这里。丢包率的测量和QoS的理解，是后续所有抗丢包策略的基础。你只有把「病」诊断清楚了，才能开对「药」。