网站排名忽然不见了,阿里企业邮箱登录,手机网站开发 html5,ip钓鱼网站在线生成研发端到端协议不是出路#xff0c;研发更智能调度流量的交换机不是出路#xff0c;将流量按长短突发模式分流到不同链路(逻辑的或物理的)才是出路。所有高速传输的前提是标准化#xff0c;统一简单的操作。多么简单的领悟。 数据中心网络具有范围小#xff0c;带宽大… 研发端到端协议不是出路研发更智能调度流量的交换机不是出路将流量按长短突发模式分流到不同链路(逻辑的或物理的)才是出路。所有高速传输的前提是标准化统一简单的操作。多么简单的领悟。 数据中心网络具有范围小带宽大全局可控等特点人们揪着这些特点设计出一系列与广域网 tcp 不同(大约还可以相悖)的端到端协议。
套路也有大概就是瞄准两个点在端侧用硬件卸载掉 cpu 的处理在网侧自研交换机支持新协议为端到端处理提供更详细的信息。这些都是正确的思路肉眼可见的 aws srdgoogle falconalibaba int-based-hpcc 以及 uec transporthoma都如此。具体来讲
支持更细粒度更准确的时间测量例如 swift支持多路径喷洒乱序传输支持 sack/nack 丢包检测以及快速重传支持成熟的拥塞控制算法(aimd or bbr or …)支持路径发现和切换(很重要但不一定有)软硬件结合…
名词我就不罗列了随便看一个协议基本就大差不差。
我一直秉持的观点之一靠上述端网这两个方向的算法相关的设计优化只能提高资源利用率而不能提升绝对性能绝对的性能提升是靠资源的量堆出来的。
简单扩容比好算法更有效且扩容花的钱比招聘人员自研更省钱省心不惹麻烦。老板总想少花钱做大事但没有免费的午餐雇经理的成本比扩容成本大的多。
但光把路修宽还不够还要限制不能谁都能上路。
我一直秉持的观点之二但凡高速运输都要将流量分别分流到专有通道而不是混部。专有通道的流量一定要同质而不能不同质流量混部。
只要流量不同质转发设备就要做更多 “判断”“区分”“针对” 等操作算法成本的本质是时间看得见的是能耗花钱买时延只有同质流量才能简单粗暴用一套简单规则对待协议头简化带来了算法的简化省钱省时间。
高铁之所以叫高铁是因为路而不是车早期的动车组跑在普速铁路上就像如今一个个自以为是的协议和 tcp 混部在以太网上一样。后来专门修建了独立于普速线路的高铁网350km/h 的速度才有了可能否则任由再好的调度算法要么对普速列车不公平要么高铁列车被掣肘。
高速公路也一样和红绿灯控制的行人自行车机动车混部的普通道路相比高速公路上只有特定的机动车可以上路且必须保持一定的速度不能随意停车。
在全局可控的数据中心将流量按照流模式分类导入不同的足够隔离的链路即使全部用以太网承载 tcp 都会在性能上获得质的提升甚至不需要新的协议和算法更无须对应用进行任何修改。
如果 incast 短突发流量和普通 tcp 长流(不仅限于 tcp)混部问题在本质上不是 incast 的问题针对 incast 再怎么的优化都无济于事问题出在长 tcp因为长 tcp 的 capacity- searching 属性摘不掉长流和突发流并不相容混部它们就是给自己找更多的事。
常规解决方案按前文所述无非再设计一个端到端协议然后在交换机上给予支持更复杂的 qos更复杂的队列 … 事情越来越复杂。
反过来长 tcp 也经常被 incast 短突发挤一下再挤一下而丢包这些突发转瞬即逝sender 无法区分且来不及反应误判的代价往往倒逼经理把更多的资源投入到算法的研发但并不有效。
好比一线城市核心区的老式红绿灯路口汽车抱怨行人自行车闯红灯行人抱怨自行车乱窜自行车抱怨汽车不礼让谁也过不去交通事故频发各种法律法规及调度都无济于事如何解决造行人自行车不让上的立交桥就行了同时汽车也不能走人行道。推荐一篇九年义务教育的课文《北京立交桥》都应该学过 分流才是出路。不分流即使上 ib 也很难。
incast 短突发流量只有 sender/receiver 最了解长短 tcp 也没有谁比 sender/receiver 更懂它们有足够的信息将自己导入不同链路。短突发不需要大带宽但需要更小收敛比而长流需要公平共享大带宽如果一个网络确保都是长流交换机自然有能力执行 总带宽 / n 调度算法而 n 可通过协议头携带的数据总量或千字节持续时间计算出。
长短流分流到不同链路(逻辑的或物理的)后固定 buffer 可以吸收更大的 incast 突发同时在长流链路甚至只运行 red aimd 就行。至于分流到固定的分离链路这件事应用自己比谁都做得好有个简单的例子可印证edt(earliest departure time) 由应用自己打戳就节省了底层很多资源同时消除了抖动。
只要分流从应用视角看它无需任何修改升级从网卡硬件和交换机视角看它们更简单(粗暴)而不是更复杂了。
然而我并没有看到有人往这个方向走人们在 “造车” 而无意于 “修高速公路”现在的数据中心无异于用上一代基建跑这一代(AI)的流量拿单体服务时代的基建支撑微服务在人车涌动的十字街头推搡着人群调度超跑。
在相似的其它领域人们十分清楚人车分流散货零担和集装箱分流只有这样才可用标准且简单的方式统一操作。试想如果散货和集装箱混在一起装船会怎样无论从分拣难度还是浪费的人力的角度都是噩梦。
船还是那条船可对码头要求更高了。要注意复杂和精巧并不意味着好。小路更复杂更富有技巧性可大路才高效。
从 cpu 乱序执行的原理也可见一斑cpu 最怕执行 if 判断涉及 if 就要预判涉及预判就有概率误判而误判的代价很大因此才有了人为偏向注入比如 likelyunlikely。但如果事先确认逻辑规格的一致性不需要 if 判断也就没有这种代价了效率自然就提升了。
我从不把做网卡的人等同于做网络的其实这些人做的事情跟网络关系也并不大。
然而从人的一方面看做复杂的事意味着更多的工作岗位高速公路取消省际收费结算后出行更高效了但收费站员工失业了。哪天要是真的数据中心流量分流了怕是要裁员不少了所以内卷也并不总是坏事干就完了。 周末跟博士聊天说到这个话题就简单发个随笔。博士认为这个思路完全是 infra 侧的事与业务无关但我觉得应用可以倒逼 infra给足时间这些五花八门的协议也解决不了问题的时候人们就跳出 “单纯仅仅的互联网技术圈子” 的思维定势要求 infra 必须做出改变了。你自己开车宁可去高速上堵着也不走国道为什么不为数据修建一条高速公路呢为什么高速公路好不仅因为它大部分时间更快还因为走它会更轻松。 浙江温州皮鞋湿下雨进水不会胖。
