文 / 袁荣喜

整理 / LiveVideoStack

大家好，我是来自学霸君的袁荣喜，本次分享内容的核心是BBR在实时视频传输中的实践。BBR其实是基于TCP的一种拥塞算法，在实时音视频中的运用也是一种全新的尝试，接下来我将会为大家逐一介绍这种尝试所带来的优缺点。

1. 传输与拥塞

讲到音视频的传输或者实时传输，就必须要了解传输和拥塞的关系。

1.1 传输三角关系

实时传输领域存在着一种三角关系，其中成本一般认为是硬件、软件和通讯带宽所带来的成本，延迟是指获得整个流媒体的时延，比如实时视频中的双端延迟和观看长视频时的首帧延迟，质量可以理解为视频清晰度和数据完备性，这种三角关系均是以保证其中一角而牺牲其余两角的方案来建立实时传输方案。随着互联网的发展，设备的成本越来越低，手持设备越来越方便，但由此也带来很多在实时视频传输过程中的问题。

1.2 实时视频的困扰

实时视频传输中常见的问题主要有卡顿、延迟、抖动、视频模糊和断线重连五种。造成这些问题的原因是多种多样的，但其中最不能忽视的一个原因就是网络拥塞。

1.3 网络拥塞

网络拥塞是指发送的数据超过了网络能承载的传输能力，但人的需求无限，即使新技术在不断地发展，网络拥塞的情况在未来还是会不断出现。

网络发生拥塞的原因大致有以下几点，WiFi/4G信号衰减、核心传输链路衰减、网络出口竞争、重发风暴和设备性能衰减等问题都会带来网络拥塞的问题，其中WiFi/4G信号衰减意味着信号被污染，导致传输信道的吞吐率下降，最终造成网络拥塞。

针对网络拥塞的问题，业界也一直在提出不同的拥塞控制算法，拥塞算法的核心包括判断拥塞状态和决策合适的发送码率，这两个其实是map和reduce模型，把网络上返回的数据进行map，通过网络状态ruduce出一个合理的发送码率。

GCC是一种基于延迟预估和丢包的拥塞控制算法，算法分为在接收端进行卡尔曼算法预估后返回发送端进行码率调整两部分。Transport CC是基于发送端线性预测的拥塞控制算法，与GCC一样主体都是基于时延的拥塞控制判断。这两种算法存在不同程度上的缺陷，在实现算法的过程中过于学术，比如GCC中有一个丢包率2%/10%的预值，但其实拥塞发生并不一定会产生丢包，而且丢包也不一定意味着发生拥塞，这种情况对于GCC是失效的。GCC基于时延估算的主体在现阶段来看与带宽的记忆丢包没有争抢率，斯坦福大学提出的Salsify算法是基于视频帧之间的时延去估算整个编码器的编码速度，但它一定要在编码器的基础上执行，无法满足将视频传到sever上进行分发的要求，如果只做分段拥塞控制就需要在sever上进行重解码和重编码，无法满足目前实时视频领域的应用。

实时传输理想的拥塞控制算法要满足三个特点，第一要相对激进，算法要能抢过流氓软件和一些基于丢包的算法。第二要对百毫秒级或者是毫秒级的码率进行实时调整，间隔尽量减小，尽量快的适应传输条件，这样卡顿时间不会太长，也能够带来更好的用户体验。第三是要能应对延迟型和丢包型的拥塞，同时能够进行分段计算。

2. BBR

BBR是基于接收端反馈和发送端调节码率的拥塞控制算法。

2.1 模型

远端packet feedback反馈信息输送到BBR之后，经过一系列运算得到拥塞控制的窗口大小（TCP发送端口）和发送码率。

2.2 网络FIFO概念

首先整个网络分为正在传输和发生堆积两部分，BBR在构建模型中只计算网络正在传输的部分，计算过程中引入了BDP（拥塞控制窗口）的概念。当前路由器的吞吐和缓冲能力大大加强，包在发送到路由器时虽然会发生拥塞，但在足够的内存和磁盘存储空间的条件下不会发生丢包现象，记忆延迟对网络更加敏感，但记忆丢包如果不发生丢包码率就不会下降，在这种情况下记忆延迟抢不过丢包。

BDP的计算方式是网络周期性最小延迟*网路周期性最大带宽。

