本文主要是介绍鉴赏 tcp vegas，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
优秀的 vegas 之后，再鉴赏一下迄今唯一像那么回事的拥塞控制算法 vegas。
从下图可看出所有的(对，所有的) aimd 都毫无伸缩性(z:吞吐，x:rtt，y:丢包率，由 buffer_size 直接决定)：
一下就可看出 rtt 和 buffer 主宰了效率，所有的 aimd 定制算法都在调节 alpha 拧巴这两者，比如照顾大 rtt 或浅 buffer，本质上就是在调整 ai 和 md 的系数，最终调整 alpha 展开成别的算法，cubic，scalable，htcp 等无不如此。
aimd 是个非常公平的控制算法，但它对于拥塞控制确实也只是公平收敛的意义，它甚至不控制拥塞，相反，对于大多数 aimd 实例，比如 reno，cubic，它控制拥塞的手段是制造拥塞。
vegas 直接控制拥塞，而不搞别的那些复杂玩意儿。vegas 监控两个变量：
- expected = delivered / basertt，以全局最小 basertt 追踪，它表示无拥塞吞吐。
- actual = delivered / lastrtt，实测吞吐。
expected - actual 自然就是实测吞吐和期望吞吐的差异，拥塞控制的目标就是追平这个差异，不同的追平方案就是不同的拥塞控制算法。vegas 的方法既有效又巧妙。
vegas 定义 diff = (expected - actual) * basertt，很显然，它的意思是实际和预期的报文数量。如果实际和预期有差异，多出来的报文一定在 buffer 中，巧妙之处在于：
- diff < beta 避免了拥塞。
- diff > alpha 兼备了探测。
- alpha，beta 只和 basertt 和 lastrtt 比例有关，公平收敛。
观察 diff < beta，其中 diff 具有全局意义，vegas 巧妙地将全局的 queuing 时间转换成单独流 actual 的下降，而 actual 下降本就由全局拥塞导致。
actual 下降由两种原因导致，自己造成或它者造成，要么由于自己 cwnd 冲高导致 expected 过高而显得 actual 相对下降，这种情况下 cwnd 需要降低，要么由于有其它流量侵入导致带宽被分享，这种情况下 cwnd 降低体现收敛，无论哪种情况都避免了拥塞。
diff 计算出来的是全局的 buffer 占率，而不是单独一条流的，vegas 所有计算都在全局意义上进行：
所以，vegas 的公平收敛非常完美：
再看 diff > alpha，它确保 buffer 中始终有一些报文以及时感知带宽变化。bbr 操作点选在 rtt，带宽正交点实际上是个错误，完全清空 buffer，如果有流量退出，bbr 不得不采用定时 probe 的方式发现新带宽，而 vegas 则能自动发现。alpha 越大，其探测性越强，但代价是 queuing 时间，这正解释了 bbr 论文中 rtt 和带宽的正交性导致的测不准原理。
干嘛不松弛一下，索性利用这个测不准呢。
有趣的是，vegas 没被推广正是因为 “不公平”，vegas 面对 aimd 流排队会不断退让。然而除了实验室数据理论分析，没有任何成规模的现网数据佐证它。全局统计意义上，只要 aimd 流足够多(足够异步)，虽然每一条流都经历锯齿起伏，但整体队列长度是稳定的，这意味着 vegas 调整好 alpha，beta 以适配这个队列，结果就 ok，因为不存在不断增加的队列。
最后谈一下实现。linux kernel 的 tcp vegas 其实是个瘸子，它没有实现精准测量，相反，它采用了 2.6 内核粗糙的计数方法。任何 delay-based 算法正确实现方式都该使用 net/ipv4/tcp_rate.c 里 rs->delivered 与 rs->interval_us 做除法才算数，而不是直接 cwnd / srtt。此外，linux tcp 也没有实现 vegas 独特的时间序重传算法以及慢启动算法，这种重传算法和 bbr 依赖的 rack，pacing control 几乎一致了，缺失的本质原因在于 linux 内置了 loss-based cc 状态机，非常难改。
为什么写这个文章重复讲一个不被看好的 vegas，毕竟以前写过好多次 vegas 了。因为我看到 windows 竟然支持 bbr 了，有个评论提到了 vegas 是好的：
我也是这么认为的，所以难免想单独再多说几句，就写了本文。
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于鉴赏 tcp vegas的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
