得有大半年没怎么碰WebRTC了，最近被一个互动直播项目拉去救火，现象很典型：连麦一开，画面还算正常，十几秒后就像被按了慢放，声音开始一顿一顿，晚高峰的时候尤其严重。我拉出webrtc-internals一看，估计带宽一路从1.5Mbps掉到200kbps左右，FEC冗余却吃掉了超过三成的码字，视频只剩个模糊的轮廓。那几天我一边调参，一边把过去压箱底的WebRTC Qos优化思路翻了出来，突然觉得该把这些零散的经验写成一篇杂记，方便自己以后再翻，也希望能帮到同样在跟WebRTC Qos死磕的人。

这篇文章不是WebRTC百宝书，不会从ICE协商或者SDP交换开始讲。我只会讲Qos优化这条线——带宽估计、抗丢包策略、码率自适应、抖动缓冲，以及我在实测链路容量估计时踩过的几个坑。适合的读者是那种已经在用WebRTC做实时音视频，但发现流畅度和清晰度总是不理想，想系统搞清楚到底哪里出了问题、从哪儿下手优化的人。

1. 收到“画面糊、声音顿”的反馈后，我先查了这三项

1.1 排查入口不是代码，是RTP和RTCP这对搭档

很多同学一上来就怀疑WebRTC的拥塞控制算法有Bug，或者是SFU转发策略不对。但我个人的习惯是： 任何排查都不先看代码，先看统计 。浏览器打开 chrome://webrtc-internals 是第一步，导出 getStats() 的JSON是第二步。里面有几个字段我每次必看：

• outbound-rtp 里的 framesEncoded 、 targetBitrate 、 qualityLimitReason
• inbound-rtp 里的 jitter 、 packetsLost 、 framesDecoded
• remote-inbound-rtp 里的 roundTripTime

这些字段组合起来，基本能定位问题是出在发送侧、网络侧还是接收侧。而理解这些字段背后的意义，就得先弄清楚RTP和RTCP这对搭档是怎么工作的。

RTP只管搬运媒体数据，本身不含网络质量信息。真正让Qos算法“睁眼”的是RTCP——它周期性上报接收端的丢包率、抖动、往返时间等统计。Receiver Report（RR）里的 fraction lost 和 interarrival jitter ，是最直接的网络质量晴雨表。带宽估计、丢包恢复策略、码率调整，全部建立在RTCP反馈的基础上。所以排查时如果RTCP反馈异常或延迟过大，后面所有Qos机制都会跟着失真。

1.2 延迟、抖动、丢包，三个指标怎么影响用户感知

这三个指标不是独立存在的，它们互相纠缠，优化时经常要拆东墙补西墙。

• 延迟 是交互性的头号杀手。RTT超过300ms，两个人连麦就会明显感觉到“抢话”和“对不上拍”。端到端延迟包括采集、编码、网络传输、抖动缓冲、解码渲染五个环节，其中网络传输往往占比最大，但抖动缓冲的贡献也经常被忽略。
• 抖动 是网络延迟的“不稳定程度”。同一路RTP包，有的延迟10ms到，有的延迟200ms到，接收端必须用缓冲去吸收这种波动，缓冲越深越流畅，但代价是延迟越高。
• 丢包 是最直观的质量劣化因素。视频丢包表现为花屏、卡顿，音频丢包表现为字吞音、断断续续。应对丢包有重传、冗余、插值等不同手段，但每种手段都要付出带宽或延迟的代价。

我调优时脑子里始终绷着一根弦： Qos的本质是用确定性的代价去对抗不确定性的网络 。你可以增加冗余来抗丢包，但要吃掉带宽；你可以加大缓冲来抗抖动，但要增加延迟；你也可以降低码率来适应带宽不足，但要牺牲清晰度。没有免费的午餐，每个策略都是在三个指标之间找平衡。

2. 带宽估计：码率决策的源头，也是GCC与TWCC的战场

2.1 GCC的双控制器机制：延迟梯度和丢包率谁说了算

带宽估计是WebRTC Qos的总指挥，因为编码器码率、FEC冗余量、重传预算都要看它的脸色。早期WebRTC用的是GCC（Google Congestion Control），它内部其实是两个控制器在同时工作。

