如果BBR发现连续两个delivered周期(类似RTT，但是在拥塞或者被监管情形下，RTT会变化)内，TCP连接内满足两点，其一是吞吐速率恒定，其二是持有高丢包率，那说明什么？说明连接被中间设备限速或者流量整形了...除此之外，你还能想到发生了别的什么情况，如果你想到了，那你就可以自己做一个算法了。
我已经提示了，温州皮鞋老板们，搞起来！我有能力，但我不会去做，因为我对瞎子哲学嗤之以鼻！
TCP这部分的代码在哪里？请patch最新的BBR补丁，然后就可以探知究竟了。
现在是中午12点整，老婆出去上班了，丈母娘在厨房做饭，而我却在这里写这些乱七八糟的东西！CAO！我在玩火！我很想多说几句，但我不得不上代码了：
static void bbr_lt_bw_sampling(struct sock *sk, const struct rate_sample *rs)
{
...
...
我还是还是不想去分析源码。我在这里只讲逻辑。
TCP发送端如何检测到自己连接的流量受到了限速设备的流量监管呢？我仍以经典VJ拥塞模型图为例：
如图上所示，虽然由于发送端不断增加发送数据量或者别的连接增加了发送量，但是对于位置A而言，速率都是一定的，对于位置B而言，要么它是空的，要么它已经满了，这是TCP所察觉不到的！TCP唯一能做的是，按照反馈的ACK来进行发送速率的抉择！
这样的BBR可以避免第2类丢包，并且可以识别第1类丢包，但是对于第3类丢包无能为力，对于BBR而言，目前而言，第3类丢包的处理是最后要做的了。
BBR处理第三类丢包的手段，非常简单，仅仅是记录丢包本身即可。当发生以下情况时，BBR认为网络Path上有流量监管或者限速：
1.持续一段时间保持高丢包率；
当BBR检测到这种情况额时候，就不再用当前测量的带宽为计算Pacing Rate和cwnd的基准了，而是将这段时间内的平均测量带宽为基准！
这个检测在最开始！详细阅读bbr_lt_bw_sampling函数的代码，花上个十几分钟，就什么都懂了。BBR如此一来就相当于朴素地识别了流量监管设备的存在并且适配了它的速率！注意，这是一种朴素的算法，而不是什么可以让一群人噼里啪啦扯淡的算法！
靠这种long-term算法，BBR可以对抗监管设备的策略造成的丢包了。于此，BBR几乎可以检测到所有的丢包了：
1).如果收到重复ACK(重复ACK，SACKed数量，SACKed最高值...)，虽然TCP核心认为发生了丢包，但是不会进入PRR，BBR会不屑一顾，继续自己的策略，参见BBR引擎说明书；
2).如果真的发生了拥塞，BBR在最小RTT周期之后会发现这是真的，虽然滞后，但总比CUBIC之类滞后发现第二类缓存被填满强多了。BBR不会盲目降速，而是依然根据检测到的max-BW来，除非max-BW已经非常小！
3).如果发生监管丢包，BBR会在一段比较长的周期内检测到，它发现在这个周期内持续持有比较高的丢包率(检测到的Lost计数器偏大)，且速率保持一致，那么BBR会将发送量限制在实际带宽的平均值。
我一向对TCP是嗤之以鼻的，就像我对SSL/TLS协议嗤之以鼻一样，于工作，我持续七年先后与SSL，TCP打交道，并且有时候还做的不错，于私下，我呻吟着在诅咒中夹杂着叫骂，希望尽快结束这个丑行。每当我想到这些的时候，我甚至都有摔电脑的冲动，然而很多人会有疑问，我既然如此恶心这些，还为何分析它们，还为何如此上心...
我的求助开始了！
你有更好玩的东西吗？昨晚我看了将TLS offload到网卡的一个演讲，瞬间有了兴趣，可是我不可能去搞什么硬件，在后半夜又幸运的发现了一个KTLS的方案，我特别想今天把这个完成，然而作罢了，因为我没有时间！(我曾经不还吐槽过OpenSSL吗？是的，其实别人也有人吐槽，但人家改造了世界，实现额KTLS，而我，就是个傻逼！即便我是个傻逼，我也将OpenVPN移植到了内核，你呢？！)