1. 网络质量评估到底在评什么

做实时音视频这行，绕不开的一个话题就是网络质量评估。不管你是用 WebRTC 做一对一通话，还是用 RTC 方案搭多人会议，甚至是在小程序里播个低延迟直播，用户第一句抱怨永远是“卡了”“听不清”“画面糊了”。这些体感问题的根因，八成以上都落在网络传输上。但网络这东西，看不见摸不着，你不能等用户投诉了再去猜，得有一套能实时量化、能提前预警、能定位到具体环节的评估体系。

网络质量评估，英文常写作 Network Quality Evaluation，圈子里习惯简称 NQE。它要干的事情很明确：在媒体数据从采集、编码、发送、传输、接收到渲染的整条链路上，持续采集关键指标，通过一套算法模型把这些指标映射成一个可比较、可解释的质量分数或等级，最终回答三个问题——当前网络能不能撑住这个通话？如果撑不住，瓶颈在哪一段？接下来该做什么动作来补救？

这套东西适合谁看？如果你是刚接触 WebRTC 或 RTC 的开发者，正在被“为什么我的视频总是卡顿”折磨，那这篇内容能帮你建立一套完整的排查框架。如果你已经在做弱网优化，但评估手段还停留在“看用户反馈”的阶段，那这里面的指标拆解和实操方法可以直接拿去用。哪怕你是嵌入式方向、在折腾 STM32 内部 32kHz 时钟做 RTC 的硬件工程师，只要你的设备涉及网络传输，这套评估思路同样有参考价值——因为网络质量评估的本质是“用数据说话”，而不是靠感觉。

我见过太多团队，WebRTC 视频数据流流程图背得滚瓜烂熟，RTC 实时时钟电路设计得漂漂亮亮，但一到线上问题就抓瞎。原因很简单：流程图画的是理想路径，真实网络里丢包、抖动、乱序、带宽骤降才是常态。没有评估体系，你连“现在到底有多差”都说不清楚，更别提优化了。

2. 核心指标拆解与评估模型设计

2.1 从媒体流水线看指标采集点

要评估网络质量，先得搞清楚数据在哪几个地方“露馅”。以 WebRTC 为例，一条典型的视频数据流会经过这些环节：采集 → 预处理 → 编码 → 打包 → 发送 → 网络传输 → 接收 → 抖动缓冲 → 解码 → 渲染。每个环节都有对应的可观测指标，但真正能反映网络质量的，主要集中在发送端和接收端的传输层统计里。

发送端最核心的三个指标是： 发送码率 、 丢包率 、 往返时延 RTT 。接收端对应的是： 接收码率 、 丢包率 、 抖动 。注意，发送端和接收端看到的丢包率不是一回事——发送端统计的是“我发出去了多少包”，接收端统计的是“我实际收到了多少包”，两者之差才是真正被网络吃掉的部分。

我习惯把评估模型分成三层： 链路层指标 、 媒体层指标 、 体验层指标 。链路层看的是网络本身，比如 RTT、丢包、抖动、带宽估计值；媒体层看的是编码和传输的配合，比如码率自适应是否及时、关键帧请求频率、NACK/PLI 重传比例；体验层才是最终用户感知，比如卡顿率、首帧耗时、音画同步偏差。三层之间是因果关系，链路层恶化会导致媒体层异常，媒体层异常最终表现为体验层下降。

2.2 为什么不能只看丢包率

新手最容易犯的错，就是盯着丢包率一个指标看。丢包率 5% 就一定差吗？不一定。如果这 5% 丢的都是非关键帧的小包，而且接收端有 FEC 和前向纠错兜底，用户可能完全无感。反过来，丢包率只有 1%，但丢的全是 I 帧或者音频的关键包，那体验就是灾难性的。

所以评估模型里必须引入 丢包分布 和 丢包类型 两个维度。丢包分布看的是丢包是均匀发生还是突发集中，突发丢包对视频的伤害远大于均匀丢包。丢包类型则要区分是视频包还是音频包、是关键帧还是普通帧。我在实际项目里会用一个简单的加权公式来算“有效丢包影响”：

