当前位置：首页 > article >正文

网络基础设施拥塞控制

article 2024/9/23 16:25:05

我经常说，传统的 TCP 优化已经到顶，不会有大意义了，这有两方面意思。

一方面，内在的，TCP 的 ACK 时钟带回的信息就那么多，用足了又能怎样。一个学习最差的差生能控制的分数是是 0～100 分的区间，宽度足足 100 分，他控制不了自己能考多少分，而一个学习最好的学生能控制的分数则是任意值，宽度为 0 分！

另一方面，按照 TCP/IP or OSI 分层模型，任何上层的机制都是在弥补下层的缺陷。比如传输层需要重传，因为下层链路不可靠，那么如果下层链路保证可靠了，上层的可靠传输机制是不是就没用了呢？答案是肯定的。

假设物理层有了极大突破，实现了无限带宽，还需要拥塞控制吗？

Linux 内核的 task 调度算法可能就是来源于 CPU 核少 task 多的环境。几千个 task 排队，肯定要精致化排队体验。但如果有几千个 CPU 核，每个核只有几个 task 排队，要需要精致化排队体验吗？随便排就好了嘛！

所有花哨的算法，都源于资源不足，不得已需要权衡取舍。一种资源调度算法，要保证相对公平，所谓不患寡而患不均，但问题恰恰就是寡，资源要是丰盈，就不需要这些算法了。简单的日常例子，高速公路上没有红绿灯。因为不需要调度，道路立交，资源丰盈，各行不悖。

有意义的事在传输层之外。

全局意识下，不能指望传输层可以解决所有问题。以 incast 流量为例，无论任何传输层方案，包括 Homa，SRD 在内，都只是 workaround，需要从物理拓扑上着手才能解决根本问题。

比如 MapReduce，它本身就是一个以服务器为中心的星型逻辑，而服务器还单独挂在胖树上，不 incast 才怪，最后一跳 TOR 往往最容易拥塞。各种大成本投入在传输协议研发以及交换机 PFC 上却始终解决不了问题。其实只要改变拓扑即可：
在这里插入图片描述

将交换机为中心的视角改为服务器为中心就豁然开朗了，服务器星型拓扑是天然的 MapReduce，多连了几根线而已，总不能空手套白狼。

剩下的事情逐层自下而上，网络层需要支持多路径。IP 路由规划与宣告是个细活儿，这里不谈，但仔细想想 IP 理由到底还适合不适合，就发现这里还是有问题。IP 天然就不适合 MapReduce。

数据中心网络需要 IP 做隔离，但 MapReduce 却明明不需要隔离，相反，如果有一个广播发送，单播回复的协议就好了。

总之，单纯从传输层解决不了的问题，如果可以着手从物理层做出改变，那么完整的方案又何止一个。点对点拓扑一直被认为是不合理的，但三层架构树就一定正确吗？

有一个其它领域的例子，Intel CPU 的 FSB(前端总线) 速率一直在提升，可终究有问题解决不了，最终发现本质问题就是 FSB 自身，于是干掉它就好了。Intel FSB 的问题是一个与 incast 问题非常类似的例子，十几年前我看 AMD 发布的 CPU 架构时，发现它们 “一点都不美”，布线引脚乱七八糟，没有 FSB 将大家汇聚在一起进入 CPU，然而优美并不意味着正确。大多数时候，优美的架构源自于资源紧缺，“如果空间有的是，谁还会去整理物品，只有狭小的空间才需要灵巧的收纳。”

为了解决 incast，应用层方案，传输层方案都有，就是没有物理层方案，可物理拓扑的限制才是问题的根本。条件允许时，浪费并不可耻，明明连几根线就能解决的问题，非要执念于一个根本不存在的完美传输协议，岂不悲哀。

再看回传输本身。

MapReduce 除了可作为编程范式之外，它竟然可以作为一种非常自然的方式解释传输的本质。传输的目标是在 receiver 还原 sender 的数据，传输的过程就是 map，而 receiver 交付数据的过程则是 reduce，非常自然的一种多路径乱序传输的范式。类似多台服务器一起提供一个文件的不同片段的 map 过程最终汇总成一个完整文件的 reduce，多条链路可以同时传输一条流 or 一则消息的不同片段最终在 receiver 汇总成原始数据流 or 消息，这就是传输的过程，我们发现它不仅仅是一个传输协议，而是包含从物理拓扑到应用语义的全部。

当然，基于最优路径的逐跳 IP 路由已经 40 多年了，显然，它并不 match 上述 MapReduce 的意思。但我们必须明白，物理基础设施并不是一成不变的，在需要的时候，它们必须 “有能力被改进”，并且，我们也不能总盯着几个传输协议，现在越来越多的方向都在模糊分层模型的各层，应用层可以自己控制 pacing rate，物理层也可以。