实时音视频系统要求低延时，流畅性好，而实际网络状态却是复杂多变的，丢包，延时和网络带宽都在时刻变化，这就对网络拥塞控制算法提出了很高的要求。本文来自网易云信资深工程师肖磊在LiveVideoStackCon2019北京站上的精彩分享，文章中详细介绍了BBR拥塞控制算法产生背景及其演进。
大家好，我是网易云信音视频工程师肖磊，目前致力于实时音视频领域的QoS研究，通过优化拥塞控制算法，为用户提供高带宽利用率，低延时，抗抖动能力强的实时音视频服务。
本次我分享的主题是BBR及其在实时音视频领域的应用，BBR全称是Bottleneck Bandwidth and RTT，它是谷歌在2016年推出的全新网络拥塞控制算法，在此之后大家对于拥塞控制的关注度逐渐提高，越来越多的新算法被推出。本次分享的内容主要包括BBR算法的基本原理以及BBR算法如何应用在网易云信的实时音视频产品中。
拥塞控制始于20世纪80年代，当时TCP是滑动窗口的算法，拥塞窗口固定，需要通过不断地响应报文推动滑动窗口前进。但在1986年TCP导致了拥塞崩溃，比如现在多端采用TCP发起报文，实际带宽达不到所能提供的最大带宽时网络出现拥堵，此时会有越来越多的TCP发起重试，进而加剧拥堵情况。
2000年之后伴随着互联网大爆发，各类应用特别是音视频应用数量大幅增加，TCP拥塞控制算法无法满足当前互联网应用对网络传输高实时性、高带宽利用率、高吞吐量的需求，在这种背景下BBR应运而生。
在互联网发展的过程当中，TCP算法也做出了一定改变，先后演进了Reno、NewReno、Cubic和Vegas，这些改进算法大体可以分为基于丢包和基于延时的拥塞控制算法。基于丢包的拥塞控制算法以Reno、NewReno为代表，它的主要问题有Buffer bloat和长肥管道两种，基于丢包的协议拥塞控制机制是被动式的，其依据网络中的丢包事件来做网络拥塞判断。即使网络中的负载很高，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。最初路由器转发出口的Buffer 是比较小的，TCP在利用时容易造成全局同步，降低带宽利用率，随后路由器厂家由于硬件成本下降不断地增加Buffer，基于丢包反馈的协议在不丢包的情况下持续占用路由器buffer，虽然提高了网络带宽的利用率，但同时也意味着发生拥塞丢包后，网络抖动性加大。另外对于带宽和RTT都很高的长肥管道问题来说，管道中随机丢包的可能性很大，TCP的默认buffer设置比较小加上随机丢包造成的cwnd经常下折，导致带宽利用率依旧很低。基于延时的拥塞控制算法以vegas为代表，但当vegas出现时，基于丢包的拥塞控制算法在市面已经占据主流，vegas抢不到带宽出现“饿死”现象，因此也没办法与之抗争。在BBR出现之前，TCP的拥塞控制一直逃脱不了这两个方向，另外优化TCP的拥塞控制难免涉及到内核的修改，这也是限制TCP继续优化的一大问题。BBR（Bottleneck Bandwidth and Round-trip propagation time）是一种基于带宽和延迟反馈的拥塞控制算法。目前已经演化到第二版，是一个典型的封闭反馈系统，发送多少报文和用多快的速度发送这些报文都是在每次反馈中不断调节。在BBR提出之前，拥塞控制都是基于事件的算法，需要通过丢包或延时事件驱动；BBR提出之后，拥塞控制是基于反馈的自主自动控制算法，对于速率的控制是由算法决定，而不由网络事件决定，算法核心是“不排队”。
BBR算法的核心是找到最大带宽（Max BW）和最小延时（Min RTT）这两个参数，最大带宽和最小延时的乘积可以得到BDP(Bandwidth Delay Product), 而BDP就是网络链路中可以存放数据的最大容量。BDP驱动Probing State Machine得到Rate quantum和cwnd，分别设置到发送引擎中就可以解决发送速度和数据量的问题。
一般情况下的即时带宽计算，很多人认为将发送报文和收到报文的时间点记录下来，发包数量再除以时间就可以得到带宽，但这样的计算方式是错误的。由于delay feedback表示一组报文的响应，一组报文之后会有一个延迟的相应来通知哪些报文没有收到，以及收到的时间差是多少。delay feedback容易受到网络影响，因此报文不会均匀发送，易发生聚合和丢包现象，在计算时要考虑发送的时间差和ack的时间差，公式为：bandwidth = delivered/max（send time,ack time），这样才能抵消掉延迟聚合和丢失的情况。
BDP（带宽延迟积）是BBR算法中的核心，其中最大带宽和最小延迟不能同时得到。如图所示，横轴是网络链路中的数据量，纵轴分别是RTT和带宽，在RTT不变的时候，网络没有发生拥塞，带宽一直在上升，没有达到最大，而当带宽停止上涨的时候，网络开始拥塞，RTT持续变大，直到发生丢包。图中BDP所标识的点就是理想情况下最大带宽和最小延时。很明显只有在没有发生拥塞时才能得到RTT的数值，因此很难在同一时刻找到最小的RTT和最大带宽。
既然最大带宽和最小延迟不能同时得到，必然存在探测最大带宽和最小RTT的过程。上图表示的是BBR的状态机，状态机分为Startup，Drain，ProbeBW，ProbeRTT4个阶段。Startup阶段类似于普通拥塞控制里的慢启动，以2/ln2的增益系数持续更新发包速率，带宽连续三次没有增长就可以判定达到最大带宽而进入Drain状态。进入Drain状态时队列可能存在拥堵，因此需要把 Startup状态中产生的队列排空，排空的速率是ln2/2，如果inflight < BDP 说明此时网络由BBR造成的拥塞已经全部排空，如果 inflght > BDP 说明此时网络还有拥塞，不能进入下一个状态。拥塞排空之后会进入探测带宽阶段，探测最大带宽的方法是在10个RTT中观测到的最大带宽，以此数据作为最大带宽。如果10s没有得到最小RTT，超时之后需要继续探测最小RTT。探测最小RTT需要尽量避免网络拥堵，降低拥塞窗口，发送比较少的报文。整个BBR的拥塞控制在启动之后，最终是在Drain和ProbeBW阶段之间切换。
BBR相对TCP的优点包括抗丢包能力强、延迟低、抢占能力强和平稳发送。在BBR算法之前的TCP Cubic，拥塞控制算法并没有平稳发送的说法，而只是判断发送与否的问题，BBR算法出现之后，会平稳的发送数据，不会突发流量冲击。BBR相对TCP的优点包括抗丢包能力强、延迟低、抢占能力强和平稳发送。在BBR算法之前的TCP Cubic，拥塞控制算法并没有平稳发送的说法，而只是判断发送与否的问题，BBR算法出现之后，会平稳的发送数据，不会突发流量冲击。关于BBR算法的抗丢包能力可以用上图来说明，BBR算法不会因为一次或者偶然的丢包就大幅降低吞吐量，因此具有较强的抗丢包能力。
对于BBR在低延迟方面的优势来说，由于目前关于拥塞控制的算法很多，BBR在运转时设备中可能会有多种拥塞控制算法同时作用的情况，BBR算法只能保证自己不排队。但在实际现行网络下，是否排队并不由BBR一个算法决定，运行过程中BBR算法不会加重网络拥塞。在带宽探测阶段，BBR算法每一轮都会尝试上探更大的带宽，由此可以很快抢占其他拥塞算法让出来的带宽，这也是BBR算法抢占能力强的原因。
之前提到在TCP算法中并没有平稳发送的说法，BBR算法后来引入了平稳发送的概念，不只解决了发送多少的问题，还解决了发送速率的问题，具体实现是使用cwnd控制发送数量，发送速度使用漏桶算法控制。BBR算法中的cwnd与TCP算法不同，TCP算法中的cwnd是对网络状态的模拟，分为发送窗口和接收窗口，而BBR算法只有发送窗口，且cwnd = 2*BDP。
BBR算法在具备一些优势的同时也存在一定的缺点，比如原始的BBR算法收敛性受到pacing gain周期影响，带宽突降的时候，BBR需要多个轮次才会降到实际带宽。这其中的原因是BBR每轮只能降速一次，而pacing gain的6个RTT的保持周期大大加长了这个时间。由于pacing gain上探周期的1.25无法抵消掉25%以上的丢包，这会造成带宽反馈持续下降，BBR吞吐量就会断崖式下跌。BBR算法设计之初cwnd = 2*BDP，在此之前BBR算法要比Cubic强很多，但在实际的网络环境中，如果出现buffer很大的情况，BBR是比Cubic竞争性差的，因此在应用BBR算法时必须了解当前的网络状况。
在算法公平性方面，BBR在与Reno竞争时可以占用90%以上的带宽，但在与多个BBR流竞争时，RTT高的流占用带宽更高，其中也暴露的漏洞是如果想占用更高带宽，可以人为调高RTT的值，这些并不是BBR算法的设计初衷。在抗抖动能力方面，RTT的抖动使BBR无法得到准确的BDP，探测带宽很有可能低于可用带宽。
如果将BBR算法应用在实时音视频领域，需要满足带宽（特别是低带宽场景）探测准确，适合实时音视频传输的低延时需求，能够满足音视频传输码率平稳的需求以及快速响应带宽变化这四个要求。
满足以上四个实时音视频需求的同时，BBR算法在应用时也存在着收敛速度慢、抗丢包能力无法达到预期的问题，另外实时音视频领域需要提供稳定的视频流，但BBR的ProbeRTT阶段只发4个包，发送速率下降太多会引发延迟加大和卡顿问题，最后BBR探测带宽需要Paddin有可能造成带宽浪费。
针对BBR应用在实时音视频领域遇到的问题，目前已经有不少解决方案。对于收敛速度慢的问题来说，BBR V2提出在Probe Down一次排空到位（inflight < BDP），另外还可以随机化6个1x平稳发送周期，缩短排空所需要的时间。对于抗丢包能力不足的问题来说，目前BBR算法的抗丢包能力是足够的，但在一些极端网络条件下可以把丢包率补偿到pacing rate，有效提升抗丢包能力。
ProbeRTT并不适用实时音视频领域，因此可以选择直接去除，或者像BBR V2把probe RTT缩短到2.5s一次，使用0.5xBDP发送。
为了保持带宽竞争性和平稳发送，BBR中的padding不可或缺，想要迅速感知带宽变化也必须有padding的存在。关于RTT不公平问题之前有提到RTT大占据的带宽多，但在排空阶段一次排空就可以缓解这个问题。
由上图整体可以看出BBR带宽利用率要高于Cubic。
目前GCC控制算法在实时音视频领域占据主流，但WebRTC的GCC算法仍然有一些局限性，比如将带宽限制在300k，一段时间后取消限制的场景来对比，由图像对比可以得到，BBR比GCC的带宽估计更加准确（GCC:250k,BBR:300k），而在带宽限制取消后，GCC需要20s以上才能恢复到最大带宽，BBR仅需要2s就可以恢复。
如果将带宽限制在2.5Mbps，加入200ms delay，200ms jitter，此场景中GCC和BBR的表现如图所示，GCC带宽探测只有300k，而BBR带宽维持在2.5M附近波动，在如此恶劣的网络环境中BBR的表现已经是相当优秀了。
总结来看，BBR算法有很多优点的同时也有很多缺点，目前没有一个算法能够适用所有的网络状态，针对不同的网络状态选择不同的拥塞算法似乎是一个可行的办法，但基于当前拥塞算法，融合其他算法的优点也是可以实现的，在此希望能够涌现出更多有兴趣的人为实时音视频领域的拥塞算法出力。除了针对复杂网络条件BBR拥塞控制算法优化之外，从4G到5G网络自身提升所带来的超高带宽、超低延迟，将会如何影响和改变即时通讯与音视频技术发展，点击【阅读原文】，走进《5G万物智联下的互联网通信云技术》沙龙。
LiveVideoStack正在招募编辑/记者/运营，与全球顶尖多媒体技术专家和LiveVideoStack年轻的伙伴一起，推动多媒体技术生态发展。同时，也欢迎你利用业余时间、远程参与内容生产。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”，或通过微信“Tony_Bao_”与主编包研交流。
![]()