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摄氏度...这已经到达了中国的最南边(别拿曾母暗沙来较真儿)了,为什么还是有大量异样的眼光盯着我的个性!我记得在上海大家都穿羽绒服了我还短袖短裤,认识我的人说我装逼(包括我的家人),不认识我的人说我傻逼,啥也不说直接拉我冒着凛冽寒风路边喝酒抽烟的,那是兄弟!我终于知道了什么叫”冷“,冷的真实含义是”别人觉得你冷“!我为了把”冷“这个字彻底排除不知废了多少力!我只能说,北方人太多了,北方人的泛滥,造就了对冷的敏感!而我,则是北方人的叛徒!

你可能感兴趣的:(CUBIC拥塞控制算法是天生干坏事的吗)