WebRTC的NACKNegative Acknowledgment技术这几年做实时音视频的团队基本都绕不开。尤其像ZeroRange这类偏底层的WebRTC传输优化方案NACK机制直接决定了弱网下的画面卡顿率、延迟和带宽利用率。我接触过不少把WebRTC跑在产品线上的项目发现很多团队在集成阶段只关注编解码和信令等到线上反馈“画面总在关键时刻马赛克”时才回过头来补NACK的课。这篇文章就把我在ZeroRange实践中对NACK的理解、调参过程和踩坑记录整理出来给正在做WebRTC传输优化的人一个可以抄作业的参考。先说清楚NACK能解决什么问题。实时音视频走的是UDPUDP本身不保证包一定送达一旦网络拥塞、Wi-Fi抖动或者基站切换RTP包就会丢。NACK做的事就是让接收端发现问题后主动告诉对端“这个包我没了请重发”。听上去很简单但真要把它做稳、做成不影响拥塞控制、不触发重传风暴里面的门道远多于第一次接触时的想象。适合阅读这篇文章的人我默认是已经跑通WebRTC Demo、但还没有深入调过传输层的开发者。如果你只是调用WebRTC接口做业务不涉及底层参数和传输策略那这篇会有些偏底层但理解了也能帮你定位很多“明明网络好却卡顿”的问题。如果你正打算基于WebRTC做低延迟直播、远程控制、或者是类似ZeroRange这样需要极致实时性的传输方案那NACK就是你绕不开的核心功课。1. 为什么实时音视频离不开丢包反馈1.1 UDP传输的现实选择没有保障的通道WebRTC之所以选UDP而不是TCP核心原因就一条TCP的可靠传输是用延迟换来的。TCP一旦丢包就要等重传而重传的包可能会把后续所有数据全堵住这就是队头阻塞Head-of-Line Blocking。视频帧之间本身就有依赖关系一帧I帧卡住后面所有P帧再完整也没有意义。对于实时通信来说延迟超过400ms就会明显感觉“对话不同步”TCP在这种场景下天然不合适。所以WebRTC选择了UDP作为传输底座把“可靠性”这件事的决策权交给业务层。数据包丢失后是否重传、重传几次、重传多快都由RTP/RTCP协议栈来控制。这也意味着如果你只是把UDP看成“不可靠的裸管道”而不去处理丢包那WebRTC的体验就会大打折扣。尤其当丢包率超过1%的时候没有抗丢包机制的视频通话会出现肉眼可见的卡顿与花屏这已经是行业共识的经验值了。1.2 抗丢包的防守梯队NACK的位置WebRTC内置了多道抗丢包防线我习惯把它们看成一个配合使用的梯队第一梯队是FECForward Error Correction也就是前向纠错。发送端在原始RTP包之外额外计算出一部分冗余包接收端即使丢了少数原始包也能通过冗余包还原不需要向对端要数据。FEC的优点是恢复延迟极低因为不涉及“请求-响应”的往返缺点是它不管网络是否真的丢包都会白白占用带宽。在丢包率不高或带宽紧张的时候固定的FEC冗余很浪费。第二梯队就是NACK也就是被动反馈与重传。接收端发现序号不连续后通过RTCP反馈给发送端发送端从重传缓存里取出对应数据重新发一次。相较于FEC省带宽但需要一个RTT左右的往返时间才能恢复丢包。第三梯队是PLCPacket Loss Concealment丢包隐藏和编解码器层面的容错。比如Opus内置PLC能在丢包时用前面帧的信息猜测当前帧稍微掩盖一下损失视频的H.264/VP8也支持帧内编码块刷新等手段减少丢包引起的花屏扩散。这三层要配合着用。ZeroRange里的经验是NACK作为兜底机制承担绝大部分丢包恢复FEC针对大帧做选择性保护PLC则负责那些来不及恢复的极端情况。没有NACK语音和视频在弱网下的可用性会断崖式下降所以它是整个防守体系的地基。2. NACK的工作原理从丢包到重传的完整闭环2.1 接收端怎么知道包丢了NACK的起点是接收端对丢包行为的“感知”。RTP包头里有一个16位的sequence number序号发送端每发一个包就加一。接收端收到包后会按序号排序正常情况下序号是连续的一旦发现跳跃比如收到了100号、101号、103号那就可以断定102号大概率丢了。但这里有个经典问题网络可能会乱序。也就是说103号先到101号反而后到。如果一发现不连续就立刻发NACK对方把101重传一遍结果原包又到了网络白浪费一轮带宽。所以成熟的实现里接收端会维护一个“乱序容忍窗口”只有在序号缺口持续存在且超过预设阈值比如等10ms或等若干个包之后才会真正生成NACK请求。在libwebrtc的实现中NackTracker模块维护了每个SCRSS的丢包记录丢包条目会保存在一个历史表里不会因为收到一个晚到的包就立即删除所有记录而是会继续保存一段时间防止重复请求。这里面涉及的“记性力”设计非常有意思既要避免漏判又要避免重复请求我后面在ZeroRange中调这块时深有体会。2.2 RTCP NACK报文格式PID与BLP的精妙设计接收端确认丢包后要通过RTCPRTP Control Protocol把信息发给发送端。WebRTC常用的RTCP反馈报文中NACK的具体格式是RTPFBTransport Layer Feedback Message类型是PID加BLP的组合。PIDPacket ID指的是接收端检测到的第一个丢失包的序号。BLPBitmask of Lost Packets是一个16位的位掩码每一位对应PID之后的一个序号。比如PID100BLP第0位对应101号第1位对应102号以此类推最多覆盖PID之后的16个包。这种设计的好处是报文很紧凑一次反馈最多可以表达17个连续的丢包信息。对于丢包比较频繁的弱网场景这个效率很高。我实测过一个突发丢包率5%的Wi-Fi环境一个NACK报文就能Cover住近20个丢失序号不会产生太大的RTCP带宽开销。不过要注意NACK本身也在UDP上传输它也可能丢。所以WebRTC的反馈机制不是只发一次就完事而是会周期性重发NACK请求直到收到重传的包或者超时放弃。这个重发间隔以及“放弃”的阈值直接决定恢复延迟和带宽占用是调优NACK时的关键参数之一。2.3 发送端重传缓存与RTX通道发送端收到NACK之后不是直接从内存里翻数据裸发一次那么简单它需要一套数据管理策略。发送端会有一个重传缓存retransmission buffer用来保存一段时间内已发送的RTP包。这个缓存不按RTP序号直接索引而是用了一个基于链表的哈希结构使得根据序号查找包的速度很快不会成为高码率下的瓶颈。重传数据有两种常见携带方式一种是用不同的SSRC和payload type重新封装走RTX通道另一种是复用原来的SSRC在原RTP包基础上带一个重传标记。WebRTC标准实现里RTX通道是更常用的选择。接收端一看payload type和SSRC就知道这是一个重传包从而和实时新到的包区分开避免把重传包当成新包交给jitter buffer造成帧乱序。RTX通道的另一个好处是方便接收端做去重。当重传包和新包重复时接收端可以很快识别并丢弃不影响后面解码流程。如果复用了原SSRC去重逻辑就需要做得更谨慎否则解码器可能会因为重复帧时间戳的问题报错。ZeroRange在早期为了省一点带宽尝试过复用SSRC的方式后来发现去重逻辑变得复杂最后还是切回标准RTX方案稳定省心省事。3. ZeroRange项目里的NACK工程实践3.1 重传缓存容量怎么定一个可量化的计算重传缓存的大小直接决定了NACK能恢复多久以前的丢包。缓存太小发出去的包很快被清掉收到NACK时包已经没了重传失败缓存太大长时间占用内存而且旧包也会增加查找和管理的开销。工程上一般用带宽和RTT的乘积来估算。假设视频码率是3Mbps网络RTT是100ms那么在一个RTT内发送的数据量约等于 3 * 10^6 bit/s * 0.1s 300Kbit换算成字节约37.5KB。如果每个RTP包平均1200字节大约需要缓存31个包。再考虑到NACK可能需要多轮反馈实际缓存长度至少按2到3个RTT的数据量来做也就是约75KB到112.5KB。ZeroRange在默认配置里按RTT_3倍的内存来兜底这样即使RTT瞬间从40ms涨到了100ms也还有余量。但这只是单纯的数据量估算还没考虑大帧的情况。视频编码中关键帧I帧往往比普通帧大很多一个I帧可能打散成几十个RTP包。如果走的是低延迟配置I帧在码率控制中会受到限制但在摄像头画面剧烈变化时依然可能出现尖峰。这种大帧场景下缓存策略最好能对关键帧做“涨价”也就是临时多保留一些历史包。ZeroRange在实现时给关键帧RTP包设置了一个稍长的缓存过期时间宁可多占一点内存也不让一个关键帧的丢失导致全部画面恢复延迟。3.2 NACKFEC混合策略延迟与带宽的博弈NACK始终有至少一个RTT的恢复延迟。在一些低延迟场景比如RTT已经到150ms再等一轮重传视频几乎就卡到不可接受了。这时候我倾向于在NACK之上叠加FEC保护大帧和关键帧。ZeroRange里的策略是这样的基础码率部分几乎不做FEC完全依赖NACK恢复遇到关键帧或视频画面复杂度突增的帧客服端会动态增加冗余包。这个思路的解释很直观——普通P帧丢了通过NACK等重传延迟即使稍高对整体的连续观看影响有限但关键帧是所有后续帧的基础一旦丢得久整个画面就是马赛克影响是毁灭性的。对关键帧做FEC哪怕带宽多耗费一些性价比也远高于对全部数据做冗余。这里有个参数需要注意FEC冗余度要随着实时丢包率调节。如果丢包率只有1%固定做20%的FEC冗余就太浪费了丢包率10%的时候20%冗余可能还不够覆盖。ZeroRange是通过RTT和丢包率预测模型动态计算FEC比例的丢包率低时FEC比例降到5%甚至0丢包率升高时按每1%丢包增加约1.5%到2%的FEC冗余逐步调整。这样既能兜住突发丢包又不至于一直浪费带宽。3.3 乱序容忍与重传去重容易被忽略的细节NACK机制有一个天然敌人包乱序。网络层不同路径、Wi-Fi和4G切换都可能造成包到达顺序与发送顺序不一致。接收端如果对乱序过度敏感就会发出大量“假NACK”发送端白忙一场还浪费带宽。ZeroRange的做法是把乱序容忍时间和网络状况联动。网络RTT低的时候乱序窗口可以设得小一点比如5msRTT高的时候乱序窗口则放大到RTT的1/2。这样做的基本逻辑是RTT越大网络内部排队和调度的不确定性越高乱序返回的可能性也越大需要给它更多时间“到达”然后再判断是否丢包。重传去重同样是关键。接收端收到RTX包后必须先根据序列号去历史表中删除对应的待重传记录防止后面继续发重复的NACK请求。这个过程要特别注意锁的粒度零散的高频访问如果用粒度过大的锁很可能把接收线程卡成性能瓶颈。ZeroRange在线上版本曾用锁保护整个NackHistory表结果在并发4路流时出现了接收线程处理延迟飙升后来改成按SSRC分片加锁问题立刻缓解。这是做传输层优化时容易被忽略的坑。4. NACK排查实战常见问题与调优手法4.1 NACK风暴越重传越丢的恶性循环NACK风暴是弱网下最让人头疼的问题之一。现象是网络一波动丢包率上来接收端发现大量序号缺失发出去的NACK请求密集到连RTCP信道都被挤占发送端重传时又加剧网络拥塞导致新的丢包继续产生最后收发双方进入一个互相拖累的恶性循环。处理NACK风暴的核心是限流和退避。接收端不能无脑把所有丢包一次性反馈出去而是要根据RTCP发送间隔、丢包率预估和拥塞状态限制单次NACK消息的数量以及重发NACK的频率。libwebrtc标准实现里NackTracker会对每个丢失包设置重传请求间隔比如第一轮重发后要隔一个RTT再发第二轮请求如果连续多次请求都没有收到重传包就放弃这条丢包记录不再浪费带宽。ZeroRange在实际调优时还加了一层“背压”机制当接收端检测到丢包率持续高于某个阈值例如8%时自动降低NACK的重发频次并请求发送端降低目标码率。虽然这会让画面清晰度下降但至少能保住连接的连续可用。这个取舍在实时通信产品中非常常见——画面可以糊一点但不能彻底卡死。4.2 与拥塞控制打架重传包的带宽从哪来NACK和拥塞控制的关系处理得好不好决定了流在高丢包下的表现。发送端的拥塞控制算法比如GCCGoogle Congestion Control在计算可用带宽时如果没把重传包的流量算进去就可能出现重传包和新的媒体包都在抢带宽结果两者都在丢拥塞窗口又一直往下掉——整个系统陷入低效状态。实际上libwebrtc的做法是把重传流量纳入带宽估计的一部分。重传包在发送前也要经过PacedSender发送节流器排队不能因为它是“重传”就有特权跳过拥塞控制。ZeroRange在排查一个“高码率高丢包但带宽估算异常低”的问题时就发现当时的自定义拥塞控制对应重传流量没有乘以惩罚系数导致重传发送过快把原本就紧张的带宽直接击穿。后来把重传的数据量按1.2倍权重计入拥塞样本后整体传输反而更稳因为重传请求本身变小了。这里有个需要平衡的点NACK重传的及时性与拥塞控制的容灾能力。如果过分依赖拥塞控制来抠带宽会让重传包排队长恢复变慢如果完全无视拥塞状态快速重传又容易把网络压垮。实际项目中我会把重传包在PacedSender里的突发速率限制为码率的两倍并作为一个经验阈值。既不会让重传数据瞬间爆发拖垮链路也能保证丢失包快速恢复。4.3 观测NACK的关键指标与日志线上问题排查没有数据光靠猜那就是灾难。NACK相关的核心指标我建议至少采集以下几项NACK请求率单位时间内收到的NACK请求数与发送RTP包数的比值正常网络应该接近于0。重传成功率重传包到达接收端的比例如果低于70%说明网络问题已经严重到重传都已经无济于事了需要降码率或切FEC。平均重传延迟从接收端发出NACK到收到重传包的耗时正常应该接近一个RTT明显大于RTT则说明发送端缓存或网络路由有问题。重传缓存命中率发送端收到NACK后能从缓存中找到数据的比例该值低于95%时优先检查缓存时长是否设置过小。日志层面ZeroRange会把每个NACK请求的关键字段PID、BLP、时间戳、RTT、缓存命中情况以结构化日志输出并配合链路追踪关联到具体视频流。有一次线上发现某条链路的NACK请求率异常高但RTT和带宽都正常最后靠日志定位到是该链路经过了MTU过小的隧道导致大量UDP包在IP层被分片丢失。这种问题如果不是靠NACK统计数据逐层排查真的很难从业务层找到原因。还有一个指标容易忽略NACK导致的重传包数量占正常媒体流量的比例。如果这个比例长期超过3%就说明当前的FEC和码率控制没有匹配实际网络状况需要对编码参数做调整。ZeroRange在这个阈值上设了监控告警一旦超标就让信令侧触发客户端码率切换避免长时间在劣化网络上硬扛。5. 最后说点实在的NACK这个技术单看原理确实不复杂无非就是“丢了告诉我我补给你”。但在真实的WebRTC工程中它和拥塞控制、FEC、jitter buffer、编码器策略都强耦合任何一层改动都可能影响另外几层的表现。ZeroRange在优化NACK的过程中最深的体会是能够量化才是优化的前提。重传缓存多大、乱序窗口多宽、NACK重发多频繁这些参数都要用线上数据来验证而不是靠感觉拍脑袋。如果你手头也正在调WebRTC的NACK建议从“重传缓存命中率”和“平均重传延迟”这两个指标入手先看当前实现到底把丢包恢复做到了什么程度再根据自己的RTT和码率逐步微调缓存时长与重发节奏。另外弱网的NACK表现一定要在真实网络环境下验证模拟器里跑出来的曲线往往过于理想。最后分享一个小技巧排查NACK问题时把发送端的重传缓存dump出来按时间轴看它在丢包瞬间发生了什么变化往往比盯日志更直观。我见过好几次表面上是NACK不生效实际上是发送端缓存管理代码在关键时刻把要重传的包提前清掉了——这类bug靠任何指标面板都看不出来只能靠这种原始姿势。希望这篇总结能让你在调NACK时少走些弯路。
