为网站做外链的方式,做自媒体有哪些网站,一个ip做几个网站,建商城网站多少钱这不是技术文档#xff0c;这是技术以外的文档。
带宽资源越来越丰富时#xff0c;大家反而不抢了#xff0c;资源越稀缺争抢越厉害#xff0c;相比丰盈的带宽#xff0c;如今人们更关注时延。l4s 提供了完全不同的方案。但梳理一下传统方法是必要的。
30 多年来#x…这不是技术文档这是技术以外的文档。
带宽资源越来越丰富时大家反而不抢了资源越稀缺争抢越厉害相比丰盈的带宽如今人们更关注时延。l4s 提供了完全不同的方案。但梳理一下传统方法是必要的。
30 多年来人们将拥塞控制算法简单划分为 loss-based 和 delay-based前者比如 renocubic后者比如 vegas无论哪一类都是以时延为代价控制拥塞丢包作为拥塞信号时重传时延是必须的代价时延增加作为拥塞信号时它本身就增加了时延这种传统路子无论怎么折腾无异于原地绕圈圈。
有个有趣的地方很多人都忽略了vegas 自始至终从没有自称 delay-based但将 diff expected - actual 视为时延增加导致将其归为 delay-based 就显得粗鲁。
如果 vegas 自身会导致时延增加那一定因为它在不停增加 cwnd or pacing_rate直到获得一个时延增加信号然而 vegas 并没有主动增加 cwnd它做的一切都在被动适应理论上时延增加一定是有新流进入这是个指示当前所有流量出让部分带宽的信号新流即使没有任何 probe 行为(实际上还有慢启动)其它流出让的带宽也能被新流自然获取反之时延减少则是有流退出需要均分它出让的带宽的信号。
vegas 采用与时延无关的方式对资源进行自适应天然避免拥塞。vegas 只是用时延计算带宽而起作用的是作为一个 “力矩” 的带宽时延乘积它消去了参与计算的时延变量是个表示实际拥塞作用效果(拥塞就要用 bdp 衡量)的量可参考 vegas 的力学解释。
loss-based cc 固有的锯齿使针对它们的优化方案均旨在减小锯齿从而获得带宽利用率的提升而 vegas 理论上是无锯齿的。
如果网络是理想的vegas 肯定是一个可伸缩的公平的低时延算法但网络不是理想的因此 vegas 只能维持脆弱的不稳定平衡而 aimd 则是稳定的平衡。不稳定平衡一旦偏离平衡点正反馈将是灾难性的这是它无法实用的根本。
l4s (的思想而非细节)为部署 vegas 带来了希望。
正如 aimd 需要类似 red aqm 提供支撑一样(否则将会跌入低效的全局同步)vegas 为什么不能由另一个 aqm 支撑呢只要利用 l4s 设施将传统流量隔离到单独的队列甚至不需要它提供的 ecn 能力vegas 自己就能适应。
l4s 的意义在于它为网络注入了真正的拥塞控制能力它显式将拥塞信息第一时间直接通知到 sender这是与传统的 aimd 完全不同aimd 的 capacity-search 行为被认为是造成拥塞的原因而不是解决拥塞的方案它解决的只是拥塞崩溃。
虽然 l4s 与 aimd 的思路完全不同但 aimd 很容易被误解为拥塞控制的根基以至于试图摆脱它只能是昙花一现的徒劳参见 bbr 到 bbr3 的迭代。
基于 l4s 框架tcp prague(一帮经理在布拉格开 l4s 副经理大会提出了算法方案延续 tcp cc 按照地名的命名法则就叫 tcp prague算法细节看参考 Prague Congestion Control) 延续了 dctcp而后者也是一个 aimd 算法。
dctcp 本质上还是 capacity-search它自己倾向于占满带宽和 buffer其内核并不符合 l4s 的思想l4s aqm 不断发送 ecn 修正 sender 先污染后治理的行为与传统 red aqm 无大不同而 vegas “保持 alpha 到 beta 个报文在 buffer 中” 则完全贴合 l4s 可扩展低时延的理念无论多少流量在 buffer 中保持固定数量报文意味着时延不会随流量而变化这便是可扩展性而 l4s aqm 只需要确保在 buffer 中保持固定数量报文这件事的落地修正 sender 的误估。
如此 l4s 岂不是只提供了个浅 buffer。话虽如此但我们很容易想象一个 aimd 流在这个浅 buffer 中如何剧烈抖动然而 vegas 在这个浅 buffer 中倾向于平稳而无锯齿除非有流量进入或退出才会导致 vegas aiad而为了防止 aimd 流量频繁干扰 vegasl4s 还有一项任务就是将传统 aimd 流量(简单方法就是无 ecn capable但也可用算法)隔离出去这也是 l4s 框架的核心工作之一。
如果只提供一个截止闸一套严酷的律法来治理环境污染这种先污染后治理的方案显然不能真正治理污染而将每家企业的碳排放维持在一个区间这才是好的方案。惯常的 tcp 锯齿就是先污染后治理的形态而 red aqm 钝化了这类锯齿这是一种优化手段但丢包仍是信号。而 l4s 既然可以提供显式信号就取消了 aimd 的必要。剩下的公平性问题只要大家遵守同一个规则就能保证公平性类似上周我对 vegas 的分析那样而 l4s 可确保这个规则得到遵守。
理想的端到端传输没有任何网络力量干预aimd 在避免拥塞崩溃后通过 red aqm 提供了优化这算是一种来自网络对端的干预此后很难再看见网络甚至会丢掉携带 ecn 的报文人们笃信一定存在一种最优的端到端算法于是人们拼命寻找它然而信息量有限是个固有缺陷该缺陷限定了端到端算法的上限任何算法都在带宽和时延之间拧巴vegas 稍好一点。突破极限还得需要网络提供更多信息将 dcn 用了很久的 ecn 思路照搬到广域网就是 l4s它在长程传输中的作用力比 dcn 短程传输更大。
作为从 dcn 衍生的广域网 dctcp 版本 tcp prague 仅仅是个开始vegas 固然不完备但 dctcp 也并非真正的可伸缩依然依赖启发式算法和处理技巧推动优化在某个点上它将不再可伸缩。但在数据中心内部dctcp 本身可以做得更好与 l4s 等效的 dcn 技术不胜枚举。 如果只是想了解一下 l4s请看Reduce network delays with L4S如果要深入了解它就看 rfc9330。
最后不得不说网络干预端实属一把不对称的双刃剑在 dcn 实施的方案在广域网却不一定可行因为在不受控的分布式环境兼容性要考虑的更多这也是最初把互联网设计成细腰型瘦网胖端模型的原因。拥塞崩溃固然可怕它由指数传输量导致但对网络设施本身牵一发而动全身的改造也是指数效应更要慎重。
浙江温州皮鞋湿下雨进水不会胖。
