【音视频】WebRTC拥塞控制学习（看了个皮毛）

书籍学习：《WebRTC音视频实时互动技术》原理、实战与源码分享
作者博客：https://avdancedu.com/

目的：了解一些底层的实现逻辑，不是单纯的知道发送端码率自适应

拥塞算法分类

GCC：谷歌拥塞算法
BBR：瓶颈带宽和往返传播时间（QUICK协议）
PCC：基于性能的拥塞控制

目前采用

自研的WebRTC服务：GCC中的TCC
目的：减少发包量，抢占更多的带宽

基于时延的拥塞评估算法（比较复杂）

1. Goog-ERMB：Google接收端评估的最大码流

• 卡尔曼滤波器
• 接收端，当码流计算好后，模块会生成RTCP消息包，最终将计算好的码流反馈给发送端。发送端接收到消息后再进行码率控制，这样发送端的延时拥塞控制算法运行起来了。

2. 模块功能

• RemoteBitrate Estimator模块：管理模块。
  • 一方面，它要与外面的模块打交道，从网络收、发模块获取RTP包的传输信息，让其通知发送端进行流控；
  • 另一方面，他还要组织内部的模块，根据当前观测到的延时差和之前的评估值推测出下一时刻的网络拥塞情况。
• Inter Arriva模块：首先将数据包按帧进行分组，然后对相邻的两组数据包进行单向梯度计算。
• OverUse Estimate模块：利用Inter Arriva模块计算结果，通过卡尔曼滤波器估算出下一时刻发送队列的增长趋势。
• OverUse Detector模块：用于检测当前网络的拥塞状态。
• AIMD Rate Controller模块：用于计算发送码流大小。

3. Transport-CC：传输带宽拥塞控制**

• TrendLine滤波器（最小二乘法滤波器，通过斜率的增大或者减小判断当前网络的拥塞情况）
• 发送端，使得评估和控制合为一体。接收端需要处理的逻辑非常少，仅需要将收到的数据包的基础信息（如：丢包数、延时时间）通过RTCP反馈给发送端即可。

4. 模块功能

• GoogCcNetworkController模块：管理模块
• SendSideBandwidthEstimation模块：作用是选出最小码流值作为最终评估的~
• DelayBaseBwe模块：发送端的延时拥塞评估模块
• Trendline模块：滤波器

基于丢包的拥塞评估算法（比较简单，区域的数学公式）

• 通过一段时间内网络延时的趋势来判断下一时刻网络是否会发生拥塞的算法。

• 在实际物理链路中，如果出现大量丢包的情况是非常严重，一直只有物理链路的路由器缓冲区被填满时才会出现大面积丢包的情况，所以此时必须减少发包量，让网络尽快恢复。

• SendSideBandwidthEstimation类的UpateEstimate（）方法中实现的。

拥塞控制流程

• 首先发送端启动会设置初始带宽
• 之后通过其发送模块将音视频数据发送给远端
• 远端接收到数据后，定期想发送端反馈RTCP报文，以报告数据的丢失、延迟情况
• 当发送端的接收模块收到RTP反馈报文后，将数据交由RTCP解析模块进行解析
• 解析后的数据再交由拥塞评估模块进行计算，评估出新的带宽
• 拥塞评估模块将新带宽，通知编码器，让编码器输出码流的大小；另一方面告知Pacer模块，控制码流发送的速度。保证最终的发送码率不会超过带宽的估算值
• 经控流后的数据最终再交由发送模块发送给远端
• 往复工作，直到通信结束