云数据中心传输的出路

研发端到端协议不是出路，研发更智能调度流量的交换机不是出路，将流量按长短突发模式分流到不同链路(逻辑的或物理的)才是出路。所有高速传输的前提是标准化，统一简单的操作。多么简单的领悟。

数据中心网络具有范围小，带宽大，全局可控等特点，人们揪着这些特点设计出一系列与广域网 tcp 不同(大约还可以相悖)的端到端协议。

套路也有，大概就是瞄准两个点：在端侧，用硬件卸载掉 cpu 的处理，在网侧，自研交换机支持新协议，为端到端处理提供更详细的信息。这些都是正确的思路，肉眼可见的 aws srd，google falcon，alibaba int-based-hpcc 以及 uec transport，homa，都如此。具体来讲：

• 支持更细粒度更准确的时间测量，例如 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 就要预判，涉及预判就有概率误判，而误判的代价很大，因此才有了人为偏向注入，比如 likely，unlikely。但如果事先确认逻辑规格的一致性不需要 if 判断，也就没有这种代价了，效率自然就提升了。

我从不把做网卡的人等同于做网络的，其实这些人做的事情跟网络关系也并不大。

然而从人的一方面看，做复杂的事意味着更多的工作岗位，高速公路取消省际收费结算后出行更高效了，但收费站员工失业了。哪天要是真的数据中心流量分流了，怕是要裁员不少了，所以内卷也并不总是坏事，干就完了。

周末跟博士聊天，说到这个话题就简单发个随笔。博士认为这个思路完全是 infra 侧的事，与业务无关，但我觉得应用可以倒逼 infra，给足时间，这些五花八门的协议也解决不了问题的时候，人们就跳出 “单纯仅仅的互联网技术圈子” 的思维定势要求 infra 必须做出改变了。你自己开车宁可去高速上堵着也不走国道，为什么不为数据修建一条高速公路呢？为什么高速公路好，不仅因为它大部分时间更快，还因为走它会更轻松。

浙江温州皮鞋湿，下雨进水不会胖。