本文主要是介绍tcp inflight 守恒算法的自动收敛，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
inflight 守恒算法看起来只描述理想情况，现实很难满足，是这样吗？
从 reno 到 bbr，无论哪个算法都在描述理想情况，以 reno 和 bbr 两个极端为例，它们分别描述两种理想管道，reno 将 buffer 从恰好的 0 塞到满而保持对带宽 100% 利用，而 bbr 则通过寻求维持在 buffer 恰好为 0 的状态保持对带宽 100% 的利用，它们分别是范雅各布森管道和 bbr 管道。
它们从一开始的注意力就没有集中在多流共享 buffer 的拉扯场景，都试图在算法中附加公平，或者在算法外补充公平性，从范雅各布森管道的原始论文以及 bbr 原始论文中都找不到最初的公平性约束。而 inflight 守恒算法的公平性是内置的，如果不存在一条以上的流，算法甚至可以缩短到两行代码以内，因为 E = bw / srtt，当然 buffer 为 0，E 最大，这个单流效果和复杂到爆的 bbr 竟然一致。
一旦涉及多流，bbr 单流不排队约束就无能为力，而 reno 的公平性表现却好得多，但还是主动公平，这显然是拉扯的结果，我们需要一种自动的公平，in-flight 守恒算法显然就做得到。
多流情况下，从收敛图上看，本质上需要两种力量，一种力量将收敛点拉向 fair–line，一种力量将收敛点拉向原点。
先分别看下在 reno 和 bbr 中这两种力量是什么。
- reno 拉向 fair-line 的力量：随时间流逝，两条流在 buffer 中的报文总量趋向接近，bw 按 buffer 占比分配；
- reno 拉向原点的力量：流属 sender 检测到丢包后主动 multiplicative decrease；
- bbr 拉向 fair-line 的力量：一方面 bw 小的流 probebw 加速比更大，另一方面 bw 大的流 probertt 减速比更大；
- bbr 拉向原点的力量：probe 阶段后立即主动 drain 掉无效 inflight。
可见，都需要算法主动去做点什么才能产生这两种力量驱动算法收敛，既然主动去做就要有触发点作为依据，reno 依靠丢包事件，bbr 则依赖内置状态机，无论哪一种触发点都存在客观干扰，这些干扰作为信息不准的反作用力驱动收敛点偏离 fair-line 靠近原点的位置，效果即 reno 总在 fair-line 上做长程震荡(tcp 锯齿)，bbr 则在 fair-line 一侧的小范围做无规则震荡。
inflight 守恒算法法则 2，进时适可而止，天然考虑他者，退时什么也不做，意味着一旦越过 fair-line，算法将失去动力进入滑翔状态，此时两条流均 “记住” 了自己的最佳 E，以此维持 inflight 守恒，并用余量中的负反馈抵消波动，余量作为阻尼器起作用。
以下图总结上面的话：
避开 bbr，说说 aimd-reno 和 inflight 守恒算法之比较。
如果用排队论经典的 queuing_delay-load 坐标曲线解释，aimd 顶着 buffer 彻底用，曲线下凸，而 inflight 守恒算法收着用，曲线上凸而向下闭合。
理论上 buff 无限假设，aimd 时延无限，现实中固定 buff，一直丢就要一直重传一直丢，只是用无穷大重传时延替代了无穷大排队时延，因此这种顶着用的策略必须执行 decrease，而 aimd 已经被控制论证明公平的。
而 inflight 守恒算法则假定固定大小 buffer，比如 30MB，然后考虑如何集约化尽可能少地使用这 30MB buffer，所谓集约化就是收着力的意思，并形成以下共识，寻找 30BM buffer 内最佳收益的占比，而不是寻求最大带宽，因此剩下的 buffer 则留给别人达到同样的目标。
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于tcp inflight 守恒算法的自动收敛的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
