TCP 的演化史-更合理，更正确的 TCP

现在很清楚，sack 是 TCP 在 40 余年历史中演化出来的，为 sender 提供更精确的 receiver 信息，但由于 sender 本身无法区分原始报文和重传报文，sack 也就没有提供进一步的信息，rack 让 sack 提供进一步信息成为可能。

现在，站在 2023 年回头看 TCP，我们会有很多 “如果当时…就好了” 这般假设，那么假设这些假设成真，我们发现，其实 TCP 天然的 “积累确认” 也是一种 sack，它 sack 的是 [0, una) 这个区间，这个观点下，sack 和 ack 便可统一处理了。

假设 “如果 TCP 一开始就有 sack 就好了”，那就让它一开始就有 sack，便可将 ack 看作一个 sack。

假设 “TCP receiver 没有 reneging 就好了”，那取消掉 reneging，那么 sender 被 sack 的数据也可删除了。

假设 “TCP sack block 按照 LRU 方式布局就好了”，那就强制 sack block 按照 LRU 方式布局，sender 更容易计算 reordering metric 了。

…

来来来，我们看一下这个新样式的 TCP：

几个亮点说一下。

首先，sack block 数量的意义是提供一个冗余度量，它是一个 “冗余窗口”，只要别把整个窗口的 ACK 都丢了，sender 就能还原接收序，从而计算 reordering metric。

另外，取消了 reneging，对 recv buffer 没坏处，却解放了 send buffer。

但这只将 TCP “合理化” 了，新样式 TCP 依然 “直接传输 byte stream”，上图所示的小方块可能会被 sack 切割，每个小方块都可从任意处截成多个，无论 S(data segment) 还是 A(ack)，所代表的都是 byte 区间，而不是如图中的数字标识。比如 S3 可能就是 2501～3985，而 A3 不一定就是 2501～3985，可能它是 2501～2504。

这意味着 sender 的处理依旧非常麻烦，sender 依旧需要做大量区间 search，split，merge 操作，以便做 delete，retransmit 以及 reordering update。

不仅如此，新样式 TCP 依然存在原始报文和重传报文之间的歧义。

因此，在合理之外，来看看 “正确” 的做法：对 packet 的传输编号，而不是对 byte stream 编号。如下图所示：

传统 TCP 没对传输编号，这是歧义之根。TCP segment 实际上是一个区间，上图所示的协议做出了改变，将 byte stream 先装入 packet 中，然后针对 packet 对其 byte stream 顺序进行编号，记做编号 1，当 packet 被传输，无论第一次传输还是重传，均为其升序编号。

事实上，编号 1 可省略，代价是 receiver 的重排序要更复杂，引入编号 1，相当于在区间 search/insert 之前，先对 packet 编号 1 进行排序，而编号 1 排序后，要做的仅仅是区间顺序 insert，省去了区间 search。编号 1 的预排序显然比直接区间 search 更省 CPU。

但编号 1 增加了 packet 头长，浪费了一些带宽和内存。还是那个问题，省 CPU 时间就需要信息，而信息需要空间来存储。这又是一个时间空间的权衡。

有一点迷思有意思，加法容易，减法难。设计一个可靠传输协议，相信大多数人都可以完成，问题是你需要多少信息。换句话说，协议头越小，成绩单越好看。你能用多么精简的信息量完成这件事，而不是任意取用信息。

TCP 最初就如上考虑，用足够简单足够精简的协议头，完成可靠传输语义。可一旦增加新需求，比如性能需求，丢掉的信息就要补回来。TCP 足够小，这驱动了 TCP 的演进，否则如果 TCP 最初是一个庞大完备的协议，也就尾大不掉了。

要做减法，直到不能再减。演化，要从最简单开始，这是更多方向，更多可能性的基础。
把上图的编号 1 去掉，先让 CPU 多跑跑，也许后面区间排序问题不再是问题了，这省下的带宽和内存就值了。

最后，我来说一下我为什么一直强调不要传输 byte stream，一定要 packetization。举个例子，HTTP/2 的分帧，和 HTTP/1.x 直接传输字符串做对比。

这周出差，酒店晚上没睡着，画了本文第一图，本文衍生自春节假期旅游期间在酒店写的一篇文字：重新设计 TCP 协议。就着这幅图，我大致讲解一二。

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