一个是基于延迟的控制器。接收端记录每个包的到达时间，计算相邻两个包的时间差与发送时间差的差值，这个差值叫延迟梯度（inter-arrival time），或者叫排队延迟变化。如果延迟梯度为正，说明包在链路上排队了，网络开始拥堵；持续为正就判定为过载，按倍数调低估计带宽。延迟梯度的判断在代码里不是简单的“最近几次平均值”，而是走了一个类似卡尔曼滤波的估计器，目的是在随机噪声中提取出排队延迟趋势。

另一个是基于丢包的控制器。当丢包率超过一定阈值时，直接按比例缩小带宽。这块的逻辑通常写在丢包反馈处理里：丢包率在2%以下基本不管，2%到10%之间开始线性下降，超过10%就狠砍一刀。两个控制器之间取最小值作为最终估计带宽。

实际使用中，GCC这套机制有个很经典的误判场景：网络抖动大而丢包率不高时，延迟控制器可能把随机抖动误判成排队延迟，导致带宽被“吓得”不断下调，画面越来越糊但网络其实还可以。这是我在弱网模拟中反复见过的情况。

2.2 TWCC把反馈粒度从“秒级”提到“包级”

后来WebRTC引入了TWCC（Transport-wide Congestion Control），思路完全变了。发送端给每个传输层的数据包打上一个 transport sequence number ，接收端记录每个包的到达时间，定期通过TransportFeedback反馈消息把整段包的到达时间戳批量发回去。这样发送端就能精确知道每个包在网络里跑了多久，排队延迟趋势的判别比原来RTT级别的反馈细腻得多。

TWCC和GCC的延迟控制器在目标上一致，但TWCC依赖的是传输层逐包反馈，天然绕开了GCC早期版本里“接收端通过REMB上报估计带宽”的额外治理流程，反馈链路更短，反应更快。在代码层面，这条链路会经过 TransportFeedbackAdapter 和 GoogCcNetworkController ，整条路径上可以看到每一组包的到达时间序列和延迟趋势计算结果。

我的实际体会是， 使用TWCC后，带宽估计对突发抖动的响应速度比老GCC快很多 ，但它也更敏感，如果不加滤波，任何一个反馈包的延迟异常尖峰都可能引发码率抖动。所以新版拥塞控制里加了很多平滑和趋势判断，没必要看到一次异常就惊慌。

2.3 带宽探测：初始码率和Probe策略别乱来

带宽估计不是凭空起步的。PeerConnection建立时，编码器会有一个初始码率，这通常来自RTCConfiguration里的可选参数，或者由应用侧显式设置。这个值如果设得太高，会在一开始就把链路打爆；设得太低，又要靠后面的带宽探测一点点涨回去，可能在弱网下根本涨不回来。我一般建议初始码率设置为期望码率的60%左右，留出探测上探的空间。

带宽探测（Probe）的原理是，通过 padding 包或临时提高码率，试探链路是否还有富余容量。经典的策略是当前带宽乘以某个系数（比如乘以1.25）发一小批包，如果延迟趋势没有明显上升，就允许估计带宽上调。这个机制在带宽闲置时非常有用，但在链路已经接近饱和时，盲目探测会制造新的排队，甚至诱发拥塞。

经验是： 不要让探测过于频繁，也不要让探测包太长 。我在线上遇到过一次带宽估计长期偏低，排查发现是应用层在发送侧额外加了一段自定义音视频逻辑，导致pacer队列经常处于非空状态，扇区探测总被误判为过载。后来把自定义逻辑拿到pacer之外，带宽估计才恢复正常。

3. NACK、FEC、PLC：抗丢包三件套到底怎么排兵布阵

3.1 不同丢包场景下三件套的优先级

抗丢包不是无脑全开。NACK是重传，FEC是冗余编码，PLC是丢包隐藏，三者的代价和适用场景完全不同。

• NACK 适合低丢包、低RTT场景。丢包率在2%以下时，个别包丢了重传一次就能补上，代价小、效果好。
• FEC 适合中高丢包场景，尤其当RTT很大、重传等不起时，FEC能通过冗余包让接收端直接恢复，不用等一次往返。WebRTC里常见的ULPFEC使用异或运算保护一组包，FlexFEC则更灵活。
• PLC 只作用于音频。接收端发现包丢了，不是干等重传，而是用上一帧的参数合成一段过渡音频，让人耳几乎听不出来。音频侧的NetEQ把PLC做得相当好，但PLC对连续丢包无能为力，只能救急。

我在实际项目里一般遵循一个粗略的策略表：

丢包率	推荐策略	注意事项
< 2%	只开NACK	重传预算控制在总码率的5%以内
2% - 10%	NACK + FEC	FEC冗余度跟随丢包率走，控制在30%以内
> 10%	先降码率/降帧率	同时考虑SVC或Simulcast切换，不要死扛

