CUBIC拥塞控制算法是天生干坏事的吗

这是一篇没有意义的即兴随笔，不长也不必推敲。
        最近经常有人问我BBR算法和CUBIC竞争的话是不是有劣势。我的回答是不一定。这倒不是说我在维护CUBIC所宣称的”公平性“(CUBIC将公平性作为一个特性来为自己拉票)，相反，我倒认为CUBIC所谓的公平性是名不副实的。基于丢包的算法，能公平到哪儿？唯一公平的特征无非就是出来混，早晚要还的。
        CUBIC比BBR看起来更加激进的地方在于，它会拼命地填塞网络路径上的一切缓存，然而这种行为的结局就是激进地试图清空缓存，标准算法是将窗口降为丢包窗口的0.7。BBR正是利用这个时机发送数据的！我一再强调CUBIC是依靠庞氏骗局来向前推进的。CUBIC的行为我们可以简单理解为罪与罚。
        我们知道，一旦数据包排队就会造成”带宽不再增长“，BBR算法天生避免排队，但是它并不能阻止CUBIC算法制造排队！如果CUBIC制造了排队，对BBR的影响就是它的带宽不会增加，反而会减小。但这不会持续太久，因为CUBIC在丢包后会降速，这个降速比例是符合公平性原则的，BBR可以利用这个时机。但是问题是，如果这个时机被另一个CUBIC连接利用了怎么办？！答案异常明显，BBR被完爆超秒！
        还在迷信BBR吗？一个使用CUBIC的MPTCP绝对完爆BBR！我从来都不认为BBR是基于时延的拥塞控制算法，但这并不意味着它们的思想不同，我一直认为BBR对比Vegas，只是灵敏度低了！
        有时候，迟钝反而是好事，难道不是吗？Vegas主动监控RTT的变化并且主动降速，而BBR则更像是被动的降速，它会在一个比较长的周期内试图采集更小的RTT，否则当这种奢望得不到满足时才会降速，BBR并不基于时延，而是利用了时延！事实上，Vegas算法如果内置一个状态机，彻底抛弃掉ssthresh那一套的话，也将是一个不错的算法。相对CUBIC，Vegas的劣势在于其对RTT有负面反应，并且在侦测掉丢包时，Vegas的重传逻辑也和CUBIC一样被接管，我想这正是BBR完全重构TCP拥塞控制框架的理由吧。BBR的min_rtt_win_sec参数影响了其对RTT的敏感性，长者都说过，要遵循的古训是：闷声发大财。所以该参数的值对于地球上的网络而言，也非常大，默认10秒钟。我们按折损光速200000km/s算，10秒钟一个数据包可以跑2000000km。请注意min_rtt_win_sec的单位，它是秒！也就是说，最灵敏的感应周期也是1秒钟！
        和Vegas不同，CUBIC算法的生命周期内，永远的话题就是罪与罚。CUBIC发得快，把数据排在队列里，这对它有好处吗？没有！丝毫没有。但是它可能会弥补自己由于填满缓存造成丢包后降窗的后果，毕竟一些数据包会留在缓存。这种”不正确“的带宽利用方式恰好让CUBIC利用了带宽，罪与罚的纠缠非常和谐！在CUBIC的框架内，多个同样使用CUBIC算法的连接其罪与罚配合的相当公平，收敛性非常不错，当世界上绝大多数服务器都在使用CUBIC之后，公平性问题似乎不再是个问题了。这也许就是Linux将CUBIC作为默认拥塞控制算法的动力源泉吧。
        世界上绝大多数服务器运行Linux，而Linux又配备了默认的CUBIC算法，NICE！如果我们把互联网看成是一片森林，那么每一条TCP连接理想中的可用带宽就是一棵棵树。CUBIC算法算出的实际带宽则是缠绕每一棵树向上攀爬的藤条，当树变粗时，藤条会舒张，当树变细时，藤条会紧缩，你能想象在森林中看到如此壮丽的场景吗？嗯，这就是CUBIC！我来形而上的回答题目的问题。
        CUBIC是出来干坏事的吗？是的，当CUBIC们在一起的时候，它们干了一件十足的坏事，藤条缠绕树干，遮天蔽日！然而，它们彼此之间却是公平谦让，内在理解罪与罚，温和对待彼此。
---------------------------------
我在深圳，当前气温12摄氏度，我短衣短裤，我说过我从短裤到穿长裤的气温阈值是8摄氏度...这已经到达了中国的最南边(别拿曾母暗沙来较真儿)了，为什么还是有大量异样的眼光盯着我的个性！我记得在上海大家都穿羽绒服了我还短袖短裤，认识我的人说我装逼(包括我的家人)，不认识我的人说我傻逼，啥也不说直接拉我冒着凛冽寒风路边喝酒抽烟的，那是兄弟！我终于知道了什么叫”冷“，冷的真实含义是”别人觉得你冷“！我为了把”冷“这个字彻底排除不知废了多少力！我只能说，北方人太多了，北方人的泛滥，造就了对冷的敏感！而我，则是北方人的叛徒！