tcp拥塞控制算法_WebRTC拥塞控制原理解析

前言

WebRTC包含三种拥塞控制算法，GCC、BBR和PCC。其中，BBR一开始是针对TCP的拥塞控制提出来的。它的输入为ACK/SACK，输出为拥塞窗口(congestion_window)发送速度(pacing_rate)。BBR是怎样运用到UDP，甚至运用到实时流媒体传输之上的？拜读一下在WebRTC中关于拥塞控制的模块吧！

正文

一、平缓发送

拥塞控制模块位于平缓发送这个区域。平缓发送指的是，不会将所有能发的包一股脑都发出去，而是根据拥塞控制模块计算出来的发送速率和拥塞窗口大小，将其平缓的发送出去，从而避免阻塞传输网络，导致RTT剧烈抖动。

这里对比TCP的Reno拥塞控制算法，Reno会维护一个cwnd，然后不停的发送包，直至inflight填满cwnd才停止发送，在收到ack时，释放in_flight，使其可以继续发送后续的包。

对于WebRTC的拥塞控制，它是一个定时循环，在正常情况下，每固定时刻（min_packet_limit_ms_默认值5ms，这个值可能会变化）循环一次。拥塞控制算法会计算出当前可用带宽。接下来，计算 循环周期时间 ✖️当前可用带宽，这个值便是当前周期可发送的数据量的预算值。

整体发送的数据量（throughput）理想情况下应该如图所示。每间隔5ms，会发送一些数据来填满带宽。5ms时间很短，整体来看，是平滑发送的。

从代码实现角度：每次循环，都从数据包的队列中取出一些包，直到消耗完数据量的预算（budget）或者消耗完cwnd（导致处于拥塞状态）。拥塞状态的判定是未收到确认（outstanding_bytes）的数据量大于拥塞窗口（cwnd）的值。

另外，如果数据包队列中的数据量不够了，也就是预算太多，实际并没有这么多数据要发送。这时候会发送一些PaddingData用于填补带宽。这个填补对于拥塞控制算法是十分关键的，要不然它无法正确测得到当前可用的带宽。

二、BBR拥塞控制算法在WebRTC中的实现

1、引子

上文明确了如何使用拥塞控制算法的产出结果（bandwidth和cwnd）。下文将介绍BBR算法如何准确获得这两个值。

BBR的简介可以参考这篇文章

BBR 拥塞控制算法解析（来自 Google 的 TCP 拥塞控制算法）​ccie.lol

原理介绍参考这个

https://blog.csdn.net/dog250/article/details/52830576​blog.csdn.net

本篇文章重点关注BBR的具体实现方式，尤其是在实时音视频领域、基于的RTP/RTCP的实现。

如果要使用拥塞控制，RTP会使用transport-wide-cc拓展。这里需要参考标准：

RTP Extensions for Transport-wide Congestion Control​tools.ietf.org

这个transport-wide-cc拓展，其实提供了一种UDP的ACK机制，为拥塞控制的实现提供了可能。另外值得注意的是，transport-wide-cc机制在RTCP中的反馈信息，是聚合的，也就是说，每次可能反馈（ack或lost）的是多个Packet。

2、最大带宽的计算

对于每个ack的数据包，都会计算带宽。并不是只有PROBE_BW模式时才计算。

当前的发送带宽是根据send_rate和ack_rate之中最小值而来的。send_rate和ack_rate都需要使用两个点，计算斜率（数据量之差➗时间差）而来。具体选点可以参考源码，这个不太重要。

如果这个带宽计算值比较好，则将其放入最大带宽的采样记录中。这个记录是最好的三个值（排序的前三名），他们都有一个有效窗口时间，在窗口时间到期或者新的采样值更为优秀，则会替代他们。

这个窗口时间是回合数（round_trip_count）的窗口。那什么算一回合呢？需要一个当前回合结束、下一个回合开始的标志。这个标志是在回合开始时，当前发送的最后一个包的序号。如果在之后收到了这个标志包（或者大于这个标志包序号的包）的ack。则代表该回合结束，下回合开始。

若干的回合之后，前面测量的采样值就会过期。

3、RTT的计算

同理，在收到每个ack时，都会计算这个采样点的RTT值。当这个采样的RTT小于当前测量的最小RTT时，可以延长最小RTT的过期时间（这个延长RTT过期时间的功能暂时没有启用）。否则，在一定物理时间过后，该最小RTT过期，必须进入PROBE_RTT模式。

4、拥塞窗口和BDP的计算

BDP指的是一个PIPE中所能承载的数据量的值。BBR中的BDP为最大带宽✖️最小RTT。拥塞窗口大小乘以一个增益系数，在STARTUP阶段和DRAIN阶段（这个可能是个bug，应该为1/2.885）为2.885，在PROBE_BW阶段为2.0，在PROBE_RTT阶段，拥塞窗口直接设置为4。

这个cwnd不是一下子直接设定一个新值的，而是每次增加当次ack的数据量（类似于TCP的慢启动过程）。

5、PacingRate的增益变化

在STARTUP阶段为2.885，DRAIN阶段为1/2.885。PREOBE_BW的阶段1为1.25，阶段2为0.75。其他时刻为1.0。

6、模式变化

每当收到ack，都有可能引起模式的变化。

• 当连续3个回合都没有带宽增加时，则认为已经处于满带宽状态了，将会从STARTUP模式转换为DRAIN模式。
• 当IN_FLIGHT的数据量小于BDP，则退出DRAIN模式，并进入PROBE_BW模式。
• 在PROBE_BW模式，如果当前处于阶段1（pacing_rate > 1.0）也就是探测额外带宽阶段且INFLIGHT的数据量达到了探测额外带宽的要求，则会前进到阶段2（pacing_rate < 1.0），也就是排空之前探测额外带宽所堆积在链路上的数据。接下来6个阶段是平缓发送阶段（pacing_rate = 1.0）。
• 当最小RTT过期时，会进入PROBE_RTT模式。将会限制拥塞窗口的大小为4个包。在后续时刻，我们会等到INFLIGHT的数据量小于5个包时，这个时候真正开始了最小RTT的探测，我们设定退出PROBE_RTT的时间为200ms之后。当等到这个时间后，会重新进入PROBE_BW模式。

7、Recovery模式

BBR有一个Recovery模式。每当收到反馈信息，发现存在丢包的时候，将recovery_state设置为CONSERVATION。如果下一次收到反馈信息时，还有丢包，则更新状态为GROWTH。当处于GROWTH状态时，如果下次收到反馈信息时，没有丢包。则更新状态为NOT_IN_RECOVERY。

这个Recovery模式考虑了丢包的因素，会得出recovery_window。根据BBR的配置，可能会与cwnd相比较，取二者之中的较小值作为最后的拥塞窗口值。

三、优化

对于实时流媒体来说，将窗口降为4个包来探测RTT，是一个很糟糕的事情。这里可以通过选项配置的方式改为0.75倍的BDP来探测RTT。

其次，启用延长RTT过期时间的选项，减少进入PROBE_RTT模式的次数。

剩下可以调整的一些参数为：各个模式的congestion_window_gain和pacing_gain。在PROBE_BW模式的8个阶段，可以有更多样化的变化组合。