3.2 FEC冗余度不能拍脑袋，要跟着丢包率走

FEC的冗余度设置是很多人栽跟头的地方。冗余度太低，防不住丢包；冗余度太高，有效码率被吃掉，画面清晰度反而崩了。

我见过一个项目把FEC冗余率写死成50%，结果丢包率只有3%时，视频清晰度已经因为带宽被挤占而肉眼可见地下降。后来我们把FEC配置改成动态计算，核心逻辑是： FEC冗余率跟随丢包率，但留出一个安全边际 。比如丢包率5%时，冗余率设置在8%到10%左右，这样既覆盖了随机突发丢包，又不至于过度占用码率。同时给FEC总开销设一个硬上限，比如不超过总目标码率的20%到30%，超过这个值就触发降级策略，宁可让画质降低，也要保住基本流畅。

还有一个容易被忽略的细节：FEC保护的是媒体包，重传包本身不再受FEC保护。当NACK和FEC同时开启时，如果重传请求的包正好也在FEC组里，接收端可能已经能用FEC恢复，重传请求就白发了。这块依赖于接收端的恢复机制做判断，但发送端也可以通过限制NACK请求频率来减少冗余重传。

3.3 重传风暴：NACK请求要设上限

NACK风暴是我在线下联调时被坑过最惨的一次。场景是突发丢包，一个关键帧的多个分片同时丢失，接收端一次性发出大量NACK请求，发送端收到后立刻重传，结果重传包和新的媒体包在瓶颈链路里挤在一起，进一步加剧拥塞，丢包率反而更高，形成一个恶性循环。

后来我们做了两件事：一是在接收端限制NACK请求的速率和数量，只对真正影响解码的包发出重传请求，过期窗口里的包直接放弃；二是把重传包的调度交给pacer统一排队，不要让重传包插队挤占正常媒体包的发送节奏。这两步做完，重传风暴基本没再出现过。

另外，接收端的 jitter buffer 窗口要跟NACK策略联动。如果一个包已经超过了播放时间点，重传回来也没有意义，这时候应该发关键帧请求而不是NACK。判断逻辑很简单：包的有效期 = 播放时间 - 当前时间 - RTT估计值，如果小于0，就不要重传了，直接请求关键帧更划算。

4. 码率自适应：让画质在劣化时“背锅背得优雅”

4.1 编码器感知网络，degradationPreference决定降质方向

带宽估计拿到了目标码率，怎么让编码器听话，是码率自适应要解决的问题。编码器内部有分辨率、帧率、量化参数三个可以调节的维度，同样是从1Mbps降到300kbps，你可以选择降低分辨率保住流畅度，也可以选择降低清晰度保住分辨率。

WebRTC给应用留了 RTCRtpSender 的 degradationPreference 字段，用来声明你的偏好： maintain-framerate 优先保帧率， maintain-resolution 优先保分辨率， balanced 在两者之间平衡。这个选择没有标准答案，完全看业务场景。我在互动连麦里更倾向保帧率，因为语音对话需要动作连贯性，画面模糊一点用户能忍，但一顿一顿会明显感到“卡”；在共享屏幕的场景里则更倾向保分辨率，因为文字和图形细节比帧率重要。

排查时经常看到 qualityLimitReason: bandwidth ，它的含义是编码器因为带宽限制主动降低了质量，这是正常的Qos行为，不是Bug。真正要小心的是 qualityLimitReason: cpu ，说明编码器是因为CPU处理不过来才降质，这时候加带宽没用，要查编码参数、帧率或者设备性能。

4.2 Simulcast和SVC：SFU场景下降级谁说了算

单对单通话时，发送端根据反馈自己调整码率就行。但在SFU架构下，一个主播推流给大量不同网络条件的观众，发送端没法兼顾所有人，这时候就需要Simulcast或SVC。

Simulcast的做法是编码多路不同分辨率的RTP流（比如1080P、720P、360P三路），由SFU根据每个观看者的带宽选择转发哪一路。优点是实现简单、兼容性好，缺点是编码多路流意味着CPU和多倍码率的开销，编码器负担重。

SVC（可伸缩视频编码）则只编码一路流，但这一流里包含多个时域层、空域层、质量层。SFU可以根据观众的带宽情况丢弃增强层，只转发基层。VP8、VP9、AV1都有一定程度的SVC支持，H.264的SVC在WebRTC场景里用得很少，因为浏览器和硬编支持都比较尴尬。

