28、WebRTC的实时通信质量指标：RTT、Jitter、Packet Loss、MOS评分

做WebRTC开发这些年，我见过太多人一上来就调编码参数、改传输策略，结果效果还是不行。为什么？因为连最基本的通信质量指标都没搞清楚。你连问题在哪都不知道，怎么对症下药？

今天咱们就把这四个核心指标掰开揉碎了讲清楚：RTT、Jitter、Packet Loss、MOS评分。它们就像汽车的仪表盘，告诉你发动机有没有过热、轮胎有没有漏气。没有这些数据，你就是在闭着眼睛开车。

一句话总结：RTT看延迟，Jitter看抖动，Packet Loss看丢包，MOS看主观体验。四个指标缺一不可。

RTT（Round-Trip Time）—— 网络延迟的硬指标

RTT，说白了就是数据包从A到B再回到A的总耗时。单位是毫秒（ms）。

在WebRTC里，RTT主要通过RTCP的Sender Report（SR）和Receiver Report（RR）来测量。具体怎么算的？

// 伪代码：RTT计算逻辑
// 发送方在SR中记录 NTP 时间戳
// 接收方在RR中回复：上次收到SR的时间(LSR) + 自上次收到SR以来的延迟(DLSR)
// 发送方收到RR时，记录当前时间 A
// RTT = A - LSR - DLSR

嗯，公式看着有点绕。你只要记住：RTT越小越好。

RTT范围 体验描述 我遇到过的情况
< 50ms 几乎无感知，像面对面说话 同城局域网，基本完美
50ms - 150ms 轻微延迟，大部分场景可接受 跨省通信，多数用户能接受
150ms - 300ms 明显延迟，对话开始有重叠 跨国链路，需要做延迟补偿
> 300ms 对话困难，基本无法正常交流 卫星链路或严重拥塞，建议降级

我的经验：我曾经帮一个客户排查视频通话卡顿问题，发现RTT在200ms左右徘徊。一开始以为是网络问题，后来发现是他们的STUN/TURN服务器部署在海外，国内用户绕了一大圈。换成国内节点后，RTT直接降到40ms。所以，节点部署位置非常关键。

Jitter（抖动）—— 延迟的“忽快忽慢”

RTT看的是平均延迟，但网络不是匀速的。有时候快，有时候慢。这种延迟的变化量，就是Jitter。

你想想看，如果每个包都稳定延迟100ms，其实问题不大。但如果有的包50ms到，有的包200ms到，接收端就乱了套了。音频会断断续续，视频会一卡一卡的。

WebRTC里Jitter的计算方式：

// RFC 3550 中定义的Jitter计算公式
// J(i) = J(i-1) + (|D(i-1,i)| - J(i-1)) / 16
// 其中 D(i-1,i) 是相邻两个包的到达时间差减去发送时间差

公式不用死记，你只要知道：Jitter越大，网络越不稳定。

WebRTC内部有一个Jitter Buffer，专门用来对抗抖动。它的工作原理很简单：

  • 收到包后不立即播放，先缓存一会儿
  • 等缓存积累到一定程度，再以稳定的速率播放
  • 如果Jitter突然变大，Buffer会自动扩容

注意：Jitter Buffer是一把双刃剑。Buffer越大，抗抖动能力越强，但延迟也越大。我见过有人把Buffer设成500ms，抖动是没了，但延迟高到没法对话。所以Jitter Buffer的大小需要动态调整，WebRTC默认是自适应的，一般不建议手动改。

Packet Loss（丢包率）—— 数据包去哪了？

丢包，就是发送方发出的数据包，接收方没收到。原因很多：网络拥塞、路由器丢包、无线信号干扰……

在WebRTC里，丢包率通过RTCP的RR包来统计。接收方会告诉发送方：我总共收到了多少包，丢了多少包。

// 丢包率计算
// 丢包率 = (期望收到的包数 - 实际收到的包数) / 期望收到的包数 * 100%

丢包对实时通信的影响非常大：

  • 音频丢包：出现“咔咔”声，或者字词丢失
  • 视频丢包：画面出现马赛克、花屏、卡顿
  • 数据通道丢包：文件传输失败，或者消息丢失
丢包率 音频影响 视频影响
< 1% 几乎无感知 几乎无感知
1% - 5% 偶尔有杂音，但可理解 轻微马赛克，偶发卡顿
5% - 10% 频繁断字，难以听清 明显花屏，频繁卡顿
> 10% 基本无法沟通 画面严重损坏，无法观看

避坑指南：我曾经遇到一个案例，丢包率只有2%，但用户反馈视频非常卡。排查后发现，这2%的丢包不是均匀分布的，而是集中在某几秒内爆发。也就是说，平均丢包率低不代表体验好，还要看丢包的模式。WebRTC的NACK（重传请求）和FEC（前向纠错）就是用来对抗丢包的，但各有优缺点。NACK会增加延迟，FEC会增加带宽消耗。具体用哪个，得看场景。

