远程控制的体验是否优秀与网络有着很大的关系。想要触达远程控制体验的上限,我们需要十分先进远控算法技术,同时也需要网络状态足够稳定;但现实中,很多需要使用远程控制的场景并没有特别稳定的网络,甚至可以称其为“弱网环境”,在这类场景下保证远程控制体验的“下限”也十分重要。
针对弱网环境下的诸多问题,“国民远控向日葵”通过引入BBR拥塞控制算法让服务器之间的连接更快,端与服务器的连接更稳定,进而提升向日葵在弱网环境下的连接稳定性和带宽的利用率。
这里,我们就来介绍一下到底什么是BBR拥塞控制算法,这一算法是如何发展而来的,向日葵引入该算法后效果如何。
何为拥塞控制算法
想要理解拥塞控制算法,我们首先要对网络为什么会出现丢包卡顿进行一个简单的解释。
互联网上的两点通信时,每经过一个路由设备叫一跳(hop)。每一跳都有不同的带宽,两点之间的可用带宽是每一跳中的最小值,被称为Bottleneck BW。因为是公共链路,它们拥挤、丢包和排队难以避免,可用带宽也时大时小,这便是网络卡顿的根本原因之一。
但网络通信有一个补救机制,即使排队和路由抖动产生了丢包或者数据错误,4层的TCP协议也会处理,它会重传并进行带宽控制,以保证数据的完整性,这便是拥塞控制算法的核心。
早期的Cubic拥塞控制算法
1980年代的互联网崩溃,促成了TCP拥塞控制的落地。经过十多年的发展,Cubic出现并延续至令,目前它仍然是互联网主流的拥塞控制算法,它基于著名的“加性增,乘性减”(AIMD)控制律,将丢包作为网络链路拥塞的指示。通过检测丢包,发现并主动降低发送频率,减少拥塞。这被称为“基于丢包”的拥塞控制算法。同类算法有几个,像更早前的Reno, BIC等。
由于只有当路由器的队列满了以后才会有丢包,因此,这类算法倾向于快速填满瓶颈路由器的缓存,然后急剧降低发包(减少50%),当队列空闲后又慢慢填满,周而复始。
Cubic算法的正常运行对链路的丢包率有一定的要求,在丢包率较高的长肥管道环境下,其发送窗口会迅速收敛到很小。另一方面,当实际可用带宽增大时,它总是会花固定的时间去探测然后慢慢增大,效率是相对低下的。
同时,Cubic在拥塞避免阶段会逐渐加大发送窗口直至填满瓶颈队列,这种机制加速了拥塞的形成,造成了网络延时的波动。因此,在链路瓶颈处保持最大带宽和最小延时的状态是拥塞控制的目标,但明显Cubic在目前的互联网环境中已经不能很好的胜任。
谷歌提出BBR拥塞控制算法
基于上述Cubic算法的短板,谷歌提出一种基于延时带宽积的算法BBR (Bottleneck Bandwidth and RTT),使用了交替测试链路的最大带宽与最小的RTT的方法,来寻找名为Kleinrock的最佳操作点,这个点,核心特征是报文开始排队。如下图所示,Cubic的拥塞控制点是排队并且缓存已经满了。
将最近10次往返中测得的最大带宽视为Bmax,将过去10s中测得的最小RTT视为Tprop,然后根据这两个值估算BDP。
BBDP = Bmax × Tprop
BBR分别通过窗口增益和起博增益来调整CWND和发送速率,进而控制其发送行为,将拥塞快速收敛到最佳控制点。
向日葵通过BBR算法,提升连接带宽3倍以上
基于BBR算法的种种优势,向日葵将其引入并应用在远程控制技术中,据向日葵的实验室数据显示,在跨国的弱网环境中,未使用多路复用的单连接应用,BBR能提升约10倍的端与服务器间的可用带宽(如:由120Kbps提升到>1Mbps)。同时,国内的服务器间互联时,BBR能提升1倍以上的服务器间带宽利用率(由40%到85%)。
在实际的使用中,在经过支持BBR的服务器中转后,向日葵的连接带宽提升了3倍以上,帧率提升了5倍以上,对于用户体验改善明显。
在BBR算法的加持下,我们可以显著的感受到向日葵远程控制的“下限”有了很充足的保障,当远程控制应用在很多弱网环境、如工业、户外等场景下时,相信向日葵能够发挥充分的技术优势。