有效丢包影响 = 视频关键帧丢包 × 3 + 视频普通帧丢包 × 1 + 音频丢包 × 2

这个权重不是拍脑袋来的，是根据实际排查经验总结的。音频丢包之所以权重高，是因为人对声音断续的敏感度远高于画面轻微花屏。关键帧丢包权重最高，因为一个 I 帧丢了，后续所有 P 帧都解不出来，直接导致长卡顿。

2.3 抖动与 RTT 的联合判断

抖动（Jitter）衡量的是数据包到达时间间隔的变化程度。适度的抖动可以用抖动缓冲吸收，但抖动过大或者抖动缓冲设置不当，就会导致要么延迟增加，要么缓冲溢出丢包。RTT 则反映了端到端的往返延迟，它直接影响重传效率——RTT 越大，丢包后重传的代价越高。

这两个指标要联合看。我总结了一个简单的判断矩阵：

RTT 范围	抖动范围	判断	建议动作
< 50ms	< 20ms	优秀	保持当前策略
50-150ms	20-50ms	良好	关注趋势
150-300ms	50-100ms	一般	降低码率，增大缓冲
> 300ms	> 100ms	差	启用 FEC，考虑降级

这个矩阵不是绝对的，但能帮你快速定位问题方向。比如 RTT 正常但抖动很大，说明网络路径上可能有拥塞或者无线信号不稳定；RTT 很大但抖动正常，可能是物理距离远或者路由跳数多。

2.4 带宽估计与码率自适应

WebRTC 里有一套带宽估计机制，发送端根据接收端的反馈来调整发送码率。评估网络质量时，不能只看当前码率，要看 带宽估计值 和 实际发送码率 之间的差距。如果估计带宽是 2Mbps，但实际只发了 500kbps，说明编码器或者采集端有问题；如果估计带宽 500kbps，实际发了 2Mbps，那肯定要丢包。

我通常会计算一个“带宽利用率”指标：

带宽利用率 = 实际发送码率 / 带宽估计值

这个值在 0.7 到 0.9 之间是比较健康的。低于 0.7 说明带宽没用满，可能是编码器保守或者采集帧率低；高于 0.9 说明已经在极限边缘，稍有波动就会丢包。超过 1.0 那就是在超发，丢包是必然的。

3. 实操：从零搭建一套评估流程

3.1 数据采集：getStats 的正确用法

WebRTC 提供了 RTCPeerConnection.getStats() 接口，这是获取网络质量数据的主要途径。但很多人用不对，要么采集频率太高导致性能问题，要么采集频率太低错过突发异常。我的经验是： 正常状态下每 2 秒采集一次，检测到异常时自动切换到每 500 毫秒一次 。

采集的时候不要只拿一个时间点的快照，要拿两次采集之间的增量。比如丢包率，应该用两次采集之间新增的丢包数除以新增的发送包数，而不是用累计值直接除。累计值会平滑掉突发异常，让你误以为网络很稳定。

// 简化的采集逻辑示意
let lastStats = null;

async function collectStats(pc) {
  const stats = await pc.getStats();
  const current = {};
  
  stats.forEach(report => {
    if (report.type === 'outbound-rtp' && report.kind === 'video') {
      current.packetsSent = report.packetsSent;
      current.bytesSent = report.bytesSent;
      current.timestamp = report.timestamp;
    }
    if (report.type === 'remote-inbound-rtp' && report.kind === 'video') {
      current.packetsLost = report.packetsLost;
      current.roundTripTime = report.roundTripTime;
      current.jitter = report.jitter;
    }
  });
  
  if (lastStats) {
    const deltaSent = current.packetsSent - lastStats.packetsSent;
    const deltaLost = current.packetsLost - lastStats.packetsLost;
    const lossRate = deltaSent > 0 ? deltaLost / (deltaSent + deltaLost) : 0;
    // 用 lossRate 做后续判断
  }
  
  lastStats = current;
}