MOS评分（Mean Opinion Score）—— 用户说好才是真的好

前面三个指标都是客观的，但用户不关心RTT是多少毫秒，他们只关心“听起来怎么样”、“看起来怎么样”。MOS评分就是用来衡量这种主观体验的。

MOS评分最初是ITU-T定义的，用于电话语音质量评估。评分范围1到5：

  • 5分：完美，像面对面说话
  • 4分：良好，有轻微失真但不影响理解
  • 3分：一般，有明显失真但还能沟通
  • 2分：差，很难听清，沟通困难
  • 1分：极差，完全无法沟通

传统MOS评分需要大量用户做主观测试，成本高、周期长。所以在实际工程中，我们常用客观MOS模型来估算，比如：

  • PESQ（Perceptual Evaluation of Speech Quality）：ITU-T P.862标准，比较原始音频和接收音频的差异
  • POLQA（Perceptual Objective Listening Quality Assessment）：PESQ的升级版，ITU-T P.863标准
  • E-Model：ITU-T G.107标准，通过RTT、丢包率、编码类型等参数计算R值，再映射到MOS
// E-Model 简化版：R值到MOS的映射
// R值范围 0-100
// MOS = 1 + 0.035*R + R*(R-60)*(100-R)*7e-6
// 当 R < 0 时，MOS = 1
// 当 R > 100 时，MOS = 4.5

在实际项目中，我一般用E-Model做实时监控。把RTT、丢包率、编码类型这些参数喂进去，就能算出当前的MOS估值。如果MOS低于3.0，就触发告警或者自动调整策略。

核心观点：RTT、Jitter、Packet Loss是“因”，MOS是“果”。你优化了前三个指标，MOS自然会提升。但要注意，MOS是一个综合指标，有时候RTT很低、丢包也很少，但MOS还是不高——那可能是编码质量不行，或者Jitter Buffer设置不合理。

四个指标的关系与权衡

这四个指标不是孤立的，它们互相影响。我画了一张图，帮你理清它们的关系：

WebRTC 四大质量指标关系图 RTT 延迟 Jitter 抖动 Packet Loss 丢包 延迟波动 Buffer溢出导致 MOS 评分 主观体验 共同影响 优化策略 降低RTT → 减少Jitter → 控制丢包 → 提升MOS （但要注意：降低Jitter Buffer会增大丢包，需要权衡）

从图上你能看到：

  • RTT高会导致Jitter变大（网络拥塞时延迟波动更剧烈）
  • Jitter大会导致Packet Loss（Jitter Buffer溢出，来不及处理的包被丢弃）
  • RTT、Jitter、Packet Loss三者共同决定MOS评分

所以，优化的时候不能只盯着一个指标。我个人的习惯是：先看MOS，如果MOS低，再逐个排查RTT、Jitter、丢包。哪个指标异常，就优先处理哪个。

一个常见的误区：有人觉得只要丢包率降到0%，体验就一定好。其实不一定。为了降低丢包，你可能用了非常激进的重传策略（NACK），结果RTT飙升到300ms。用户虽然不丢包了，但延迟高到没法对话。所以指标之间需要平衡，没有绝对的最优值，只有最适合你场景的值。

实战：如何获取这些指标

在WebRTC中，获取这些指标其实很简单。通过RTCPeerConnection的getStats() API就能拿到。

// 获取WebRTC统计信息
const pc = new RTCPeerConnection(configuration);

// 每隔1秒获取一次统计信息
setInterval(async () => {
  const stats = await pc.getStats();
  
  stats.forEach(report => {
    if (report.type === 'candidate-pair' && report.state === 'succeeded') {
      // RTT（单位：秒）
      console.log('RTT:', report.currentRoundTripTime * 1000, 'ms');
    }
    
    if (report.type === 'inbound-rtp' && report.kind === 'video') {
      // Jitter（单位：秒）
      console.log('Video Jitter:', report.jitter * 1000, 'ms');
      // 丢包率
      const packetsLost = report.packetsLost;
      const packetsReceived = report.packetsReceived;
      const lossRate = packetsLost / (packetsLost + packetsReceived) * 100;
      console.log('Video Packet Loss:', lossRate.toFixed(2), '%');
    }
    
    if (report.type === 'inbound-rtp' && report.kind === 'audio') {
      // 音频Jitter
      console.log('Audio Jitter:', report.jitter * 1000, 'ms');
    }
  });
}, 1000);

我的建议：在生产环境中，不要只打印到控制台。把这些指标上报到你的监控系统，比如Prometheus + Grafana。设置告警阈值：RTT > 200ms告警，丢包率 > 5%告警。这样你就能在用户投诉之前发现问题。

好了，四个核心指标就讲到这里。记住：RTT看延迟，Jitter看抖动，丢包看可靠性，MOS看体验。下次再遇到WebRTC通话质量差的问题，你知道该看什么了吧？

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →