BBR拥塞算法的简单解释

TCP BBR的ACM论文中,开篇就引入了图1,以此来说明BBR算法的切入点:

  • 为何当前基于丢包探测的TCP拥塞控制算法还有优化空间?
  • BBR算法的优化极限在哪儿?

BBR拥塞算法的简单解释_第1张图片

图1

为了理解这张图花了我整整一个晚上的时间,它使我重新审视了所有基础概念,而我以下的讨论对于TCP定义的RTT、带宽、Inflight data都作了简化,从而使讨论更易于满足物理直觉,但又不影响最终结论。

为了便于讨论,先引入形式符号。当我们使用TCP从A端到B端传输数据时,A与B间的网络链路是复杂的并且是动态变化的,但我们可以把A到B的网络想象成一段黑盒链路,这条链路有以下物理属性:

  • RTprop:光信号从A端到B端的最小时延(其实是2倍时延,因为是一个来回,但不影响讨论),这取决于物理距离
  • BtlBw:在A到B的链路中,它的带宽取决于最慢的那段链路的带宽,称为瓶颈带宽,可以想象为光纤的粗细
  • BtlBufSize:在A到B的链路中,每个路由器都有自己的缓存,这些缓存的容量之和,称为瓶颈缓存大小
  • BDP:整条物理链路(不含路由器缓存)所能储藏的比特数据之和,BDP = BtlBw * RTprop

仅有物理属性还不够,在实际应用中我们最关心的是TCP链接的两个真实属性:

  • T(时延):数据从A到B的实际时延,对应于图中的round-trip time(其实是单程的trip time,2倍即为RTT,不影响讨论)
  • R(带宽):数据的实际传输带宽,对应于图中的delivery rate(并非严格对应,与T一样做了等效简化)

我再啰嗦一句:TCP BBR协议定义的带宽(delivery rate)与我们的直觉不一样,它的定义是:

带宽 = 数据量/从发送出去至收到ACK的时长

而我们的直觉是:数据穿过网线的速度

为了利于的直觉想象,本文使用T来代替RTT,使用R来代替delivery rate,下文的所有概念也一样作为简化,请注意!

此外,为了定量分析T与R,再引入一个概念:

  • D:已经从A发出但未被B收到的数据(对应于inflight data,我故意修改了它的原始定义——A已经发出但未收到B返回的ACK的数据——是为了直觉想象,不影响结论)

有了以上定义,很自然就有了以下3个式子:

  • T >= RTprop,即实际时延总是大于等于最小时延
  • R <= BtlBw,即实际带宽总是小于等于瓶颈带宽
  • R = D/T

由以上3式可得:

  1. T/S >= 1/BtlBw
  2. R/S <= 1/RTprop

1,2两式就是图中两个斜率(slope)的由来。

有了上面的讨论,就可以较为轻松地理解上半图与下半图的物理意义了:

上半图

  • 当链路上正在传输的比特数据未超过整条链路的物理容量(BDP)之前,传输时延的极限就是RTprop,对应上半图中蓝色的横线
  • 当数据塞满了整条链路的物理容量后,路由器开始启用缓存来存储比特数据,这相当于拉长了整个链路,造成传输时延开始变大,偏离了物理极限RTprop,于是有了slope = 1/BtlBw那条绿色斜线
  • 当路由器的缓存填满后(BDP+BtlBufSize),整条链路开始丢数据,1/BtlBw斜线消失,对应于上半图中红点虚线

下半图

  • 当链路上正在传输的比特数据未超过整条链路的物理容量(BDP)之前,在B端观察到的数据带宽是逐渐往上涨的,这个带宽的上涨速率由5式确定,即slope = 1/RTprop,对应下半图中蓝色斜线
  • 当数据塞满了整条链路的物理容量后,路由器开始启用缓存来存储比特数据,但不影响B端观察到的带宽,这个带宽的极限就是BtlBw,对应于图中那条绿色的BtlBw横线
  • 当路由器的缓存填满后(BDP+BtlBufSize),整条链路开始丢数据,但B端观察到的带宽极限还是BtlBw,对应于下半图中红点虚线

由此就可以解答这两个问题了:

  • 为何当前基于丢包探测的TCP拥塞控制算法还有优化空间?

因为基于丢包探测的算法总会使inflight的数据量达到BDP+BtlBufSize这个状态,在现代的路由器中由于缓存很大,相当于把物理链路人为的拉长了,使数据传输的延时变大,即RTT变大。

  • BBR算法的优化极限在哪儿?

BBR算法不再基于丢包探测,而是努力去估算BDP和RTprop,从而使RTT向它的物理极限RTprop靠近,从而减少传输时延,达到提速TCP的目的。

那么BBR与丢包探测算法的共同点在哪里?——它们都试图使链路的带宽趋于它的物理极限:BtlBw。

基于BBR算法,由于瓶颈路由器的队列为空,最直接的影响就是RTT大幅下降,可以看到下图中CUBIC红色线条的RTT比BBR要高很多:

BBR拥塞算法的简单解释_第2张图片

而因为没有丢包,BBR传输速率也会有大幅提升,下图中插入的图为CDF累积概率分布函数,从CDF中可以很清晰的看到CUBIC下大部分连接的吞吐量都更低:

BBR拥塞算法的简单解释_第3张图片

如果链路发生了切换,新的瓶颈带宽升大或者变小怎么办呢?BBR会尝试周期性的探测新的瓶颈带宽,这个周期值为1.25、0.75、1、1、1、1,如下所示:

BBR拥塞算法的简单解释_第4张图片

1.25会使得BBR尝试发送更多的飞行中报文,而如果产生了队列积压,0.75则会释放队列。下图中是先以10Mbps的链路传输TCP,在第20秒网络切换到了更快的40Mbps链路,由于1.25的存在BBR很快发现了更大的带宽,而第40秒又切换回了10Mbps链路,2秒内由于RTT的快速增加BBR调低了发送速率,可以看到由于有了pacing_gain周期变换BBR工作得很好。

BBR拥塞算法的简单解释_第5张图片

pacing_gain周期还有个优点,就是可以使多条初始速度不同的TCP链路快速的平均分享带宽,如下图所示,后启动的连接由于过高估计BDP产生队列积压,早先连接的BBR便会在数个周期内快速降低发送速率,最终由于不产生队列积压下RTT是一致的,故平衡时5条链路均分了带宽:

BBR拥塞算法的简单解释_第6张图片

我们再来看看慢启动阶段,下图网络是10Mbps、40ms,因此未确认的飞行字节数应为10Mbps*0.04s=0.05MB。红色线条是CUBIC算法下已发送字节数,而蓝色是ACK已确认字节数,绿色则是BBR算法下的已发送字节数。显然,最初CUBIC与BBR算法相同,在0.25秒时飞行字节数显然远超过了0.05MB字节数,大约在 0.1MB字节数也就是2倍BDP:

BBR拥塞算法的简单解释_第7张图片

大约在0.3秒时,CUBIC开始线性增加拥塞窗口,而到了0.5秒后BBR开始降低发送速率,即排空瓶颈路由器的拥塞队列,到0.75秒时飞行字节数调整到了BDP大小,这是最合适的发送速率。

当繁忙的网络出现大幅丢包时,BBR的表现也远好于CUBIC算法。下图中,丢包率从0.001%到50%时,可以看到绿色的BBR远好于红色的CUBIC。大约当丢包率到0.1%时,CUBIC由于不停的触发拥塞算法,所以吞吐量极速降到10Mbps只有原先的1/10,而BBR直到5%丢包率才出现明显的吞吐量下降。

BBR拥塞算法的简单解释_第8张图片

CUBIC造成瓶颈路由器的缓冲队列越来越满,RTT时延就会越来越大,而操作系统对三次握手的建立是有最大时间限制的,这导致建CUBIC下的网络极端拥塞时,新连接很难建立成功,如下图中RTT中位数达到 100秒时 Windows便很难建立成功新连接,而200秒时Linux/Android也无法建立成功。

BBR拥塞算法的简单解释_第9张图片

BBR算法的伪代码如下,这里包括两个流程,收到ACK确认以及发送报文:

function onAck(packet) 
  rtt = now - packet.sendtime 
  update_min_filter(RTpropFilter, rtt) 
  delivered += packet.size 
  delivered_time = now 
  deliveryRate = (delivered - packet.delivered) / (delivered_time - packet.delivered_time) 
  if (deliveryRate > BtlBwFilter.currentMax || ! packet.app_limited) 
     update_max_filter(BtlBwFilter, deliveryRate) 
  if (app_limited_until > 0) 
     app_limited_until = app_limited_until - packet.size

这里的app_limited_until是在允许发送时观察是否有发送任务决定的。发送报文时伪码为:

function send(packet) 
  bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin 
  if (inflight >= cwnd_gain × bdp) 
     // wait for ack or retransmission timeout 
     return 
  if (now >= nextSendTime) 
     packet = nextPacketToSend() 
     if (! packet) 
        app_limited_until = inflight 
        return 
     packet.app_limited = (app_limited_until > 0) 
     packet.sendtime = now 
     packet.delivered = delivered 
     packet.delivered_time = delivered_time 
     ship(packet) 
     nextSendTime = now + packet.size / (pacing_gain × BtlBwFilter.currentMax) 
  timerCallbackAt(send, nextSendTime)

pacing_gain便是决定链路速率调整的关键周期数组。

BBR算法对网络世界的拥塞控制有重大意义,尤其未来可以想见路由器的队列一定会越来越大。HTTP3放弃了TCP协议,这意味着它需要在应用层(各框架中间件)中基于BBR算法实现拥塞控制,所以,BBR算法其实离我们很近。理解BBR,我们便能更好的应对网络拥塞导致的性能问题,也会对未来的拥塞控制算法发展脉络更清晰。

 

你可能感兴趣的:(网络)