这段代码的关键在于用增量计算丢包率。我踩过的坑是：早期直接用累计丢包数除以累计发送数，结果一个持续 10 分钟的通话，前 30 秒的严重丢包被后面 9 分钟的稳定传输稀释了，丢包率显示只有 0.5%，但用户明明在前 30 秒卡得不行。

3.2 弱网模拟：不能等线上出问题才测

评估体系建好了，怎么验证它准不准？你得能主动制造弱网环境。我常用的工具组合是： Linux 上用 tc netem ， Windows 上用 Clumsy ， 移动端用手机自带的网络调试功能或者第三方弱网模拟 App 。

以 tc netem 为例，模拟 10% 丢包、100ms 延迟、50ms 抖动的命令是：

tc qdisc add dev eth0 root netem loss 10% delay 100ms 50ms

这条命令的意思是：在 eth0 网卡上添加一个网络模拟规则，丢包率 10%，基础延迟 100ms，抖动范围 ±50ms。测完之后用 tc qdisc del dev eth0 root 删除规则。

我建议在弱网模拟时重点观察三个场景： 突发丢包 （比如连续丢 20 个包然后恢复正常）、 带宽骤降 （从 2Mbps 突然降到 500kbps）、 高抖动 （延迟在 50ms 到 300ms 之间快速波动）。这三个场景覆盖了 90% 以上的真实弱网情况。

3.3 评估分数的计算与阈值设定

有了原始指标，接下来要把它变成一个可比较的分数。我一般用 0 到 100 的分数制，分数越高网络越好。计算方式不是简单的加权平均，而是 先分档再插值 。

以丢包率为例：0% 到 1% 算优秀，对应 90 到 100 分；1% 到 5% 算良好，对应 70 到 90 分；5% 到 10% 算一般，对应 50 到 70 分；10% 以上算差，对应 0 到 50 分。在每个档位内做线性插值，这样分数变化比较平滑，不会出现跳变。

RTT 和抖动也类似处理，最后取三者中的最低分作为综合网络质量分。为什么取最低分而不是平均分？因为网络质量遵循“木桶原理”——最差的那个指标决定了用户体验的上限。RTT 再好，丢包率 20%，通话照样没法用。

阈值设定要结合业务场景。一对一通话对 RTT 敏感，阈值可以设紧一点；多人会议对丢包更敏感，丢包阈值要设紧。我通常会准备两套阈值： 告警阈值 和 降级阈值 。告警阈值触发时记录日志、上报监控；降级阈值触发时自动执行码率下调、关闭视频等动作。

3.4 可视化与告警：让问题自己跳出来

数据采集了、分数算了，如果只是躺在日志里，那等于没做。我习惯用两种方式呈现： 实时曲线图 和 异常事件列表 。实时曲线图展示最近 5 分钟的丢包率、RTT、抖动、码率变化，方便快速判断趋势；异常事件列表则记录每一次分数跌破阈值的时间点和当时的指标快照，方便事后复盘。

告警策略上，我反对“一超阈值就告警”。网络本身就有波动，偶尔一次抖动很正常。我的做法是 连续 3 次采集都超过阈值才触发告警 ，这样能过滤掉大部分偶发波动。同时告警要分级：分数 60 到 70 是提醒，40 到 60 是警告，40 以下是严重。不同级别对应不同的通知方式和响应速度。

4. 常见问题与排查技巧实录

4.1 为什么 getStats 拿到的数据和实际体验对不上

这是被问得最多的问题。明明 getStats 显示丢包率只有 2%，但用户就是觉得卡。原因通常有三个：一是采集频率太低，错过了突发丢包；二是只看了视频流，没看音频流，音频丢包对体验影响更大；三是没有区分发送端和接收端的统计，发送端觉得没丢包，但接收端实际没收到。

排查方法：把采集频率临时调到 200ms 一次，同时采集音频和视频的收发两端数据，对比着看。如果发送端丢包率低但接收端丢包率高，说明问题出在中间网络；如果两端都低但用户还卡，那可能是解码性能或者渲染环节的问题，跟网络无关。

4.2 弱网下码率降不下来怎么办