选型上，如果客户端CPU普遍紧张，Simulcast的负担会很重；如果编码器支持SVC且终端兼容性可控，SVC的灵活性明显更高。不过在SFU里做SVC裁剪需要SFU本身支持按层转发，很多自研SFU没有实现这个能力，最后的降级只能靠发送端“一刀切”降低码率，这在多人混流场景里体验会比较差。

4.3 GOP太长，翻车太急：关键帧策略也要配合

关键帧（I帧）是所有Qos机制里最容易被忽略又最容易埋雷的点。I帧体积通常是P帧的十倍甚至几十倍，如果网络刚好处于拥塞状态，一个巨大的I帧会把即时码率顶上去，瞬间加剧拥塞。

很多团队为了压缩码率会把GOP（两个关键帧之间的帧数）设置得很大，比如10秒一个关键帧。这种做法在稳定网络下没问题，但在丢包环境下，一旦某个关键帧的分片丢了，接收端要等下一个关键帧到来才能恢复画面，而这个过程可能要等好几秒。此时如果接收端频繁请求关键帧，又会让发送端频繁输出大I帧，形成另一种“关键帧风暴”。

我的建议是：在弱网环境下适当缩短关键帧间隔，比如缩到2到4秒，虽然平均码率略增，但能显著减少花屏恢复时间。同时，关键帧的调度也要交给pacer控制，不要让I帧一次性把发送队列打穿。另外，SVC时域层的设计本身就能缓解这个问题，基层和增强层的关键帧分开传输，丢帧时接收端还能保持一个低帧率的画面完整性。

5. 抖动缓冲：容易被忽略的流畅体验“最后一道闸门”

5.1 NetEQ：音频侧的隐形MVP

WebRTC音频侧最容易被低估的组件就是NetEQ。它不是一个简单的jitter buffer，而是把自适应抖动缓冲、PLC、舒适噪声、音频解码前处理整合到一起的模块。很多刚接触WebRTC的人以为音频卡顿都是网络问题，但实际抓包发现丢包率和抖动都不高，声音依然一顿一顿，问题往往出在对NetEQ参数的调节或配合策略上。

NetEQ的动态缓冲区会根据抖动统计自动调整深度，目标是尽量小延迟下保证低卡顿率。它内部有一套对丢包和延时的权衡逻辑，会在“多等一会儿以减少丢包导致的卡顿”和“早点播放以降低延迟”之间做动态决策。这段时间我很少去硬改NetEQ内部参数，更推荐从上层保证音频包到达的节奏相对稳定。如果发送端把音频包的发送间隔控制得忽快忽慢，NetEQ再聪明也会频繁调整缓冲深度，最终反映为延迟的波动。

5.2 视频jitter buffer怎么平衡延迟与卡顿

视频侧的抖动缓冲没有NetEQ那么成熟，它面对的是帧大小差异极大的问题。一个I帧可能是几个P帧体积的几十倍，到达时间天然不均匀，不能只看包的实时到达间隔。WebRTC的视频jitter buffer会根据帧大小动态估算解码所需时间，并参考到达时机决定让当前帧等待多久再送去解码。

调优时要注意，视频抖动缓冲的深度和音频是独立的，两边对时延的容忍完全不同。如果音频缓冲较浅，视频缓冲较深，用户可能会觉得“嘴型和声音对不上”，这是一个经常在Qos优化中被忽视的体验问题。在做音画同步时，不能只看音视频各自的流畅度，还要看它们的缓冲延迟是否匹配。

5.3 关于缓冲参数的一些经验记录

我在项目里做过一段时间的缓冲参数观察，几个结论分享一下：

• 音频NetEQ的缓冲深度一般会根据网络抖动自动调整，不需要手动干扰，但如果你在播放端做了额外的音频后处理，要小心处理耗时影响NetEQ的播放节奏。
• 视频抖动缓冲和重传策略需要协同：如果NACK重传很积极，视频缓冲就必须预留足够的等待窗口，否则重传包还没到，帧已经被送去解码，重传就白费了。窗口设得太大又会增加延迟，这需要根据RTT和业务容忍度来权衡。
• 不要让应用层再做一次“万能缓存”。很多播放器喜欢在SourceBuffer后面再加一层全局缓冲，用来吸收底层抖动，这在点播场景没问题，但在实时的WebRTC场景里，这会直接抵消掉NetEQ和视频jitter buffer好不容易压下来的延迟。

