数据中心网络不是互联网

在地铁上看了几篇朋友推荐的公众号卷文(无非推广自己的方案或者卖卡的那种)，呜呼天啊。

pfc 是大错特错，但英伟达也不全对，都没到点子上，都是兜售卖货卖关子自吹而已，我没指名道姓，我这也不检票，对答入座好了。

【pfc 纯属问题转移，且不光转移还蔓延，制造问题解决问题类型的方案，无论再高雅也不行，相反，pfc 只是个手段，你忘了目的，其实如果非要折腾，你只要做 link level 的 fec 就会好很多。如果一次把球投进却不要，偏偏要把球扔到半空中，然后再跳起来把球补推进去，这不是秀球吗】

受制于功耗，内存墙等因素，单片晶体管不能无限堆积，机架间互联传输必不可少，数据中心网络端到端时延从几十 ns 到几十甚至几百 us 不等，按 10us 记，抠 ns 级的计算时延真就是屎上雕花，真的大头在动辄上百 us 甚至越过 ms 级的排队时延，然卷客们将此交给对拥塞信号的响应，曰 “优秀的拥塞控制”，为此还引入复杂的硬件机制，曰 “更精确的测量”，想啥呢。

时延和抖动的根因是计算和排队，而计算时延在自己吹上天的硬件如果都不可控，你还卷个啥，剩下的就是排队时延，干掉它才是正道，但几乎没人答对如何干掉它。

钟爱的以太网是统计复用网假不假，统计复用网必有排队时延假不假，时延抖动受突发程度决定假不假，突发程度受流量类型同质性决定假不假，都不假吧，不假的话咋就不从源头上最小化排队时延呢，你非要等排队实际发生了，才秀出你的那些卷技，看我测量多精确，看我 pacing rate/cwnd 算得多准，你算的再准，时延已经发生了啊。

简单解释为啥 “突发程度受流量类型同质性决定”，主要看两点，一看排队时间占比，二看容忍时间。一列持续 10us 的突发，排队 10us，对它而言排队占比是 1，如果混入一列持续 1us 的突发，将引入对它而言 10 倍的排队占比，若要降低排队占比，只能加大突发持续时间，而这个时间由流量类型决定不可改变，便只能增加突发数量，结果会再拉高 10us 突发的排队占比，以此反复直到有流量退出，相异流量混部，总不能收敛到一致的排队占比。

换个方式解释，不同流量对排队的容忍程度不一致，任何对拥塞的响应都很容易让拥塞加剧。10us 的突发以为排队占比 1 很 ok，它无需任何措施，然而 1us 的突发则无法容忍 10 倍的排队占比，但它自己响应拥塞而收敛将对结果几无改变，因为它的分量太轻了，最终它的收敛行为将饿死自己而不是缓解拥塞。

时延抖动主要来自于不可预知的排队，而强烈的不可预知排队则源自于一大堆长的短的有的没的流都挤在了一起。

混部的各类流量实施拥塞控制只能让自己感动，很难控制拥塞，本质原因是各类流对拥塞的认知不一致。没有共识，企图在 us 甚至 ns 级时间响应拥塞，这能控制个 jb。

现在的几户所有解法都本末倒置，因果颠倒。所有解法几户全都指向丢包重传和折腾 buffer，却几乎全没认识到这些才是时延以及时延抖动的根源，真正保证低时延的手段恰恰是不丢包不重传，无 buffer。你秀个重传算法，再秀的重传也要时间，你怕丢包就加大 buffer，可大 buffer 就要大排队，然而你又在 buffer 和丢包重传之间权衡，无非就是把重传时间和排队时间互换，做这种互换免不了又要引入复杂的 amq 和端到端拥塞控制算法，运行算法也需要时间，于是又要折腾硬件，嫌 cpu 不行。看到了吧，这就是个怪圈，根源原来就是结果，不做就不会错，做减法才对。

我在 数据中心传输的出路 和 再谈数据中心传输 提到要将不同的流量按突发长度进行分流，也就是按流的长短进行分流，这才是真解法，它在除了计算网络领域以外的几乎所有领域都解决了大问题，但唯独在计算机网络领域却反其道而行之，纷纷秀自己 “探测并正确响应一切网络中问题” 的算法，网络都是 best effort，你让人家承诺啥。

分流不同突发长度流量可以解决问题的本质在于所有流对拥塞有共识，拥塞控制才可起作用。而不会出现短流觉得堵了，长流还在拼命怼呢，反之亦然。

人们一直恪守的胖端瘦网(smart edge dump core)信条对于数据中心而言压根就是个错误。需要区分的一个核心问题是 “数据中心是如何形成的”，到底是服务器拆分成的数据中心，还是互联网压缩成了数据中心。在我看来很明显是前者，如果没有各种散热，能耗，ha，解耦方法论，微服务等约束以及增长极限的限制，人们宁可将数据中心所有东西堆在一起，甚至希望将数据中心安装在一枚芯片上，这就和 “微内核 vs 大内核” 的争论一样。

