（本篇文章主要是给自己以后看，协助记忆，不会过于在意菜鸟读者是否能够完全读懂）
TCP BBR的ACM论文中，开篇就引入了图1，以此来说明BBR算法的切入点：
- 为何当前基于丢包探测的TCP拥塞控制算法还有优化空间？
- BBR算法的优化极限在哪儿？
为了理解这张图花了我整整一个晚上的时间，它使我重新审视了所有基础概念，而我以下的讨论对于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。
