客机坠毁始终是种灾难，理论上至少存在 100 种不让客机坠毁的方案，其中之一是携带一个巨大的降落伞(合计展开面积 6000 平米)，该方案涉及包括材料学，力学等，用最轻的材料做展开面积最大的降落伞，当客机要坠毁时，展开此降落伞，考虑到展开效率，降落伞还可以设计成分层冗余式。

这类方案始终没有实施的原因也不难理解，从成本收益考虑，空难概率低，万一发生，保险赔付遇难者及其名牌西装皮鞋等贵重行李的成本远低于每架飞机都携带一个巨型降落伞的成本。

问题是，空难概率高到什么程度才能让这类方案变得可行呢？假设空难概率提高 4 倍，再兜售这类方案会不会有市场呢？

答案是，如果空难概率提高 4 倍，工程师们会花大精力寻找空难如此容易发生的根因，并改进飞机的安全性能，让空难概率降低到保险赔付可以容忍的程度。换句话说，类似超大降落伞这类超酷的的方案在任何情况下都不会有市场。

让灾难尽量不发生，而不是引入复杂机制减灭灾难的影响。

在工程上，每引入一种新机制自然要考虑这种机制失效后怎么办的兜底，这是个递归的过程，系统的复杂度会指数级上升，而复杂度和故障率正相关。因此，要把到复杂度简化并用在 “正常路径” 而不是为 “异常路径” 增加复杂度，要控制进入异常路径的概率，使其低到一定程度。当异常路径占比超过一定比例时，它们的开销将导致系统是不划算的。

tcp/ip 在 1980 年代遭遇网络拥塞崩溃时，仅仅引入 aimd 就解决了问题。aimd 的核心不是性能，更不是对丢包的善后，而是能让网络收敛到一个可用且稳定的状态，这典型地在处理 “正常路径” 。loss-based cc 仅将丢包作为触发行为的信号，而重传则是 tcp 的语义，更与 aimd 无关。而 gbn，sack，pfc 都是 “异常路径”。

后面的事花开两朵，各表一枝，aimd 引领的拥塞控制以及重传等算法在广域网和数据中心都被玩开了花，结果也是被爆菊，散落一地，可谓菊花残，满地伤，花落人断肠。

广域网的事是彻底端到端的，他们将 aiad，miad 和 fec 重传说成优化，把拥塞控制的目的误解为性能，能偷偷多发一个报文就多发一个。没人说得清 bbr 到底哪里有问题却都能改上一改。

有趣的是，广域网的手段在数据中心反而行不通，因为业务 a 的人这么做了，业务 b，业务 c 的人会一起屌他。广域网是黑暗森林，数据中心玩的是均势。

但数据中心玩的更花，因为他们能动网卡和交换机。网卡实现 sack 太复杂，交换机 pfc 自然接力，但为什么看不上 gbn，因为 gbn 重传效率太低。看到了吧，他们把丢包当成了司空见惯，自然要花大力气去做丢包重传咯。丢包重传是典型 “异常路径”，如果丢包很少发生，gbn 当然就足够，简单才性能高。sack，pfc，int-based cc 这些就是客机上的降落伞，而 gbn 是保险公司。

你不去思考如何减少丢包，偏偏要在丢包了如何感知和重传上炫技。

顺着 “正常路径” 继续思考丢包怎么减少。丢包无非两类，误码丢包，溢出丢包(如 td，red)，减少误码就提高硬件可靠性，减少溢出就控制突发。是不是很合理，但这里很容易进入另一个犄角旮旯，提高硬件可靠性就要保证 100% 可靠，减少溢出就要严禁溢出，于是大量的复杂机制被引入以保证不丢包，pfc 就合理了，看，绕了一圈又回到了 pfc，瞧， pfc 就是万金油。 其实这是从一个死胡同倒回，经过了出口却错过，进入另一个死胡同。

“提高” 和 “减少” 这些词暗含一个 “阈值”，即提高和减少到什么程度就刚刚够，再多做就拐回去了。比方说把溢出丢包的概率减少了 0.0005 以下就够了，为此之下的小概率事件做任何事都不划算，但它要真发生了，“保险公司赔钱” 就是了。引入复杂机制做小概率事件和引入复杂机制做 “异常路径” 都没意识到少就是多，过犹不及。

按正确思路，如何 “提高” 和 “减少” 到阈值简直显而易见。简单点说，用更贵的名牌设备，拉专线就 ok 了。这一点上无论广域网还是数据中心的方案就殊途同归了。

如果摩尔定律依然如故，核心带宽依然可不断翻番，就要不断扩展带宽。在带宽一定的约束下，最直接简单的优化方案是将网络划为一条条物理的或虚拟的通道，每类业务流量进入特定通道。

网络切片，infiniband virtual lane 都属此类，但以太网交换机的包分类和 qos 队列不是。前文说过，将数据包映射进通道，基于通道做控制，而不是分类每个数据包，对数据包做控制，显然前者更简单，ib 报头上就有 vl 号，交换机看一眼就好，以太头，ip 头上有啥(目前 roce 也在引入 ib 的良好特性，这一次以太网有希望再次依靠其生态取胜)，还指着元组 hash 吗，一个协议头加个字段看一眼就能搞定的事，拿 hash 算法炫技。

至于如何控制突发，pacing 是摩尔定律进展的大势所趋，前面的系列文章已经说过，不再赘述。 sender 测一下 delivery rate 简单算个 pacing，交换机 buffer 能省很多，加上同质流量映射到独立控制的通道，交换机复杂度也降低。更简单了，性能才能更高。

这几天跟一些朋友聊这个话题，大家普遍 concern 的点是 “将数据包映射进通道还是要包分类”，“业务自己又不知道自己是什么流量类型”。再次，参考高速公路的例子，自己是个行人还是自行车，轿车，卡车，自己不清楚吗，只要开进去了，还要分什么类。

为此，一种简单粗暴的方案是在业务部署上线前就确定通道类型，网络侧基于该业务流量类型(比如突发型，短 rpc，大象流)定制通道 qos，开发的时候把通道号硬编码到报文。但显然这很不技术，程序员普遍认可用算法来自适应，而不是靠需求和沟通。这个问题不多说了。

虽然数据中心不是互联网，但它们在性能提升的手段上殊途同归，我说数据中心更像主板的扩展，看一下 pcie 就有好处，看看 pcie 如何做消息交换的，再看看 pcie 的通道如何划分怎么使用的。

要全局看问题，要了解一点历史。否则很容易拿着锤子找钉子。

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