RTC拥塞控制算法GCC和BBR总结

GCC核心思想就是通过预测可用带宽来控制发送的速率，会结合发送端和接收端两端各自估测的带宽来综合计算，其中发送端的带宽估测主要依赖于丢包率(其实也有延迟)，接收端的带宽估测依赖于延迟(的变化)。GCC主要是依靠丢包、延迟、抖动等网络参数来预估当前的可用带宽进而控制发送的速率从而避免网络拥塞引起的丢包、延迟、抖动等现象。

由于WebRTC还有NACK、FEC等策略来解决丢包问题，（NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。FEC为前向冗余。）实际上发送端的带宽估测对较小程度的丢包来说并不太敏感，反而是接收端的带宽估测对延迟的抖动有较大的灵敏度。GCC的接收端通过一系列算法检测当前网络延迟是否有变化，延迟变大的话，在考虑并消除掉数据尺寸变化的影响后，可以认为是网络路由的拥塞，需要降低码率，否则在延迟变小的情况下，认为网络空闲，可以提高码率。所以在延迟抖动较大的情况下，即使没有丢包，GCC也会进行较大程度的带宽调整。

也就是说，延迟如果稳定的话，即使值较大，也并不影响带宽的估测，反过来如果平均延迟比较小，但是出现较多较大的抖动，则会迅速将估测带宽调低。

发送端调整算法总结：

1. 初始默认300k的带宽，并可以设置上下限；

2. 如果收到REMB包，立刻以REMB包中的带宽为准更新预估带宽；（REMB是指接收端预估最大码率）

3. 如果丢包率 < 2%，则以当前历史最小码率表的最小值也就是上一秒的码率为基准，增长8%；

4. 如果丢包率在(2%, 10%)范围，则保持；