BDP中网络周期性最小延迟和网路周期性最大带宽是通过BBR的四个状态机来计算的，第一个状态是STARTUP，BBR刚进入STARTUP时会进行慢启动，慢启动不断地增加带宽到带宽不再增长或者发生丢包现象就会切入DRAIN排空状态，进入排空状态是由于BPD已满，飞行数据发生堆积。DRAIN状态会在发送数据小于BDP时进入重新评估带宽的过程，如果持续一定周期还没有探测到最小RTT的值，就需要进行最小RTT的探测工作，BBR将窗口设置为4个miss大小或者保留3/4的大小去估算最小延迟，估算结束后重新回到STARTUP状态。

BDP/RTT就是我们认为可以发送的码率。

发送出去会有pace sender通过平滑发送发到接收端，接收端会把一个一个的包返回给发送端，发送端通过事件可以很快得到最小延迟和最大带宽的样本，结合一定的算法得到相对应的BDP，由BDP可以得到pacing rate，最后不断调整带宽形成循环，达成拥塞控制的目的。

3. 实时视频传输与BBR

3.1 实时视频传输与BBR相结合

网络协议进入网络接收器以后，通过RTCP的方式获得feedback信息直接输入BBR，再通过一系列状态机计算出带宽和窗口大小，码率分配器会根据各种情况对码率进行重新分配，调节视频编码器使码率达到缩放自如的反馈。实时视频有非持续性的特点，关键帧之间流量不均匀，帧间存在时延，突然发送实时视频会导致中间为空的状态，为了防止这样的情况发生设计了pacer用来平滑发送。

3.2 Feedback

RTT在实际应用中设计的是记忆帧的反馈，这样减少了反馈数量的同时也提升了效率，通过上图中的公式可以得到RTT的反馈序列。

即时速率是通过发送的数据和接收/发送端的相互统计，由于网络发生抖动会使send bitrate变得非常大，即时速率不能超过发送端本身的速度，所以要在两值中取最小值以减少误差。

3.3 Pacer

pacer的发送机制基于BDP发送数据和pacing rate发送数据，如果发送数据已经超过了BDP的吞吐量，此时pacer不会再向外发送数据加重网络拥塞，pacing是间隔5毫秒的间隔发送，pacing rate是基于5毫秒发送的数据量，基于这两个条件就可以构建出定时发送的pacer。

在探测最高带宽时，使用pacer的padding来满足BBR的probe_bw状态最大带宽探测要求。

3.4 AIMD码率决策

BBR是及时发送的码率而不是编码器需要采用的码率，这样会导致网络拥塞问题更加复杂，因此设计了AIMD码率决策来控制video码率的机制。如果BDPinfight_size时，并不会采用即时码率而是用和式加来对码率进行控制，通过添加一个固定倍数码率来平滑地控制整个运作的反馈机制，避免网络恶化。

3.5 拥塞控制与QoS

QoS和拥塞控制是两个概念，QoS是在拥塞控制的范畴之下进行的，码率和拥塞控制的窗口大小会制约QoS的行为。FEC/NACK之间是制约关系，所以一定要基于决策码率来做。

3.6 BBR与GCC比较

上图中可以明显看到BBR在网络限速的情况下表现要比GCC良好一些，不会有大幅度的网络抖动和衰减。

3.7 多路竞争测试

上图是关于BBR多路竞争的测试，测试过程是在300kBps的带宽下分时间段引入三路BBR数据流，最终观察发送码率是否是平均分配的。

4. 总结

BBR的比较豪放激进，具有不容易被其他应用抢占带宽、码率调节实时性高，能很好应对网络变化、可以对应各种类型的网络丢包和技术成熟等优势。

但BBR的不足也表现在，评估最小RTT时会减小窗口，这样会使发送码率下降，极端情况下会使实时视频瞬间质量变差。BBR在诞生之初并不是用做小带宽传输，因此在小码率视频传输过程中，BBR的效果并不明显。最重要的问题还有padding计算流量不经济实用，需要在使用过程中重点考量。BBR所有的带宽统计和实效性都是基于RTT，如果RTT过大会导致带宽的条件不太平滑。

源码实现：https://github.com/yuanrongxi/razor

————————————————

版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/96226078

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。