上周技术圈发生了些事,我也收到了些邀请,要我来评价两句,我很荣幸,就说两句。
我都被字节的经理开除很久了,已没资格也不想继续在这行业圈子混日子,就干脆相忘于江湖,也不用迎合谁害怕谁,反而能说点真话,反而能提供些不怕被别人说服的新想法,这就是我能欣慰的。

准备说两个事,一个是字节的 veRoCE,内容主要来自 zartbot 的文章,另一个是快手事件,后面单独再说,先说 veRoCE。但 zartbot 已经详解了 Spec,再详解就没意思了,而且大概没他写得好,我就说点别的。

我对 zartbot 的多数观点是认同的,但我没他那么基于过往经验的二元论,计党网党啦,谁对谁错啦,多年以前就怎样啦,你这么干没前途啦,不服以后再看啦,吧啦吧啦。我一向是个行者游士,于八方没利害,不开大会,不提派驰,没作品,就只说我看到的,我看到的是客观,我说的我看到的却是主观,所以我的观点是直观的。

另外,我只是借 veRoCE 这个话题,谈一些哲学观点,并不针对任何 Spec 本身,好久没写这些了而已。所以我不会顺着任何既有生态故弄玄虚,持有某个具体生态,以为 “现在是什么样就应该是什么” 的决定论一定是错误的,但并不意味着反过来就一定正确,能让你思考,我就赢了,至于对错,你说什么都对。

字节的 veRoCE(ve 取 Volcano Engine 之意),以我个人的理解,大概率是卷出来的。veRoCE 确实很多地方做对了,但可能算不小心蒙对了,毕竟一共就那点东西,100 人 100 个排列组合,总有几个能对上号不是吗,上上周我还写了一篇 世界是概率的,没有因果,这是我的世界观。背靠着概率压注,创而不新,这就是卷。

以我对草台班子世界的理解,有懂网络的但不多,看作品能看出是不是他们的风格。外行人看的巧夺天工,内行人眼里就是堆出来的一大坨,减法和加法的区别而已。

先看看 RDMA 的 SACK 是怎么回事。

看起来 veRoCE 终于以 SACK 替代 GBN 是个大事,也就摆脱,至少是减轻了对 PFC 的依赖,而 PFC 以排队时延交换重传时延,并引入复杂的死锁控制为代价。你拿排队兑换重传没问题,但引入新问题再去解决新问题,就是纯属出力不讨好。即便拿排队换重传,你们不知道交易要交税的吗,这还是大宗交易,你把交易税当手续费也行,anyway,省不了的。

起初折腾这一大圈,在工程意义上只是为了照顾在 RDMA 最初的年代 “Host 卡无法或不易实现 SACK 只能 GBN”,通信数据量不大,buffer overflow 率很低时,相比 SACK 解决问题,不如简单 PFC 规避,于是抱怨存储空间不足,硬件太复杂云云助推,这不是一个解决问题的正确路径。你无能为力,要么努力学习,要么换有能力的上,结果你抱残守缺,让别人折腾一圈只为照顾你,GBN + PFC 是这方面的典型实例。

支持 SACK 在工程意义的方向上,veRoCE 解决了问题,但为什么止步于 SACK 呢,就不能更进一步,把带内传输控制(主要基于 ACK 自时钟)的问题都解决一部分咯?这就是我说的创而不新。不出意外,我并不针对哪个公司的哪个协议,虽然基于 ACK 自时钟的协议不只有 TCP,但除了 TTPoESUNH 还算有点意思像回真事,其它的所有都倾向于变成 yet another TCP。

说到底黑白黄绿一共就那几个词,GBN,SACK,NAK,PFC,FEC,ECN,还有谁?没现成的就想不到,有现成的就随机组合,总能组合成对的,一招鲜,吃遍天。这方法论来自《技术的本质》[布莱恩·阿瑟 著],但类似轮子和手提包组合称得上真正的精巧发明,毕竟它不是从多个劳民伤财的组合尝试中挑出来的,提包也从没人试着绑在皮鞋上。

