网络规模与性能优化的一篇随笔

本周写篇轻松的话题，注意信息传输的尺度和缩放比例，写篇随笔。

控制面和数据面随规模缩放的影响，举几个例子就能说明白。

CSMA/CD，控制面和数据面在一起，控制信息交互时延和数据面时延在同一尺度时，就到了极限，因为控制交互时延相对数据面时延更大的话，便可以反过来用了，如果一个胖经理跑 100 步等于一个工人走 1 步，为什么不换个瘦经理或者让工人命令经理呢，因此它们趋向最多收敛到一致。控制面和数据面合而为一的另一个例子是 TCP，带内控制协议典范。

翻转时延分配的经典例子是非对称加密和对称加密，时延更大的 RSA 可用的理由是它更安全更方便解决对称密钥分发和认证问题，但更大的理由是这些需求相对于对称加密更不频繁，否则人们肯定会想办法组合对称加密算法来满足。

交换式以太网脱胎于总线是从 CSMA/CD 逐步将控制面抽离并将控制面信息交互时延不断压缩的过程，最终控制信息交互时延足够短，几乎就有了全局视图，用 crossbar 类交换设施取代统计仲裁变得可行。但 rfc2544 的要求指出控制时延依然存在，它并没有消失，只是和传播时延相比，低到足以忽略了。

接着看另一个时延尺度问题从而揭示根本。

提到 rtt，它指主机时延，传播时延，排队时延之和，整个网络的控制面开销被所有流量的转发过程分担。注意到这些时延在整体 rtt 中的占比以及影响非常重要。

对不同尺度的网络，主机时延和排队时延的占比存在根本区别，问题解法也根本不同。网络规模越小，主机时延和排队时延占比越大，而排队时延影响越大，详细分析这事能指导我们做正确的事。

注意两个变量，一个是光速传播时延随网络规模线性变化，即 proprt = d/c，一个是 buffer 排空时间随网络规模以 根号n 变化，依据是 buffer_size = bdp/根号n。两个变量表现为两个不同伸缩速率，围绕这两个伸缩速率的其它时延伸缩是根本：

在数据中心，rtt 的主机分量和传播分量在同一 us 尺度，排队分量要高一两个数量级在 ms 尺度，以应对随机而频繁的 incast。三者占比类似，主机时延增加一倍，rtt 至少增加 1/3，而一旦遭遇 buffer queuing，rtt 至少增加 10 倍，这指明两个明确的方向，降低主机时延，减少 incast。大多数互联网厂商的伙计们都在干这两件事，DPDK，XDP 等 bypass，FPGA，DPU 等研发均旨在降低主机时延，而包括 SRD，Falcon 等 transport protocol，以及 SDN 技术旨在缓解甚至消除排队时延，而 Swift cc 则旨在明确区分势均力敌的主机和传播/排队网络时延，以更精确进行拥塞识别。

数据中心内部，SDN 控制器作为控制面，它本身与传统路由协议工作在同一时间尺度(参考南北向流量的生成过程)，与 CSMA/CD 一样已到规模极限，但这并不是摒弃它的理由，相反，它是从多个盒子里故意抽拉出来的，因为它能大大减少甚至消除排队时延，而排队时延在数据中心影响巨大。

而 SDN 控制器在广域网上的作用却是另一个故事，反在相反的路上越走越远。广域网的排队时延小于传播时延且随规模增加而差距渐大(参见根号关系)，控制信息交互时延与传播时延仍在同一尺度，尝试用它稍微降低一个很重要但并不那么重要的排队时延，反过来可能引入控制器净时延，因为广域网是异步统计的，完全消除排队肯定需要同步仲裁，这本身反而会加重排队(比较有趣的矛盾)。

总之，排队时延的广域网的影响不如在数据中心的影响大，为降低(但不能消除)排队时延在广域网引入 SDN 的 ROI 太低甚至带来净亏损。

整个互联网即使一开始不是脱胎于应对核打击而采用分布式架构，仅仅在知道中心化如此低效后，也还会转向分布式架构。

如果SDN 控制信息交互时延不低于数据通信本身甚至阻滞(比如指令尚未下发)数据通信时，它都有收缩趋势，只有在它能实际降低净时延时，比如数据中心场景，才能抵抗这种收缩趋势，所以不可能存在全球 SDN 控制器，它只能存在于数据中心，局域网。就像大帝国达到一定疆域必定收缩一样，而像希腊城邦则对CSMA/CD更包容。

至于 SDWAN 的意义，单独抽出这张 overlay，它就是个小规模网络，不得不说的是，这涉及到分形或同构性，只要在同一个层次上说事，就要在这个层次上谈规模，规模缩放的原则依然是普适的同一个原则，因此，全球 overlay 上的 SDN 就可以，但全球 underlay 上 SDN 就不行，但如果规模扩展到太阳系，overlay 的 SDN 也不行了。

