我不知道该怎么说。总之，便舍船，从口入，我看不到黄发垂髫并怡然自乐！
在BBR之前，存在着两种拥塞控制算法，基于丢包的和基于时延的，不管哪一种都是基于探测的，换句话说，基于丢包的算法将丢包作为一种发现拥塞的手段，而基于时延的算法则是将时延增加作为发现拥塞的手段，它们之所以错误是因为它们的初衷就是错的：
丢包算法：为了发现拥塞就不得不制造拥塞，这TMD的太JIBA讽刺了，为了戒毒，就必须先TMD的染上毒瘾！然而根本没毒瘾的话何谈戒毒！TCP之所以这么玩我觉得很大程度上”归功“于30多年前最初的关于拥塞控制的论文。在那个年代，和我们现在的网络完全不同，几乎很少的队列，由于存储器比较贵，所以路由器和交换机上几乎都没有太深的队列，甚至都是很浅的队列，在那种情况下，丢包确实表明了拥塞的信号，然而后来随着设备队列越来越深(摩尔定律使然)，在丢包前，一个TCP连接必须不断的去填充非常深的队列，当深队列被填满后，是什么情况？是拥塞！
我不得不再次重复解释时间延展性缓存和时间墙缓存的区别，对于前者，时间可以消耗掉任何数据包，然而对于后者，时间墙的存在则必然会发生拥塞，如果不明白这个基本区别的话，就会设计出错误的拥塞控制方案。不幸的是，TCP在30年来都没有对这两类缓存进行区分！同样的大小，二者的表现完全不同！
后面我把时间延展性缓存称作第一类缓存，时间墙缓存称作第二类缓存。只有当第二类缓存被填满的时候，算法才会发现拥塞，而此时，拥塞已经要开始缓解了！滞后性！
时延算法：OK！我承认时延算法主动避免了第二类缓存的数据堆积(如果你意识不到这一点，请停止阅读。)，然而由于丢包算法的存在，时延算法一直处在被压制的状态。想知道时延算法的问题，请自己百度，根本不需要google。
所以说，这些算法都是错的！那么BBR就一定对吗？
近几日，从9月16号开始，BBR被炒作的沸沸扬扬，好像就是神一般，但事实会证明都JIBA扯淡，TCP拥塞控制领域本身就是一个无解的领域，现在用BBR撕CUBIC好像还比较得心应手，到头来来个RBB就可以跟BBR势均力敌了，带宽还是那么多，硬件资源就摆在那，大家要公平共享这才是王道，任由一家独大抢占别人的带宽还不告诉别人，这是傻逼。所以我说，TCP加速这个行当是个丑行。
BBR不是神，甚至不是人，但它...
BBR区分了两类缓存，并且发誓不再将第二类缓存作为BDP的计算，然而BBR有原则，它将坚持在max-BW和min-RTT处，任由其它的算法去抢那些第二类缓存吧，CAO！TCP的君子协定让那些别的算法发现第二类缓存填满后，会降速到不足以填充第一类缓存的地步，此时，BBR会说：这是你们出让给我的。
总结一点，BBR不去抢占没有意义的第二类缓存，这类缓存不光没有意义--不会增加速率，一旦填满后后还要付出代价而降速！BBR只要属于自己的。BBR会尽可能完全利用第一类缓存！
所以，我觉得BBR既不是基于丢包的算法，也不是基于时延的算法，而是一个基于反馈的算法！既然搞不定猜测，那就不猜测，BBR只基于现在，而不考虑历史(win_minmax表明其仅仅在意时间窗口内的历史！)！
BBR算法避免了填充第二类缓存，因此它的初衷就是避免拥塞-真正的cong_avoid！。
避免了拥塞，在Linux传统看来就是避免了丢包！BBR的收敛点在第二类缓存左边，因此不会因为拥塞而丢包，但是丢包分三类：
1.噪声丢包
2.拥塞被动丢包
BBR已经可以应对1和2(对于1，通过时间窗口可以过滤，对于2，算法本身的反馈收敛特性决定)，那么对于3，BBR有何杀手锏呢？这就是BBR的long-term rate特性。
我先来展示一段关于BBR long-term的注释：
Token-bucket traffic policers are common (see "An Internet-Wide Analysis of Traffic Policing", SIGCOMM 2016). BBR detects token-bucket policers and explicitly
models their policed rate, to reduce unnecessary losses. We estimate that we're policed if we see 2 consecutive sampling intervals with consistent throughput
我之前说过，BBR会基于即时测量的上一次发送带宽来计算这次该发送的速率和cwnd，好像BBR根本不会经历丢包一样！但这是不真实的！任何算法都不能忽略上述第3种丢包。没有拥塞，没有噪声，但就是丢包了，Why？因为路由器有权力决定任何数据包的丢失。TCP流在路由器面前就是渣！虽然是渣渣，BBR还是可以发现路由器的这种丢包行为。
BBR在采集即时带宽的同时，还在默默观察丢包率。