解决方案,新技术都由需求促就,那几个词出现的时代跟现在完全不同,那时根本就没有如今超算,AI 集群的需求场景,就不太可能出现适应该场景的名词和技术,用那些老词描述的技术解决现在的问题,如同为马车装上蒸汽机。但还有一种技术是依第一性原理想象出来的,往往超前但不实用,这就涉及工程学生态的本质。

不得不说,整个工程界就是这样,非常类似屎山式的生物进化,不管什么东西堆多了,堆久了,那一坨就成标准了,就好像必须那么一坨才行,做工的人做什么就以为世界是什么,容不得半点不同,实则是积重难返了,改不了了,没有第一性原理插手的空间了。

TTPoESUNH 那样做减法才是正道,微核才经得起扩展,简单才容得下复杂,软件上你得收着,剩下的交给硬件和基础设施,至于拥塞控制,指望一系列端到端协议软件去搞分布式控制,纯扯淡。顾名思义,拥塞控制你要去控制啊,TCP/IP 跨省,夸运营商,跨洋路径反馈周期太长,它是在尽力而为的网络上控制不了,于是分布式端到端拥塞控制就是它的创新,你特么一个集群你也控制不了?人家是做不到而求其次,你是能做到硬模仿。

传闻杨坤的嗓音是这样的:

实际上,杨坤刚出道的时候并不是这样,而是清爽细腻的风格,还能唱蔡国庆和张信哲的歌。后来是因为发声方法不对,导致声带使用过度,长了两个米粒大的声带小结 … 在一家专业研究声带恢复技术的医院做了手术 … 可是他没当回事,一个礼拜就开唱了,不久后就声带出血,变成了现在这样粗犷、沙哑的嗓音。

当然,你有蔡国庆和张信哲的嗓音,非要噶了嗓子模仿杨坤,也没什么不好。

SACK 只解决了重传问题,既然要把一切的恶都归为 flow 和尽力而为网络的错配,丢包的孪生兄弟就是乱序,你依然要对乱序做重排序,好像一切理所当然。我的天,最终你只能把 TCP,QUIC,IB,甚至 ATM 的东西都抄一遍做个集大成了,叫什么呢,QIBRCPoE,“以太网上的快速 IB RDMA 传输控制协议”,现在大家不都在这样抄作业吗?

上周我在 HTTP 2.0 的真正革命 提到了 QUIC 未竟全功,这里再稍微细化一下。有人将 QUIC 移植到了数据中心,本身这件事就很艹,结果连 flow 也跟着挪过去了,然后搞多路径,紧接着(不得不)拼命解决和优化乱序重组问题,一个算法一篇论文,KPI 卷得飞起。可是我在文中提到一种 “拼图式” 重构法至今鲜有人提到:

应用无需像过去那样严格依赖接收顺序,而可以像处理乱序的拼图块一样,根据每个数据帧自带的序号和位置信息,并行地,乱序地将它们还原成完整的资源,从而彻底释放了多核并行处理能力,解除了传统流式传输强加的顺序约束。如此一来,在常识性的 TCP 外,保序和可靠就终于解耦了。

这不就 DDP 嘛,这难道不该是第一时间想到的方法吗,还非要人提醒?你家搬家的时候拆卸的东西散了,你是怎么做的。找一个高中生问他怎么在多路径上传一个大块数据,他都能想到拼图这种最自然的方法,但你要是问 “一个乱序的序列如何重组成特定序列”,他就顿时就不会了,但却能折腾一篇论文出来。

多路径是方案,是手段,要不是有 flow 的概念,多路径以及它带来的所有问题在任何网络中都不会存在,回想分组交换网最初的设计,packet 交换的最初目标不就是为了破 flow 约束吗?让每一个 packet 独立地,逐跳地,无状态地到达目的地,但因为 flow 更 match 人的日常认知,最终又拐回了 flow 范式,强行加了一个保序约束,这个约束反过来在 TCP 统治的 40 年中加强了 flow 范式,以至于不管什么问题,什么方案,全都是 TCP/IP。

