BBR
BBR[4]是在2016年提出的一种新的拥塞控制算法,部署BBR后,在全球范围内访问Youtube的延迟降低了53%,在时延较高的发展中国家,延迟降低了80%。目前BBR已经集成到Linux 4.9以上版本的内核中。
BBR算法不将出现丢包或时延增加作为拥塞的信号,而是认为当网络上的数据包总量大于瓶颈链路带宽和时延的乘积时才出现了拥塞,所以BBR也称为基于拥塞的拥塞控制算法(Congestion-Based Congestion Control)。BBR算法周期性地探测网络的容量,交替测量一段时间内的带宽极大值和时延极小值,将其乘积作为作为拥塞窗口大小(交替测量的原因是极大带宽和极小时延不可能同时得到,带宽极大时网络被填满造成排队,时延必然极大,时延极小时需要数据包不被排队直接转发,带宽必然极小),使得拥塞窗口始的值始终与网络的容量保持一致。
由于BBR的拥塞窗口是精确测量出来的,不会无限的增加拥塞窗口,也就不会将网络设备的缓冲区填满,避免了出现Bufferbloat问题,使得时延大大降低。如图4所示,网络缓冲区被填满时时延为250ms,Cubic算法会继续增加拥塞窗口,使得时延持续增加到500ms并出现丢包,整个过程Cubic一直处于高时延状态,而BBR由于不会填满网络缓冲区,时延一直处于较低状态。
由于BBR算法不将丢包作为拥塞信号,所以在丢包率较高的网络中,BBR依然有极高的吞吐量,如图5所示,在1%丢包率的网络环境下,Cubic的吞吐量已经降低90%以上,而BBR的吞吐量几乎没有受到影响,当丢包率大于15%时,BBR的吞吐量才大幅下降。
BBR算法是反馈驱动的,有自主调节机制,不受TCP拥塞控制状态机的控制,通过测量网络容量来调整拥塞窗口,发送速率由自己掌控,而传统的拥塞控制算法只负责计算拥塞窗口,而不管发送速率(pacing rate),怎么发由TCP自己决定,这样会在瓶颈带宽附近因发送速率的激增导致数据包排队或出现丢包。
经过测试,在高延时、高丢包率的环境下,BBR相对于Cubic算法在传输速度上有较大的提升。
BBR算法的不足之处在于设备队列缓存较大时,BBR可能会竞争不过Cubic等比较激进算法,原因是BBR不主动去占据队列缓存,如果Cubic的流量长期占据队列缓存,会使得BBR在多个周期内测量的极小RTT增大,进而使BBR的带宽减小。
适用场景:适用于高带宽、高时延、有一定丢包率的长肥网络,可以有效降低传输时延,并保证较高的吞吐量。