6. 链路容量估计：用实验数据给Qos策略“称重”

6.1 通过webrtc-internals跟踪带宽估计变化

“链路容量估计”听起来高大上，实际上我日常做的最多的就是用 chrome://webrtc-internals 去实时盯带宽估计的变化曲线，观察带宽估计值和实际发送码率之间的差值。

重点看三个趋势：一是看带宽估计是否稳定，如果一直上下跳动，说明拥塞控制对链路质量的判断不够稳定，需要回到网络侧排查抖动或丢包；二是看实际码率和带宽估计的贴近程度，如果两者长期偏离很远，可能是pacer或编码器没有及时跟上估计值的更新；三是看丢包率与带宽曲线的关系，如果丢包率没起来但带宽还是狂降，大概率是延迟控制器误判过载，这个问题在公网上时常见到。

有一次线上故障，用户反馈频道画面全糊，我查internals发现丢包率只有0.5%，但估计带宽已经掉到了100kbps。再细看发现这路连接跨运营商，RTT中的RTT抖动非常剧烈，延迟控制器把连续的高延迟样本当成了排队拥塞信号，触发了过载惩罚。最终我们把该场景下的过载阈值参数做了一下调整，问题就缓解了。

6.2 用tc/netem做一次可控弱网实验

想验证Qos策略靠不靠谱，不能只在真机上碰运气，我习惯先做可控实验。Linux下用 tc + netem 模拟可控的丢包、延迟和带宽上限，非常方便。

一条典型的模拟命令是这样：

# 模拟丢包5% + 延迟100ms
tc qdisc add dev eth0 root netem loss 5% delay 100ms

# 限制带宽上限1Mbit，模拟链路容量
tc qdisc add dev eth0 root tbf rate 1Mbit burst 32kbit latency 400ms

实验设计的思路是：先固定一组网络参数，比如丢包3%、延迟80ms、带宽1Mbps，然后让WebRTC跑起来，观察带宽估计是否收敛到1Mbps附近，FEC和NACK的重传码率是否在可控范围内，画面有没有出现长时间花屏。换几组参数后，基本就能摸清这套Qos策略的“脾气”。

实验时最好同时抓包。Wireshark里过滤RTCP中的TransportFeedback消息，可以直接看到接收端每一批包的到达时间记录，这是分析发送端带宽估计行为最直接的证据。只盯着webrtc-internals看，永远只看到结果，看不到反馈的原始细节。

6.3 几个容易翻车的地方，尤其是WebRTC泄露这类问题

链路容量估计实验里有几个坑，都是我自己踩过的。

第一个是 多网卡和WebRTC IP泄露 。现代设备普遍同时有有线和无线网络，WebRTC的ICE在收集候选地址时，会把本机所有网卡的IP都作为host candidate上报。如果应用没有启用mDNS加密，这些内网IP甚至公网IP就可能被对端或者旁路网络设备看到，这就是常说的WebRTC泄露问题。从Qos角度讲，多网卡还会导致某一路网卡质量极差被误判为全网链路差。我现在的做法是：在应用层根据网络类型和信号强度选好默认网卡，再通过ICE候选策略尽量只使用符合条件的候选类型，而不是放任所有候选都参与。

第二个是 测试环境的系统时钟不同步 。TWCC和延迟梯度的计算都依赖时间戳，如果发送端和接收端的时钟漂移过大，排队延迟趋势会被严重扭曲，带宽估计就会失真。做链路容量估计实验前，最好先检查两台机器的NTP同步状态，别让半小时的时钟偏差把整个实验结果毁掉。

第三个是 后台流量干扰 。如果测试机器上有其他应用在大量占用网络，比如系统自动更新、网盘同步，链路容量估计的结果会完全不准。做实验时最好关掉无关网络应用，并且在webrtc-internals里对比 Available Send Bandwidth 和系统级网卡实时速率，确认没有外部干扰。

最后分享一个让我印象最深的小发现。很多时候用户说卡，但抓包看到丢包率只有0.5%、RTT也只有30ms，问题其实出在发送端的Pacer和编码器配合上——码率估算没问题，但一个大I帧突然把所有发送队列塞满，瞬时把链路堵死。Qos优化不总是一个算法层面的问题，往往两个模块之间的配合才是大头。每次动手调优之前，先把webrtc-internals的图表截图保存一份，再结合抓包数据一起判断。调优结束后隔一天在同条件下复测一遍，数据对比比什么总结都靠谱。