26、WebRTC故障排查：常见连接失败原因、音视频不同步解决、网络抖动处理
做WebRTC开发，说白了就是跟各种不确定性打交道。我做了这么多年实时通信，最深的体会就是——出问题是常态，不出问题才是意外。这一章，我就把那些年踩过的坑、填过的土，好好跟你聊聊。
一、连接失败：最常见的“见面死”
你想想看，两个浏览器好不容易要“握手”了，结果死活连不上。这种情况我遇到过不下几十次。原因其实就那么几类，咱们一个一个说。
1.1 ICE候选收集失败
ICE（Interactive Connectivity Establishment）是WebRTC的“探路者”。它负责找到一条能通的路。如果这条路没找到，连接自然就断了。
核心原因：
- STUN/TURN服务器配置错误
- 防火墙阻断了UDP端口
- NAT类型太严格（对称NAT）
我记得有一次，客户反馈说视频死活连不上。我查了半天，最后发现是STUN服务器的地址写错了——多了一个空格。嗯，这种低级错误，谁还没犯过呢？
我的排查习惯：先看浏览器控制台的ICE日志。如果看到candidate:typ host但没有typ srflx或typ relay，那基本就是STUN/TURN的问题。
1.2 SDP协商不匹配
SDP（Session Description Protocol）是双方的“自我介绍”。你说你支持H.264，我说我只支持VP8——那还怎么聊？
我曾经遇到过一个案例：两端都是Chrome，但一个版本是78，另一个是86。结果因为编解码器优先级不同，协商失败。折腾了两小时，最后升级浏览器版本解决。
// 检查SDP是否匹配的简单方法
// 在offer端打印SDP
console.log('Local SDP:', offer.sdp);
// 在answer端打印SDP
console.log('Remote SDP:', answer.sdp);
// 重点检查：
// 1. m=audio 和 m=video 行是否存在
// 2. a=rtpmap 中是否有共同的编解码器
// 3. a=candidate 行是否非空注意：不要盲目相信“Chrome对Chrome一定能连”。不同版本、不同操作系统，SDP的生成逻辑可能有细微差异。我建议你在两端都打印SDP，手动对比一下。
二、音视频不同步：看着难受，听着更难受
画面里嘴在动，声音却慢半拍。这种体验，用户能忍三秒算我输。音视频不同步，专业术语叫“唇同步”（Lip Sync）问题。
2.1 时间戳的“猫腻”
WebRTC里，音频和视频用的是不同的时间戳时钟。音频通常是48kHz，视频可能是90kHz。如果这两个时钟不同步，那画面和声音就各走各的了。
说白了，就是音频说“我走到第48000步了”，视频说“我走到第90000步了”。但这两个“步”的长度不一样，你得换算一下。
解决思路：
- 确保发送端使用相同的参考时钟（如NTP时间）
- 接收端通过RTCP SR（Sender Report）中的NTP时间戳来对齐
- 缓冲区不要太大——我一般控制在200ms以内
2.2 我的实战经验
有一次做远程医疗项目，医生抱怨说“看到病人张嘴，声音要等半秒才到”。我检查了网络，延迟才30ms，不应该是网络问题。
后来发现，是视频处理管线里加了一个美颜滤镜，处理耗时太长。音频是直通的，视频却绕了一大圈。结果就是音频等视频，不同步了。
解决方案：给音频也加一个等量的延迟，或者优化视频处理速度。我选择了后者——把美颜算法从CPU换到GPU，延迟从150ms降到了20ms。
快速检测方法：用RTCPeerConnection.getStats()查看jitterBufferDelay和totalSamplesReceived。如果音频的抖动缓冲延迟远大于视频，那就要调整了。
三、网络抖动：实时通信的头号杀手
网络抖动（Jitter），就是延迟忽高忽低。上一包走了10ms，下一包走了200ms。这种不确定性，对实时通信是致命的。
3.1 抖动从哪来？
说白了，就是网络拥堵、路由变化、Wi-Fi信号不稳定这些原因。我见过最夸张的一次，抖动从5ms跳到了800ms——用户直接骂娘了。
3.2 怎么处理？
WebRTC内部有抖动缓冲（Jitter Buffer），但它不是万能的。你需要配合一些策略：
| 策略 | 原理 | 适用场景 |
|---|---|---|
| 增大抖动缓冲 | 多缓存一些数据，平滑抖动 | 网络抖动大但带宽充足 |
| 降低码率 | 减少数据量，降低网络压力 | 带宽不足导致抖动 |
| FEC（前向纠错） | 发送冗余数据，丢包也能恢复 | 丢包率高且抖动大 |
| NACK（重传） | 丢包后请求重传 | 抖动小但偶尔丢包 |
我的建议：不要死磕一种策略。我通常的做法是——动态调整。抖动小时用NACK，抖动大时切到FEC。带宽不够时，先降码率，再考虑其他方案。
3.3 一个实用的抖动检测代码
// 通过getStats获取抖动数据
async function checkJitter(pc) {
const stats = await pc.getStats();
let jitter = 0;
stats.forEach(report => {
if (report.type === 'inbound-rtp' && report.kind === 'video') {
jitter = report.jitter; // 单位：秒
console.log(`当前视频抖动: ${(jitter * 1000).toFixed(2)}ms`);
}
});
// 如果抖动超过100ms，触发降级策略
if (jitter > 0.1) {
console.warn('抖动过大，建议降低码率或切换FEC');
// 这里可以触发码率调整逻辑
}
return jitter;
}
// 每5秒检测一次
setInterval(() => checkJitter(pc), 5000);避坑指南：我曾经在抖动检测里犯过一个错——直接用jitter字段的值做判断，没注意它单位是秒。结果阈值设成了0.1，实际应该是100ms。嗯，这种单位换算的坑，你也要小心。
四、知识体系总览
下面这张图，是我梳理的WebRTC故障排查核心逻辑。你可以把它当成一张“作战地图”。
这张图把三大问题、排查步骤和解决方案串在了一起。你排查的时候，就按这个顺序来——先看连接，再看同步，最后处理抖动。别跳步，跳步容易漏掉关键信息。
好了，这一章的内容就到这。故障排查这东西，光看理论没用，你得真去踩坑、真去修bug。下次遇到问题，别慌，按我上面说的步骤来，八成能搞定。
公众号:蓝海资料掘金营，微信deep3321