一个和 SDWAN 规模相关的例子是，假设选择一条更好的路径的开销为 1ms，在数据中心，这 1ms 的选路开销避开 5ms 排队延时或许看起来挺值，但在广域网上，1ms 的选路开销可能减少 50ms 的传播时延(比如一个节点比另一个节点近 10000 公里)，并且减少了 10ms 的排队时延，同样的选路开销却带来相差 10 倍的增益，这就是规模非线性效应。另一方面，数据中心抖动 100us 可能造成总 rtt 相差一倍，但对于广域网，100us 微不足道，因此对于 cc 中的 bdp 计算，显然对规模越小的网络越敏感，一个看得见的结果是 bbr 在小规模网络中侵占性太强(rtt 陡一下，bdp 差很多)而不实用。

指导性很明确，大规模网络选路收益大，小规模网络时延敏感性高。用什么不用什么，怎么做，现成的东西怎么改，自己定。

现在谈下传播时延。

传播时延看起来是一个受光速制约的倔强变量，我们无法做任何事情。但当它真成为瓶颈，唯一选择就是绕开它。典型的例子是多核处理器和边缘计算，看起来不相干的东西，实际是一回事。

处理器实际上就是用导线连接的不同计算组件总体，每个组件完成部分计算，将结果通过导线传输到另一个组件继续。传播时延不变，但组件的计算速度却在变快，直到它超过了传播速率，导线成了瓶颈。

让导线变短是好办法，而摩尔定律让这可行。处理器发展方向不是不断增强计算组件，而是不断把所有组件缩小，把整个处理器缩小，同一空间部署多个更小的处理器，这就是多核。

边缘计算则更直接，其不变量是一些硬需求，比如刹车时间，卡顿感知时间，分帧感知时间，唯一的方式就是将计算搬到离自己足够近到传播时延满足这些要求的地方。由此计算弹性可以衍生出 CDN，在边缘计算资源闲置时可缓存内容资源供就近下载，但有趣的是，这个顺序是反着的，CDN 更早一些，后来才有了边缘计算，可见时间不耐古已有之。

我举个例子结束关于传播时延的讨论，半径 200 米的圆形社区，圆心处有一家大型超市，别墅围绕在圆周，居民幸福感很强，半径 200 公里的圆形社区，别墅围绕在圆周，圆心处即使有座城市，居民便感受不到便利了。因为从步行到汽车速度的缩放相对距离缩放太慢了。

最后，谈谈 TCP。所有 TCP 失效的问题几乎都是规模问题。

上周写过一篇文章，谈谈越来越无效的拥塞控制 提到随着带宽的提高，拥塞信号越发不准确，传统的长肥管道问题也是一个规模问题，两个其实也是一回事，网络规模变大了，速度变快了，可拥塞的事实并没变，传达这个事实必然不能再用老方法了。

生活在越来越大的城市里的人们直接串门越来越少，事前都要先约一下，跑空的概率增加，代价增大，规模缩放会改变信息交互方式。

长肥管道中丢包后 cwnd 张开慢只是表象，认识不到本质只会被这些表面现象牵着鼻子走，就算不用 cwnd 控制你也搞不定。你想想任何信号包括电力在长距离传输中也会衰减就明白本质了，这其实是成功概率是与关系很快趋近 0，失败概率是或关系的问题很快到 100%，这概率计算随着规模扩展迅速非线性地拉大成功和失败之间的距离，这就是本质。解法自然就是不要搞长肥管道，别跟自然律对抗。

长肥管道问题，其它行业早就有解法，信号传输用中继补偿衰减，长距离输电升压减少热耗，TCP 你就不搞个代理 or SDWAN 隧道模仿一下信号中继，你就不用 pacing 模仿一下升压减少对 buffer 的冲击(bdp 很大，burst 对 buffer 冲击大，类似大电流的热耗)？固有损耗只能通过中继，比如电线漏电是没法通过升压解决的，但自身行为导致的损耗是可通过调节自身行为弥补的，比如升压输电，pacing 发送，一个 100MB 的 buffer 一窗发 110MB 就会丢包，但 pacing 就能顺利通过，这就是为什么转发节点都 pacing 的原因，网络传输也有欧姆定律。

成天想着怎么往长肥管道里猛灌增加 cwnd，除非你有物理专线，否则灌得多丢得多。

so？线性系统不好玩，纯内卷看不到岸。只有指数(无论指数是否大于 1)系统才有趣，才能在缩放中让各组分以不同比例的速度达到极限，优化明显落后的，或者砍掉明显靠前的，就有了看得见的收益，而工作的意义就在于，你要敏锐地发现哪些组分缩放地更快或者更慢。

希望本文对你有所启发。

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