周六，由于要赶一个月底的Deadline，因此选择了在家VPN加班，大半夜就爬起来跑用例，抓数据……自然也就没有时间写文章和外出耍了，不过利用周日的午夜时间（不要问我为什么可以连续24小时不睡觉，因为我觉得吃饭睡觉是负担），我决定把工作上的事情先放下，还是要把每周至少一文补上，这已经成了习惯。由于上周实在太忙乱，所以自然根本没有更多的时间去思考一些“与工作无关且深入”的东西，我指的与工作无关并非意味着与IT，与互联网无关，只是意味着不是目前我在做的。比如在两年前，VPN，PKI这些是与工作有关的，而现在就成了与工作无关的，古代希腊罗马史一直都是与工作无关的，直到我进了罗马历史研究相关的领域去领薪资，直白点说，老板不为之给我支付薪水的，都算是工作无关的东西。玩转与思考这些东西是比较放得开的，不需要对谁负责，没有压力，没有KPI，没有Deadline，完全自由的心态对待之，说不定真的很容易获得真知。

　　我认识一个草根鼓手朋友，玩转爵士鼓的水准远高于那些所谓的专业鼓手，自然带有一种侠客之风传道授业解惑，鼓槌随心所欲地挥舞在他自己的心中，没有任何负担和障碍，任何的节奏都可以一气呵成，从来不打重复鼓点，atv，那叫一个帅！然而他并非专业考级出来的，是拜师出来后自己摸索的。

　　要兴趣去自然挥洒，而不是迫于压力去应对。

　　我也是鼓手，但我打的不是爵士鼓，我是鼓噪者，技术的鼓噪者。本文与TCP BBR算法相关。

　　0. 说明

　　BBR热了一段时间后终于回归了理性，这显然要比过热地炒作要好很多。这显然也是我所期望的。

　　本文的内容主要解释一些关于BBR的细节问题。这些问题一般人可能不会关注，但是针对这些问题仔细思考的话，会得到很多有用的东西。在解释这些问题时，我依然倾向于使用图解的方式，但这一次我不再使用Wireshark的tcptrace图了，而是使用时序图的方式，因为这种时序图既然能够令人一目了然地解释TCP三次握手，四次分手，TIME-WAIT等，那它自然也能解释更复杂的机制，比如说拥塞控制。

　　1. 延迟ACK以及ACK丢失并不会影响TCP的传输速率

　　在大的时间尺度上看，延迟ACK以及ACK丢失并不会对速率造成任何影响，比如一个文件4个TCP段正好发完，即便前面几个ACK全部丢失，只有最后一个到达，那它的传输总时间也是不变的。

　　但是在细微的时间段内，由于延迟ACK或者ACK丢失带来的时间偏差却是不可忽略的。

　　首先我们再次看一下BBR是如何测量即时速率的。测量即时速率需要做一个除法，分子是一段时间内成功到达对端的数据包总量，分母就是这段时间。BBR会在每收到一次ACK的时候测量一次即时速率。计算需要的数据分别在数据传输和数据被ACK的时候采样。很显然，我们可以想当然地拍脑袋得出一个算法：

　　设数据包x发出的时间为t1，数据包x被应答的时间为t2，则在数据包x被应答时采集的即时速率为：

　　Rate=(从x被发出到x被应答之间一共ACK以及SACK了多少个数据包)/(t2-t1)

　　但是这会造成什么问题呢？这会造成误差。如下图所示：

　　BBR如果依赖这种即时的速率测量机制来运作的话，在ACK丢失或者延迟ACK的情况下会造成测量值偏高。举一个简单的例子：

　　那么，BBR是如何做到不引入这种误差从而精确测量即时速率的呢？很简单，将t1改成至数据包x发出时为止，最后一个(S)ACK收到的时间即可。

　　详情请参考内核源码的net/ipv4/tcp_rate.c文件，原理非常简单。

　　所以说，BBR的速率测量值并不受延迟ACK，ACK丢失的影响，其测量方法是妥当的。之所以上面给出一个错误的方法，是想展示一下什么样的做法是不妥当的，以及容易引起质疑的点在哪里。

　　结论很明确，延迟ACK，ACK丢失，并不影响BBR速率的采集值。

　　接下来谈第二个问题，关于BBR的拥塞窗口大小的问题。

　　2. 为什么BBR要把计算出来的BDP乘以2作为拥塞窗口值？

　　这个问题可以换一种问法，即BBR的bbr_cwnd_gain值如何解释：