数据中心的架构和互联网架构基本无关，它更像一个计算机主板架构的扩大版。

和 pcie，infiniband 等一样，基于通道做控制而不是基于数据包，因此将不同类数据包归入特定的通道而不是在交换机上分类数据包就是很自然的策略。数据中心更适合 pcie，ib 这种从事务层到物理层的承载，而不仅仅是以太网这种链路层(只是因为以太网更清洁，有更强的生态支撑)。

而互联网的原则则完全不同于主板或数据中心。

互联网核心要素是可扩展，易接入快速蔓延，兼容(详见 The Twelve Networking Truths)，tcp/ip 很完美完成了任务，对于底层链路却是沙漏模型的宽下摆，tcp/ip 使互联网在过去的 30 年飞速发展，适应各类终端接入。

而数据中心则是互联网的反面，扩展是从板卡到外设的，兼容性则只在保护投资。比如主机板卡的扩展，外设必须兼容卡口，而不是卡口在外设看起来易接入，数据中心没有病毒式扩展的欲望，相反数据中心追求能效比，反不希望规模太大。

哪怕对于拥塞控制，数据中心网络也更接近板卡总线而不是广域网，广域网拥塞处理时延(排队时间和响应时间)在端到端总时延占比很低，而数据中心网络的同时延占比相当高，所以必须用不同方式处理，确切来讲，拥塞避免优先于拥塞响应。

注意看 infiniband 的措施是如何解决低时延问题的(我并没有推销 ib 的意思，我也并不踩以太网)，ib 低时延的核心不是 cut-through，而是 virtual lane，在其协议头中直接就有指示 vl 的字段，而不用像 tcp/ip/以太网 那样用一些元组硬算，但凡硬算就有卷活了不是吗，发明一个新协议封装，再发明一个新算法，秀自己相对于五元组硬算提升了多少。

但 vl 对于广域网的端到端而言就没有意义，因为广域网传播时延过大，长距离大时间段遭遇的变数越大，端到端通道(无论虚拟的还是物理的)越容易好坏抵消，意义就抵消了；此外，无法为广域网流量规划特定的几种流量类型，这与互联网中立性原则相违背，互联网允许任何流量接入并通过，因此互联不认识且不能认识任何流量。

然而板卡上完全不需要中立性原则，谁考虑谁 sb。

数据中心网络和互联网是完全不同的东西，它是服务器主板的拓展，而不是互联网的小型化。当然，类似 ib vl 的这种分流确实也简化了交换机的设计，简化了转发数据面，但这只是无心插柳，并非刻意如此。分流是因，交换机简化是果。

再粗暴一点，有朋友在我前面的文章下回复 “拉专线啊”，嗯，是这个意思，有条件的话，为每一类业务拉一条专线，买交换机买光纤的钱比雇经理和卷客的钱便宜，运维还简单。

在核心本质的问题空间都搞错的情况下，再秀数据都不能说话。

有个有趣的点，问一个做数据中心传输的要注意什么，他会说要慎重甚至避免部署 bbr，如果问一个做广域网传输的要注意什么，他会说仅仅部署 bbr 还不够，还要把它改激进些。在数据中心，如果 a 抢了 b，b 会找 a 处理，必须要全局考虑，但在广域网，如果 a 不抢 b，就会被 b 抢，谁全局考虑谁 sb。

基于统计数据，互联网 buffer 排队时延就在 5ms 到 50ms 量级，再多就影响 qoe 了，再少会增加丢包重传，拥塞反噬。本质上这是人体感官容忍度决定的，但在数据中心微服务 rpc 环境，受众 qoe 容忍度指标却需要不同的度量。

所以，懂了吗？这是不同的领域。

我反思两点。

其一，我一直关注拥塞控制和传输加速，不管数据中心还是广域网，手里只有个锤子看什么都是钉子，我一直觉得数据中心拥塞控制的路子大错特错，但事实上会不会现有的这些铺天盖地的协议和算法已经解决了大部分问题，以至于即使在理论上它们确实存在这样那样的问题，但实际上甚至并没有严重到值得重视的地步呢。

其二，虽然 tcp/ip/以太网(亦可以单说以太网，tcp 纯背锅) 在原教旨意义上是个 best effort 网络，但实际上以太网亦不断吸收 ib 的先进特性不断在进步，roce 完全体已经足够好到让大家忘记以太网是那个从 csma/cd 进化而来的低效率但能用的以太网了。像以往的胜利一样，以太网以其最小假设的 afap(as fast as possible，tcp 类同) 特征稍微加入一些新特性就能再次打赢全场。

果真事情就是分流那么简单，那些卷材厂的卷客们还有啥好卷的呢，再次感谢这些卷念给了卷业而不至于失业，还能让一些有卷念的出去创业，让创业失败的小经理们还能卷几年卷活儿。其实，大道至简，疯狂的不止是卷客们的不得已，更多的是卷客们的执念。

The juaner who believed juanism had juaned himself to the juanable juanage or juanization itself.

我竟没法用现代汉语译它，但我能对应一段古文：卷之卷，卷者无他，是故，卷也。

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