BBR拥塞算法的简单解释
TCP BBR的ACM论文中，开篇就引入了图1，以此来说明BBR算法的切入点：
- 为何当前基于丢包探测的TCP拥塞控制算法还有优化空间？
- BBR算法的优化极限在哪儿？
图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式可得：
- T/S >= 1/BtlBw
- 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传输速率也会有大幅提升，下图中插入的图为CDF累积概率分布函数，从CDF中可以很清晰的看到CUBIC下大部分连接的吞吐量都更低：
如果链路发生了切换，新的瓶颈带宽升大或者变小怎么办呢？BBR会尝试周期性的探测新的瓶颈带宽，这个周期值为1.25、0.75、1、1、1、1，如下所示：
1.25会使得BBR尝试发送更多的飞行中报文，而如果产生了队列积压，0.75则会释放队列。下图中是先以10Mbps的链路传输TCP，在第20秒网络切换到了更快的40Mbps链路，由于1.25的存在BBR很快发现了更大的带宽，而第40秒又切换回了10Mbps链路，2秒内由于RTT的快速增加BBR调低了发送速率，可以看到由于有了pacing_gain周期变换BBR工作得很好。
pacing_gain周期还有个优点，就是可以使多条初始速度不同的TCP链路快速的平均分享带宽，如下图所示，后启动的连接由于过高估计BDP产生队列积压，早先连接的BBR便会在数个周期内快速降低发送速率，最终由于不产生队列积压下RTT是一致的，故平衡时5条链路均分了带宽：
我们再来看看慢启动阶段，下图网络是10Mbps、40ms，因此未确认的飞行字节数应为10Mbps*0.04s=0.05MB。红色线条是CUBIC算法下已发送字节数，而蓝色是ACK已确认字节数，绿色则是BBR算法下的已发送字节数。显然，最初CUBIC与BBR算法相同，在0.25秒时飞行字节数显然远超过了0.05MB字节数，大约在 0.1MB字节数也就是2倍BDP：
大约在0.3秒时，CUBIC开始线性增加拥塞窗口，而到了0.5秒后BBR开始降低发送速率，即排空瓶颈路由器的拥塞队列，到0.75秒时飞行字节数调整到了BDP大小，这是最合适的发送速率。
当繁忙的网络出现大幅丢包时，BBR的表现也远好于CUBIC算法。下图中，丢包率从0.001%到50%时，可以看到绿色的BBR远好于红色的CUBIC。大约当丢包率到0.1%时，CUBIC由于不停的触发拥塞算法，所以吞吐量极速降到10Mbps只有原先的1/10，而BBR直到5%丢包率才出现明显的吞吐量下降。
CUBIC造成瓶颈路由器的缓冲队列越来越满，RTT时延就会越来越大，而操作系统对三次握手的建立是有最大时间限制的，这导致建CUBIC下的网络极端拥塞时，新连接很难建立成功，如下图中RTT中位数达到 100秒时 Windows便很难建立成功新连接，而200秒时Linux/Android也无法建立成功。
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，我们便能更好的应对网络拥塞导致的性能问题，也会对未来的拥塞控制算法发展脉络更清晰。