30、综合实战：构建一个低延迟、高可用的 WebRTC 应用、QoS 策略调优全流程、常见问题与解决方案总结。
好，终于到了最后一章。说实话，前面讲了那么多理论、算法、参数，最后都得落到一个能跑起来的应用上。这一章，我就带你把前面学的所有 QoS 手段串起来，做一个真正能抗住弱网、延迟还低的 WebRTC 应用。
我会从架构设计开始，一步步讲调优流程，最后把那些我踩过的坑、常见的翻车现场都给你列出来。你跟着走一遍，基本就能应付大部分生产环境的问题了。
整体架构：分层解耦，各司其职
先看整体架构。我习惯把 QoS 相关的逻辑拆成三层，这样出了问题好排查，也方便单独升级策略。
核心思路：采集层只负责拿数据，决策层只负责算策略，执行层只负责把策略怼到 PeerConnection 上。千万别混在一起。
你看这个图，最下面有个虚线箭头，那是反馈闭环。采集层拿到数据，喂给决策层，决策层算出策略，执行层改参数，然后下一轮采集再看效果。这个循环我一般设 1 到 2 秒一次，太快了 CPU 扛不住，太慢了反应不过来。
调优全流程：从默认配置到极致体验
下面我带你走一遍完整的调优流程。假设你刚搭好一个视频通话应用，用的是默认配置。嗯，默认配置在局域网里跑得挺欢，一上公网就原形毕露了。
第一步：基线测试
先别急着调参数。你得知道当前应用在好网和坏网下的表现。我一般用 chrome://webrtc-internals 抓一轮数据，重点关注这几个指标：
| 指标 | 好网（WiFi） | 差网（3G 模拟） | 说明 |
|---|---|---|---|
| RTT | 20~50ms | 200~500ms | 越高越影响交互 |
| 丢包率 | <0.5% | 5%~15% | 超过 5% 画面就开始花了 |
| 视频码率 | 1.5~2 Mbps | 200~400 Kbps | 带宽估计会主动降 |
| 帧率 | 30 fps | 8~15 fps | 低于 15 就感觉卡了 |
我的习惯：用 Chrome 的 Network Throttling 模拟弱网，别真跑到户外去测。模拟丢包 10%、延迟 300ms 就够看出问题了。
第二步：开启关键 QoS 开关
基线数据拿到了，接下来改配置。我建议你按这个顺序来：
- 开启 TWCC（Transport Wide Congestion Control） —— 这是现代带宽估计的基础，默认可能没开。
- 设置合理的码率上下限 —— 别让编码器放飞自我。
- 配置 FEC 策略 —— 丢包率超过 5% 时，开启 ULPFEC 或 FlexFEC。
- 启用 SVC（可伸缩编码） —— 如果编码器支持，这是降级最平滑的方式。
代码示例，怎么设置码率上下限：
const sender = pc.getSenders().find(s => s.track.kind === 'video');
const params = sender.getParameters();
params.encodings[0].minBitrate = 200000; // 200 Kbps
params.encodings[0].maxBitrate = 1500000; // 1.5 Mbps
params.encodings[0].scaleResolutionDownBy = 1.0; // 初始不降
await sender.setParameters(params);这里有个坑：setParameters 不是所有浏览器都支持动态改所有字段。我在项目中遇到过，Chrome 可以改码率，但 Safari 会直接抛异常。所以调用前最好 try-catch 一下。
第三步：动态降级策略
静态配置搞定了，接下来是动态调优。说白了，就是网络变差时主动降级，网络恢复时再升回来。
我常用的策略是这样的：
- 丢包率 > 5% 且持续 3 秒：降分辨率到 640x360，同时开启 FEC。
- 丢包率 > 15% 且持续 2 秒：降帧率到 15fps，关闭高码率层（SVC 场景）。
- RTT > 400ms：增大 NACK 等待时间，别死等重传，直接请求关键帧。
- 带宽估计 < 500 Kbps：强制切换到音频优先模式，视频只传缩略图。
注意：别一看到丢包就降级。偶尔的突发丢包可能是网络抖动，降级太频繁反而让用户体验更差。我一般会加一个「持续 N 秒」的阈值，避免乒乓效应。
常见问题与解决方案总结
这部分是我这些年攒下来的血泪史。你遇到的大部分问题，应该都能在这里找到答案。
问题 1：视频花屏/马赛克
原因：丢包严重，且 FEC 没开或冗余度不够。
解决：开启 ULPFEC，冗余度设为丢包率的 1.2 倍。如果带宽够，直接上 FlexFEC。
问题 2：音频卡顿、断断续续
原因：音频包被视频包挤占了带宽，或者 JitterBuffer 设置太小。
解决：设置音频优先级最高，在 RTCRtpEncodingParameters 里把 priority 设为 'high'。同时增大音频 JitterBuffer 到 100ms 以上。
问题 3：带宽估计不准，忽高忽低
原因：TWCC 反馈周期太长，或者网络本身波动大。
解决：缩短反馈间隔，在 SDP 里设置 a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01。另外，可以自己实现一个带宽平滑滤波器，别直接用原始值。
问题 4：切换网络（WiFi 切 4G）时断连
原因：ICE 连接没有及时重建，或者候选地址失效。
解决：监听 oniceconnectionstatechange，状态变为 'disconnected' 时主动触发 ICE Restart。代码示例：
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === 'disconnected') {
pc.restartIce();
console.log('ICE 重启，尝试快速恢复连接');
}
};我曾经踩过的坑：ICE Restart 不是万能的。如果网络切换后 IP 变了，但 STUN 服务器没配好，重启也没用。所以一定要配多个 STUN 服务器，最好再加 TURN。
问题 5：CPU 占用过高，导致编码延迟
原因：分辨率太高，或者编码器用了软件编码。
解决：在弱网时主动降分辨率，同时检测 CPU 使用率。如果 CPU > 80%，强制切换到硬件编码（如果支持的话）。
写在最后
好了，这一章的内容就这些。从架构设计到调优流程，再到常见问题的解法，我希望你能感受到：QoS 不是一锤子买卖，而是一个持续观察、持续调整的过程。
你想想看，WebRTC 本身已经帮我们做了很多事，但真正决定用户体验的，往往是这些「额外」的策略。我见过太多应用，默认配置上线，然后被用户骂卡顿、花屏。其实只要花半天时间，把上面这些策略加进去，体验就能提升一大截。
嗯，就到这里。希望你在自己的项目里，也能把这些策略用起来，做出真正能打的实时通信应用。