WebRTC 的码率自适应有时候会“反应迟钝”。带宽已经掉到 500kbps 了，发送码率还在 1.5Mbps 硬撑，结果就是大量丢包。这种情况通常是带宽估计器没有及时收敛，或者编码器没有响应码率调整指令。

我的处理办法是：在评估体系里加一个“码率超发检测”，当实际发送码率超过带宽估计值 1.2 倍且持续 2 秒以上，就强制触发一次码率重算。同时检查编码器配置，确保它支持动态码率调整。有些硬编码器对码率调整的响应很慢，这时候可以考虑切换到软编码或者调整关键帧间隔来加速收敛。

4.3 移动端网络切换时的评估盲区

手机从 Wi-Fi 切到 4G，或者从 4G 切到 5G，网络质量会发生剧烈变化。但 WebRTC 的评估体系在切换瞬间往往有 1 到 3 秒的盲区，因为旧的连接还没完全断开，新的连接还没稳定。这段时间的统计数据是混乱的，不能直接用来判断。

我的做法是在评估逻辑里加一个“网络切换检测”：当 RTT 或者丢包率在短时间内发生超过 50% 的突变，就标记为疑似切换，暂停评分 3 秒，等指标稳定后再恢复。同时记录切换前后的指标对比，这对分析切换成功率很有帮助。

4.4 常见问题速查表

现象	可能原因	排查方向	解决建议
丢包率低但卡顿明显	突发丢包被平均	提高采集频率，看增量	用增量计算，关注突发
码率降不下来	带宽估计未收敛	检查估计值与实际值差距	强制重算，检查编码器
音频断续但视频正常	音频包优先级低	检查音频丢包率	提高音频 FEC 强度
切换网络后质量差	评估盲区	看切换前后指标突变	加切换检测，暂停评分
分数高但用户投诉	评估维度不全	检查是否漏采关键指标	补充端到端延迟等指标

4.5 几个我踩过的坑

第一个坑： 只评估不记录 。早期我觉得实时看指标就行了，没必要存历史数据。结果有一次线上大面积卡顿，事后想复盘，发现什么数据都没留下。从那以后，我要求所有评估数据至少保留 7 天，关键指标保留 30 天。

第二个坑： 阈值一刀切 。不同地区、不同运营商的网络基线不一样，用同一套阈值会导致某些地区频繁误告警。后来我改成了动态阈值：根据过去 24 小时的历史数据计算基线，阈值设为基线的 1.5 倍。这样既能发现异常，又不会因为地区差异误报。

第三个坑： 忽略设备性能 。有些卡顿根本不是网络问题，是设备解码能力不足。评估体系里应该加一个“设备负载”指标，当 CPU 占用率超过 80% 时，网络质量分数要打折扣，因为这时候即使网络很好，设备也处理不过来。

5. 从评估到优化：闭环才是终点

评估本身不是目的，基于评估结果做优化才是。我习惯把优化动作分成三档： 轻度优化 包括调整抖动缓冲大小、微调码率上限； 中度优化 包括启用 FEC、调整关键帧间隔、切换编码档次； 重度优化 包括关闭视频只保留音频、降低分辨率、甚至主动断线重连。

每档优化动作都要有明确的触发条件和回滚机制。比如启用 FEC 后，如果丢包率没有下降反而延迟增加了，就要自动回滚。这个闭环逻辑我一般写在客户端，因为服务端做的话延迟太高，等指令传下来，通话可能已经断了。

还有一点很重要： 评估体系要能区分“网络问题”和“非网络问题” 。我见过太多团队，一卡顿就怪网络，结果查了半天发现是采集设备驱动有问题。所以在评估报告里，我会明确标注“网络因素占比”和“非网络因素占比”，帮助团队快速定位方向。

这套东西搭起来不难，难的是持续迭代。网络环境在变，业务场景在变，评估模型也得跟着调。我现在的做法是每季度回顾一次阈值和权重，根据实际告警准确率和漏报率来微调。没有一劳永逸的评估体系，只有不断逼近真实的评估体系。