你只要掀掉一个先入为主的概念,回归到本质,就能体会到很多高效的解法是多么直接和自然。以我自己的 TCP/IP 到 Torus 街坊的重构 为例,总有人觉得不同的解法早晚会遇到相同的问题,其实还有混淆了手段和目的。掀掉 flow 的概念,将计算和传输看作整体,计算是可调度的啊,不会伫立在那当靶子让 incast 怼的啊。

只要确保计算资源在网格(网格,不是网络)上分布是均匀的,同样用一套趋向目标的随机规则就可以保证流量是均匀的,flow-based fairness 这问题本身就消失了,看,多么简单,我们几千年就是这么自然而然生活的,堵车是为什么,是你们故意要把车聚在一起的啊,然后你们再去治堵,是不是活该。

问题都来自既要又要还要,背后还是大数定律,抽样越多,期望越明显,越多人的期望变成尖峰,那便是问题,如果大家的期望都不同,就均匀分布了。拥塞也好,incast 也好,fairness 也罢,本质上都是不均匀,x 方向的流量超过了 y 方向的流量,仅此而已,从源头解决问题的方法就是调度资源分布而不是调度已经发生的传输。

东区往铁西区送孩子上学的车总是堵死中心城区,你去调度交通吗?倒是在东区多建几个学校啊。不从本质上理解和解决问题,只会对表象对症下药,最终就跌入 “引入新问题-解决新问题” 的无奈循环。

由此方法论,再看 Torus 网格本身,我在文中不小的篇幅描述了如何避免环路和解决死锁问题,为这个想象中网络增加了一点瑕疵,当时怎么看都觉得不美,其实只要掀掉网络的可靠性,“让它丢包” 就行了,发不出就丢掉,让它丢,然后重传,把死锁这类问题本身消灭掉,这才是正路。

前面提到,在工程意义的方向上,veRoCE 支持 SACK 是正确的,现在回到 RDMA 本身,重估 SACK 在实际意义上的价值,就没什么对和不对的了,不是解决了已有问题的方案就是对的,要看这问题到底是不是问题。以我个人经验,SACK 到底需不需要做,还是要基于测量的实际丢包率,如果丢包率很低,SACK 就没必要,GBN 足以应对,没必要花大代价去兜底一个小概率异常。但如果丢包率偏高,就扩容升级基础设施,把丢包率降下来RDMA 早就可以 SACK 了却还不支持它,更多还是对硬件设施有一个好的假设,因为只有丢包率极低才敢 GBN + PFC,veRoCE 相当于又把软件给拉回主导了。

总之,给人的感觉很熟悉,天天说 TCP 这般那般不好,吵闹要自研,还天天把 TCP 的 feature 往自研协议上搬运,结果我说它们就是 yet another TCP 还不愿意。但为啥不用 iWARP 呢,就算生态不好也能自己造的啊,但另一层意思,搬归搬,你说你就实现了一个 bypass 版的 TCP,会被说没有工作量。但不开玩笑的说,iWARP 的协议头开销确实太大了,除了能跑广域网,它和 SUNH 是相反的路径。

不管怎样,GBN 也好,GBN + PFC 也好,SACK 也好,SACK + NAK 也好,还是直接用 TCP/IP-based 的 iWARP 也罢,不要指望谁能降维打击谁,在一个硬件基础设施良好的网络,它们都差不离,原因很简单,因为丢包根本就不会被触发,知道该往哪使劲了吧。

另一个 topic,至于 veRoCE Spec 介绍里提到的 PSN 以及其 vs. SeqNum,不值得一提,传什么编号什么,请再想象你搬家时的做法就行了,没搬过就去买个房子搬一次,相比都做协议设计和优化了,买个房子简单多了。这个 topic 不多说。

再看,为什么很多人拥塞控制做不好,因为不懂硬学 BBR。

当年(2016 年底) BBR 提出个 rate-based 方法(pacing_rate is BBR’s primary control parameter),一群人好像找到了银弹,相见恨晚。一时间开发出各种 BBR 魔改版,甚至 CUBIC 也给 cwnd 除了个 RTT,假装成 rate-based 赶个时髦。这帮人其实只知其一,不懂其二,net/ipv4/tcp_bbr.c 就在那里,可 BBR 的运行环境没几个人关注。没有中控或带外的网络中根本就跑不了 rate-based,即使有中控,BBR 也要不停 probe,如此也还是解决不了 fairness 问题。可要不是 BBR,fairness 还是问题吗?

