传输优化抽象-CSDN博客

昨天跟朋友聊起传输优化的抽象(用词不当，但我及其恶心方法论这个说法)，整理一些观点。

端到端传输优化的上限取决于能有效利用多少信息，而下限取决于这副牌你想打多烂，注意，你有什么牌并不由你决定，你只能决定怎么打。

类比考试，你能确定性地考 100 分，你就能确定性地考 0 分，分数的上限和下限同样由你的能力决定。如果你什么都不会，概率上讲，你只能考 50 分，不多也不少。能力越强，偏离 50 分越多。

我们做传输优化，比如 TCP 加速，TCP 拥塞控制，普遍的误区在于，我们总希望通过有限信息获得全部真相，总希望能通过摆置这些有限信息将获得的规律公式化，从而得出一个最优解。这是不符合信息论的。

信息论的一个结论是，做任何有效的决策，必须有额外信息的输入。

一个常用例子，我们总希望不断采集并分析 RTT 来区分拥塞丢包和随机丢包，这显然颠倒了因果。RTT 持续升高只是拥塞的一个表象，反过来看，如果观察到 RTT 持续升高，并不意味着一定发生了拥塞，比如可能有人在操作路由器逗你玩，若真出现这种玩笑，你真区别不出是真拥塞还是真有人逗你玩，因为没有额外的信息让你做这个区分。这个时候，误判是必然的。

以前上学时，放假买回家火车票都靠抢，但如果你认识铁路系统的人，在放票前给你些信息，你还怕抢不到票吗？同样道理，端到端传输优化，每条连接能利用的信息一致，上限就是通用的公平，如果你非要脱颖而出做得比别人好看，你就必须要有额外信息。

给定一个算法，固定输入，那它的效果就一定存在一个上限，想突破这个上限，必须额外的信息注入，是必须，而不是建议。

对于无线链路传输优化，若能获取链路状态信息，比如物理资源调度信息，就相当于抢火车票时有系统内部的人帮忙。任何脱颖而出的优化都来自信息不对称。该场景的最优解是找厂商或运营商合作，用业务收益让对方受益，对方当然会提供信息。和风险投资不同，这种合作对它们而言是承诺收益的，厂商，运营商投资信息，你利用这些信息改造算法获得优化收益，变现后让对方获得收益，就是这么一个环。

就是这么一个简单的道理。

仅依靠滞后的反馈，你永远不会知道正在发生什么，更不会知道将要发生什么，即便在理想场景，依靠反馈也只能猜对大部分，任何抖动都不在控制范围，而这些抖动偏偏正是要控制的。比如一个短突发转瞬即逝，你怎么靠反馈捕捉到，反馈只能误导你欺骗你。

要事先知道信息才能对决策产生决定性影响，而这不可能靠端到端完成，这需要底层提供额外支撑。你若笃定端到端闭环优化，那很抱歉，这行不通。

违反分层抽象是必然的，从应用到链路，信息通达，才可优化到极致。分层抽象的收益是通用，反之，极致的优化需要个性化定制，这道理放之四海而皆准，无论对于 TCP 还是对皮鞋。

…

有人说，为什么 BBR 做到了呢？我们能不能做一个 XXYY，它对 BBR 的效果就像 BBR 对 CUBIC 的效果呢？

BBR 多数实际场景到底比 CUBIC 好多少，甚至是不是真比 CUBIC 好姑且不谈，权当它真的吊打 CUBIC 。你以为它是凭空出来的吗？跟 CUBIC 共建于同一套基础设施？

如果 BBR 团队不事先加入 us，ns 级高精度时间戳支持，仅靠 ms 级 的 jiffies，BBR 能玩起来吗？高精度时间戳一直放在系统里，BBR 想利用就要自己去挖这个信息，BBR 前那么多基于延时的算法都不行，就是因为没有利用这个信息，以至于无法支持高精度计算。只有 1 ms的时间精度，就分辨不出 1 ms 以内发生的事，甚至连 rack 都实现不了，更别说 BBR 的 maxbw 计算以及 pacing rate 计算了。

…

本随笔第二部分，我来谈谈 TCP 报头。

1970～1980 年代的 TCP 由于带宽和内存资源受限而过于谨慎。1990 年代往后，特别到了 2000 年代，带宽和内存等资源不再紧缺，TCP 开始考虑利用这些资源增强表达能力，和老式 TCP 极端有限的表达能力不同，TCP 增加了很多新选项，如 SACK，Window Scale，Timestamps。这些新选项无一例外都是希望为连接注入了新信息而提升性能，这正是本文第一部分的观点。

以 SACK 为例，若没有该选项，TCP 不知道接收端具体收到了哪些包，只能无脑 GBN，这个时候无论什么高尚算法，也无法 “猜” 到对端到底收到了哪些包。缺了这个信息，怎么猜都不行。SACK 的思路很简单，就是把这个信息带回来。

Window Scale 也类似，16 bits 窗口最大容量 64KB，这是 16 bits 所能表达的信息的极限，还是信息不够。注入一个新的 WScale 选项信息，事情就解决了。

TImestamps 这个新选项例外，它并没有带来预期的收益，因为没有它也可以完成同样的事，Timestamps 注入的信息完全是冗余信息，有趣的是，冗余信息还浪费了 12 Bytes 的空间：
Save some bandwidth by turning off TCP Timestamps

这也是我提高 TCP Timestamps 精度的原因，因为高精度 Timestamps 作为一个可以 echo 回来的信息，对于度量时序很有用，甚至可用来度量对端 Delayed ACK。此前没这个信息，现在有了，利用好它就有收益。

再进一步看。

SACK 选项由于选项存在长度限制，只能容纳 4 个不连续的块，这使它未竟全功。如何突破这一点呢？
增加新信息以提高表达能力，代价是增加报头长度，徒增的报头长度就是徒增的带宽，也需要徒增 CPU 处理开销，不能让你空手套白狼。

我在想 TCP 为什么不干脆增加一个新选项，该选项的意义就是 “选项本身是否支持 TLV(Type-Length-Value)”，只要两端均升级，那么选项就完全 TLV 化了，SACK 不再受限，还能支持 NACK，甚至能把 Delayed ACK，处理延时等信息全部带回。TCP 只需要调整选项就可以变成任何协议，甚至可以带着 TCP 标准头直接变身 QUIC。

如果愿意，底层链路可以将它想给你的信息打入 TLV 格式的选项中。

TLV 选项实属空谈理想，现实是，TCP 选项依然是固定长度的，对端返回的信息依然有限，那么向谁要信息，怎么返给你就是要做的事。

向对端要端到端信息，可通过带外连接，比如伺服连接专门探测链路并相互交流。向底层要链路信息，需要有接口支持。无论跟客户端合作，跟终端厂商合作，还是跟运营商合作，目标永远是拿到更多的信息，信息，还是信息。

我一直觉得端到端 TCP CC 优化已经到顶了，BBR 最终也退回了到了相对兼容的 BBRv2，并且即便 BBR 本身对网络也是挑剔的。这不是算法到顶了，而是端到端 TCP 连接能提供的所有信息的利用率已经逼近极限。类比考试，就好像你把毕生所学全部烂熟于心，这也就决定了你的能力上限，靠答题技巧走不远，你的上限由你掌握的信息决定。… 谈传输优化，大部分普通连接质量无需优化，客户够用，你需要把那些弱连接识别出来，而你没有额外的信息可以帮你做这个识别… 所以我曾经干过一件事，分析散点图，把一段时间弱连接一个个挑出来求交集，把交集内的 IP 写死在代码里，几千个 if 语句，效果好的很。这就是信息的力量。

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