米定制网的网站是那个公司做,北京建设网站的,天眼查登录入口,手机网站网页设计拥塞控制面临的几类问题#xff1a;
网络拥塞时#xff0c;大象流如何为微突发让路#xff1b;网络拥塞时#xff0c;如何只惩罚造成拥塞的流量#xff1b;网络拥塞时#xff0c;如何确保小流量不受影响。
既然不想在 host 将流按照大小分类#xff0c;嫌没意义#…拥塞控制面临的几类问题
网络拥塞时大象流如何为微突发让路网络拥塞时如何只惩罚造成拥塞的流量网络拥塞时如何确保小流量不受影响。
既然不想在 host 将流按照大小分类嫌没意义麻烦或看不上那其实交换机一直在做这件事比如优先级队列加权公平队列加权随机早期检测等不管是物理交换机还是虚拟交换机这几样肯定跑不了。
但那些队列和调度策略往往配置复杂实现太重且无法自适应流量特征的变化。
codel 是个好东西fq_codel 更有点意思自适应携带负反馈环这个我喜欢。
linux 的 fq_codel 实现中在 enqueue 位置有个针对最长队列的 fq_codel_drop 操作只在队列满载时执行还是太粗糙。我后来在它基础上修改了一版改动如下
enqueue 队列长度超限后在所有长度大于某个预设值的足够 fat 的 flow 中分担删除报文flow 长度即分担权重(后面会提到一种预防重传风暴的情况特意在同一个队列丢包而不是分担)。
再后来我增加了 dequeue 逻辑就成了一个虚拟交换机的框架它的原理如下
在 dequeue 而不在 enqueue 做的理由如下
enqueue 由不同的 ingress 端口(物理 or 虚拟)执行执行复杂逻辑涉及 lock 过久问题enqueue 逻辑对大象流丢包会导致队列中的流长度反转误伤中等流量。dequeue 位置是个一致的并行 check 点。
另一个点在每一次 dequeue 报文时按概率删除报文追求的不仅仅是平滑另一种看起来更简单的方式反而会造成颠簸误伤良性流量与上述不在 enqueue 做此逻辑的理由 2 一样。简单分析一下 why
最后谈谈该 aqm 的算法细节。
这种自适应策略可以逐渐让各 hash list 长度趋向一致迫使各流量收敛到公平(如果端到端算法不主动收敛aqm 会迫使它们收敛)但如果所有 hash list 长度都快速增加且长度趋向一致那就是遇到 incast 了应尽力缓存而不是丢包因此应该夹带以下逻辑
以均匀方差做指标切换策略方差越大越趋向丢包方差越小越趋向缓存趋向缓存但 buffer 不足必须丢包时尽量在同一个队列丢防止重传 incast。
所以这一切能否自适应答案是肯定的。保存一个系数 a (max_len - min_len) * (mid_len - avg_len) * avg_len
丢包概率计算时乘以 a 即可hash 队列越畸变丢包率越高反之越平坦丢包率越低enqueue 逻辑的队列 limit 改为动态计算a 越小说明有 incast 微突发limit 就要越大limit 做成 a 的负相关函数即可limit 越大越倾向于在一个队列丢包计算每队列丢包数量是要乘以 a 的负相关函数a 越小每队列丢包数量越多。
简单数学函数的威力无穷。
浙江温州皮鞋湿下雨进水不会胖。
