我经常说,传统的 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,物理层也可以。
传统网络以交换机为中心,意在巩固利好上层,如果以服务器为中心,则巩固利好底层,很多问题都将解决。多对多,人人为我,我为人人,自服务器为中心的交叉。这是一个在来温州的
路上想到的一个问题,写篇文字以记录。
浙江温州皮鞋湿,下雨进水不会胖。