为什么 rate-based 难,因为 rate 不能守恒。有个时间做分母,能把 pacing rate 拖没了。换句话,仅依靠 ACK 自时钟来测量 delivery rate,分子部分的 inflight 和分母部分的时间是个攀附的正反馈,所以你的 probe 是盲目的(或者胡乱找个公式让人不明觉厉,做不到 VJ AIMD 那么让人能理解,就别出来胡扯),最后要么逼停传输,要么侵犯其它传输,只要你用 ACK 自时钟,你只能从中数出一个量以及与之互为因果的 RTT,就没有办法解决这个问题。

BBR 有 B4 你有吗?B4 有非常细化的 SDN controller 你有吗?

不要把事情当任务来做,而要当问题来解。

上周我抓住运营商掐掉了我们的 MPTCP 选项导致我们无法聚合带宽。无法聚合带宽只是通往结果的现象,它不是结果,碰到这事我第一个想到的不是给软件做加法,搞什么探测脚本,怀疑软件 bug 啊,我会想运营商正常会怎么做。

运营商发现了数据包里有 MPTCP 就知道你要干啥,他不想让你抢带宽,肯定给你干掉,简单抓包就能确认,接下来运营商要怎么做?程序员的想法很程序,写个脚本,再聚合再干掉,谁搞 MPTCP 干谁,工作量自然就上来了,日报周报也有内容了,但运营商不会这么麻烦,直接给你限速就完事了,然后躺着抽烟不好?

为什么专门干 MPTCP 不好,因为 MPTCP 只是聚合手段之一,程序员只能想一层。不让用 MPTCP 聚合,我用私有协议折腾不行啊。直接给限速 10Mbps,用私有协议 10 个模组也就聚合 100Mbps,聚合边际收益递减,这么多模组,耗电呢,主板呢,都是钱,30Mbps 聚不上去就没人玩了。想到这个,运营商咋处理这事就一清二楚了,果然,真是,打个电话就能解除。

技术能扯一晚上,先说到这里打住。

这篇文章主要是就着一个听得耳根子都快发麻的陈年话题聊一下我的看法,veRoCE 作为技术本身还不错,但人皆有偏见,我向来并不认同字节的价值观,所以我对卷客出品持两面观点,就算它真是唯一一个雷霆救兵式的团队协作出来的,我也不信,我可能错了,但这就是我的偏见。

我曾开玩笑,字节一个部门走掉一个最能卷的,其他人就都有事做了,可字节价值观偏偏留下最能卷的,然后唤起其他人争强好胜但又胆怯的心,把不争不抢的淘汰,这显然不是一种团队价值观,因为你根本不敢把后背亮给他人。他们在筛选优秀但在工作以外没想法的卷客,旁边依附一群优秀但紧张的人,而不是直接筛选一个优秀的团队,同样做成一件事,从一帮技术人根本不关注的人性立场看,本质是不同的。

失败了,卷没了怎么办,形式上加入胜利者,默默离职,转岗,苟着,都行。

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

不过有悲喜无对错,若果真 veRoCE 是卷出来的,那么这种卷品真的要被鄙视吗?单纯从产品本身而无关人性而言,我看也未必。

只要你能负担足够的成本达到目标,就不失一种好方法。正如算力为王的当下,再也没有人鄙视AI “一个一个试” 的傻 X 策略了,事实就是机器下棋赢了人。算力够了,数据够了,做事的方式也该改了,不缺啥就用啥。字节不缺钱就不缺人,越能卷出好货,期权越是节节高,大家都挺好。

九工裂草,盲锥争巧,蒸皮误漆,鞣革错砾。初时皆谓败道,三曝九转,竟得玄光挺刃,合于金堂玉律,终成摩登之履。奥康乎,康奈乎,日泰乎,意尔康,吉尔达,红蜻蜓乎?你们请看,温州作为皮鞋之都就是这么来的。

这周的文章有点长,而我一向很鄙视 “万字长文”,除非真想说点什么。

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

Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