本文由百度智能云-视频云技术架构师——柯于刚 在百度开发者沙龙线上分享的演讲内容整理而成。内容从抗弱网技术意义出发，梳理抗弱网的概念与方法，结合百度RTC抗弱网过程中遇到的问题，重点分享抗弱网技术优化的探索与实践。希望本次分享能够让开发者对抗弱网技术有一个全面的认识，并掌握一定的webRTC优化方法。

• RTC抗弱网技术的意义
• RTC抗弱网技术解析
• 百度RTC抗弱网实践与探索

• 用户端接入， 包括信令和媒体。
• 服务间流的中转和控制，包括媒体分发、调度。

• 在带宽估计阶段，采用基于丢包、基于时延、基于 ACK 带宽的评估方法；
• 在带宽分配阶段，动态地分配视频、音频的编码码率， FEC 前向纠错、重传纠错的带宽。
• 在带宽使用阶段，采用 Nack、Sack、FEC 实现数据纠错，采用 Pacing实现发送优先级，平滑数据发送；
• 在缓存解码渲染阶段，WebRTC 中提供了面向视频的 JitterBuff 和面向音频的 NetEQ，适应网络的抖动、修补数据的残缺、将网络数据包转换成音频帧或视频帧。

• 丢包估计：统计流丢包率的大小，在上次评估的带宽基础上，判断是增加带宽还是降低带宽，或者维持不变。
• 延时估计：采用 Aimd 实现和式的增加带宽，乘式的降低带宽。具体实现方式：持续计算发送端和接收端连续两个包组之间的差值之差，作为输入值拟合线性回归线计算得到斜率，根据斜率判定网络是拥塞、轻载、稳定，基于ACK带宽估计的值做Aimd调节。
• 确认带宽估计：基于FeedBack接收反馈，采用贝叶斯评估接收方到码率，该值作为延时估计的带宽基值。
  最后，对丢包估计得出的带宽值和由 Aimd 处理后的时延估计结果取最小值，作为最终的带宽评估结果。

1. 采用「丢包+延时」网络拥塞检测方法，实现了边界性的保护。

2. 面向视频应用，考虑未充分使用的带宽、已确认的带宽，并检测估计出的带宽是否有效。

1. 所有估计强烈依赖反馈，接收端会影响发送端。

2. 发送方的丢包、延时拥塞估计都基于统计实现，反映灵敏度低。

3. 未覆盖高乱序抖动等场景。

• 视频原始码率

• 前向纠错的 FEC带宽

• 视频重传所需要带宽

  
  

• 在接收 103 号包时，基于包序规则发现丢掉了前两个包，因此重新对发送方申请发送 101 和 102 号包。

• 如果重新请求后经过了 RTT+退避期的时间仍然没有收到这两个包，则会超时请求重传。

• 一套动态缓存机制，处理丢包、超时、乱序、延迟、帧残缺等异常情况。
• 一套将 RTP 包解码成帧的控制机制，确定还原帧的时机、参考关系。
• 计算网络抖动延时，通过卡尔曼滤波，预测包到达的时间，实现出帧的平滑稳定。

• 带宽估计阶段，首先判断丢包的类型，确定对带宽的调整方案，提升抗乱序抖动、提升对网络变化感知的灵敏度。
• 带宽分配阶段，我们以音视频清晰和流畅为目标导向，对丢包率、延时、抖动的统计，预测恢复效果，动态调整 ARQ、FEC，以及编码带宽配比。
• 带宽使用阶段，精细地优化重传，优化接收方发起重传的时机和发送方发送数据包的时机，避免重传风暴，保证重传的有效性。在重传 Nack 请求丢失时，及早发现并尽可能快速恢复。此外，还重点优化音频的连续丢包问题，在编解码环节采用多码流的Simulcast和SVC技术。

• 缓存\解码\渲染阶段，我们优化视频、音频 JitterBuff，更好适应抖动、乱序等场景，值得注意的是，目前的 WebRTC协议是端到端的，然而商业系统往往经过 SFU服务器中转，使用场景就发送了变化，原有机制就不适应了，需要JitterBuff做调整。

  
  

• 分发与调度环节中，我们试图得到服务器之间的最优分发路径，不断检测部署的云节点、公网的边缘节点之间的连通性，挑选出较优的连接，形成虚拟的低延时中转网络。优先使用事先挑选出的虚拟中转网络的低延迟链路。
• 为了降低服务器网络波动对实时通信结果的影响，在实际分发时会建立多条冗余备路，随时自动切换，并采用重传、FEC纠错等手段规避分发不稳定性。