再从 Tesla 的 TTPoE 看传输优化

天下皆知美之为美，斯恶已。

昨天写了一篇关于 ttpoe 的文字 从 Tesla 的 TTPoE 看资源和算法，下午跟朋友关于这个论题聊了几句，自然就聊到了多路径：稍加修改就能让 ttpoe 支持 multipath，packet spraying…

我没吱声。好家伙，做加法的执念如此自然且与生俱来，果然手里拿着锤子，看啥都是钉子。逮一个简单协议就要给它增加 feature，日后不合时宜后自然会带来各种问题，如今 feature 和 bug 早无边界，卷吧。

我先随便来个简单的：

/* Transport Header (TTP) that follows TSH
*
*  15  14  13  12  11  10   9   8   7   6   5   4   3   2   1   0
* +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
* |         opcode [7:0]          |             vc [7:0]          |
* +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
* |         pathID [7:0]          |             base [7:0]        | 加入这行：标识路径
* +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
* |                       path-sequence [31:0].                   | 加入这行：路径序列号
* +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ # 也可以用 reversed-byte
* ......
*/

加一个路径标识 layer，所有 cumulative ack 和 nack 均针对 pathID。但这无疑需要在协议层面增加处理逻辑，协议变复杂，不再至简了。

让我们反推一下。multipath 大部分为了利用更多带宽，小部分为了容错。在数据中心高度规则可控的环境，获取更多带宽当然是增加带宽，而不是寻求一种获取更多带宽的算法。

假设数据中心(智算中心)当前网络容量 C 确定，延时容忍阈值 R 确定，根据 little 定律，最大带宽 T 就确定，如果 T 足够小，即使 multipath 也不能满足，如果 T 足够大，即使 singlepath 亦可满足，性能不取决于协议和算法本身，而取决于 C。

“道生之，德畜之，物形之，势成之”，协议是道，算法是德，运行实例是物，带宽容量是势，缺的是带宽，改协议毛用。

另一方面，我们假设为 ttpoe 增加了 multipath 且运行良好，有朝一日机房带宽扩容了，足以 singlepath 满足需求，multipath 这个 feature 将成累赘，就像在好网络上跑 selective ack 一样。带宽随时可扩容，而 feature 向下兼容，甩掉很难。

花钱招人做 feature 将来变累赘，还是省掉这部分钱扩容带宽保持端到端协议的极简，你选哪个？

数据中心保持端协议极简是如此重要，因为服务器指令时间非常宝贵，时间应最大程度出让给计算而不是协议处理，协议保持极简，最少资源占用，剩下的交给带宽。

按第一性原理，缺什么补什么，而不是 workaround，包括 multipath 在内的数据中心 transport protocol 的一切花活，就是 workaround。

但现实是一个博弈制衡环境，不可能照最优解做事。先有计算资源感受到协议的复杂，才有 hw offloading，做 hw offloading 既能卷活又能卖卡，而简化协议并简单买带宽虽有性价比，但只能让更多做端系统的人没事做，收益都集中在交换机，长期看并不适合产业链平衡。综合看现实，performance 并非仅仅简单的表示为数据传输的有效吞吐与时间的商 bw / delay，而是包括人力，产能等各种因素加权的函数。

现实的做法更多先在端卷算法，再卷 offloading 卡，期间推出一些简化替代协议，达到极限后再扩容带宽，如此进入下一个循环。

简单总结，数据中心网络，简化端，增加带宽资源，传输算法越简化越好，用带宽资源来换服务器时间，把服务器时间更多留给计算，理解了这个，就理解了数据中心网络传输的游戏规则，也就理解了 ttpoe。但广域网正相反，广域网传输优化的前提是量化统计波动，而这需要大量持久的监控，统计和计算。

来到广域网，我们会发现一个不一样的世界。虽然数据中心的经理们倾向于宁可卷卡也不买带宽(更多为了保住饭碗)，但广域网用户却恰恰相反倾向于购买更大的带宽，这也是一个错误但现实的倾向。

和数据中心更像一台更大的主机不同，广域网是一个真实的复杂系统，数据流统计特征在一个更大的时间尺度上可观测，但在小的时间尺度上是随机的。用户购买的带宽只是接入带宽，它只约束可用带宽的上限，而全链路的统计波动往往把实际可用带宽压到一个固定的位置。

比如你买 1gbps 的带宽和买 100mbps 的带宽可以都只获得 50mbps 带宽。数据在全链路甚至要穿越不同 isp 的异构网络，端主机很难在一个往返时延内对统计波动做出反应，这意味着在广域网几乎所有的精确测量都不算数，cubic，bbr 给出了不同的方法应对网络拥塞，但无论哪一种都只能被动适应统计波动而不能影响。

cloudflare 早期的一篇文章给出了一个更有用的方法：Optimizing TCP Congestion Control Algorithms，我也曾经提到过类似的想法 互联网拥塞控制实践，它更像是天气预报的方式，结合昨天，近期，去年同期，以及最近 12 小时，最近 6 小时，最近 1 小时的数据进行长程依赖加权分析，而不仅仅只根据最近 1 小时的数据做即时预测。

不管怎样，在如此复杂的统计分析下，协议需要采集并处理更多信息，协议本身需要更多动态调整能力，往往就不是极简协议可以胜任，但从 ttpoe 开始做加法，直到加一笔就多，少这一笔就刚刚够，停下这一笔，就是 tcp 了。

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

原文地址：https://blog.csdn.net/dog250/article/details/142520428

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！