TCP/IP 协议演进中的瓶颈，权衡和突破

所有(去掉 “几乎” 修饰)问题都来自于生长速度的不一致，换句话说，膨胀不是均匀的，从而产生瓶颈甚至触碰极限，TCP/IP 从协议到实现面临的多方问题与动物体型不能无限大，摩天大楼不能无限高本质上一样。

如今被高性能网络诟病的 BSD socket API 诞生之初的姿态是非常高的，1980 年代的网络非常慢，CPU 通过 socket API 不慌不忙地喂数据在当时是一个很直接很简单的方式，就算加上拷贝，上下文切换的拖累，网络依然相对很慢。彼时如果能料到网卡终有一天会远超 CPU，socket API 可能就会以一种更容易扩展的形式存在。如果认识到网络只是在当时慢但总归会变快，socket API 便会以更集约的方式而不是慢吞吞地将数据准备好。

如今的 DPDK，零拷贝技术终究还是以 work around 出现，几乎已经成了事实标准，但存量应用程序非常难(几乎不可能)迁移到新方案以获取高性能。现在网络快而 CPU 慢，再设计网络 API，它不应该是反过来(与 socket API 相反)慢吞吞将数据交给主机，而且网卡集约处理更多逻辑，也就是小经理们都正在做的事，不吹不黑，这事(至少目前)靠谱。

再看协议本身，IP 报文长度被限制在 64kB，可以太网 MTU 却只有 1500，这种错配意味着什么？虽然大家都清楚分层模型在层间不必耦合，各做各的，但总会有现实考虑。

设想 IP 允许一个无限长(64bit？128bit？)的报文长度，当需要在物理网络上发送这样的一个报文时，链路将回退到电路交换，而这正是分组交换网要避免的，即避免长时间占用线路。考虑到典型的 T1，E1 链路，发送一个占用线路不超过一个容忍值的报文，求其最大长度。64kB 在 1.5Mb/s T1 链路占据 0.3s 显得稍久但能容忍，同时考虑实际物理链路 MTU 有限以及网络带宽会随技术发展不断提高，这个实际的时间会更短，且越来越短，而 64kB 仅由 16bit 即可表达，对带宽和内存要求也不大。

随着带宽逐渐增大，压力给到了主机，因为发包收包越来越快，一个报文的持续间隔相对越来越短，主机被中断的频率越来越高，64kB 的长度显小了，tcp: BIG TCP implementation 我引用好几次，但终究是 work around。IPv6 仍然维持 64kB 长度限制，但允许扩展头发送巨型报文，这个方式就不错，兼容和扩展都有了。

以上两例旨在说明主机和网络发展不对称，CPU 和网卡的增长率不同产生了最初的设计并导致了最终的反转，然后 work around 以及下一代的修复，如此再循环。

这些经验教训似乎表明所有旧时的设计都是不足够的，但并非总是如此。

继续看 TTL，只有 8bit，在带宽，内存资源看似可以浪费的现在，8bit 是一个让人看一眼就觉得可怜就想拉长的字段，但它应该更长一些吗？

高速转发最大的阻力就在交换节点(路由器和各类交换机)，随着带宽增长以及路由(主要是增量 IPv6 路由)汇聚规整化，更小的路由表在基建方面倾向于推动建设更长的链路，端到端的跳数应该减少而不是增加。全球的地理范围有限，网络扩展倾向于跳数增加，但路由汇聚抵消了新增的那一跳，互联网旨在构建连通性而不是在织蜘蛛网。所以直到 IPv6，TTL 依然只有 8bit。

再看 IP 地址本身，32bit 显然太短，但 160bit 绝对太长了，这是一个有争议的问题，IPv6 取 128bit 属折中，这里换一个视角，IPv6 128bit 的地址长度最大的问题在于地址空间大小和期望特性间的错配。

书写，记忆难度以及配置问题不值得一提，毕竟 IPv4 地址也不太容易书写记忆，所以才有了 DNS，且不必说计算机系统处理海量信息能力对人而言本就是降维打击。

过于庞大的地址空间意味着几乎无限的分配可能性，若稀疏分配，路由表的存储以及查询开销将变得巨大，若紧凑聚合分配，理论上离散的地址将聚集在一起有助于减小路由表条目，但也抵消了抗扫描的优势，此外，稀疏的空间抗扫描的同时，也几乎让攻击溯源变得不可能。各类 trade off 是非常难的，地址空间越大，问题越难，越容易遗留问题。

128bit 地址空间倾向于被塞入很多层间信息(反正够用)，让人更容易以浪费的理念去使用。但不要忘了，塞入更多信息意味着暴露更多信息，这又是一个争议话题。MAC 地址，位置，类型，甚至公司机构的规模，都可能会被映射进地址空间，而 IP 的初衷只是一个 best-effort 核，无状态，不记名，128bit 空间本无碍，大地址空间便于路由管理，但它太大也容易被误用。

下一个问题，TCP/UDP 端口号 16bit，如果有下一代协议，它应该扩展到 32bit 吗？

事实上很少有人意识到这个问题，但很多工人都遭遇并排查过 timewait socket 太多导致建连失败，bind，connect 的 CPU 热点问题，在此背景下，很多把戏应声而出，包括魔改内核缩短 timewait 时间，stap -g 硬改 timewait 状态，甚至 Linux 内核在 bind，connect 分别遍历奇偶端口号选择端口，而这正是 CPU 热点的根源，总之一塌糊涂。

本质上这是由于 16bit 端口号空间过小导致。如果扩展到 32bit，问题就迎刃而解。主机简单递增并选择全局 32bit 变量作端口号即可，毫不费力。

随着网络速度越来越快，越要解放节点算力。随着网络带宽相对于主机的加速度越来越大，传输每字节的主机时间越来越小，因此协议必须越来越简洁，减少计算量！具体实例参见 QUIC，Falcon 等。

最后来看 TCP 序列号，32bit 够吗？

在 1970～1980 年代足够了，但随着带宽增加，序列号回绕问题必须面对，同时 32bit 的序列号空间也限制了最大 rwnd 只能达到 2^30(就这还是在 wscale 选项的支持下)，导致更大的带宽无法被充分利用。同样的，各种复杂且难以理解的把戏就来自于这种原始设计的向后不兼容性。

设计一个向后兼容的序列号表示法并不难，由于数据包的自解释性，TLV 及其变体是常见的方式。可以限制最大的序列号空间为 16Byte，这是个天文数字，足够度量现实中可以想象的任意数据的长度，因此一个序列号可以是 1～16Byte，具体多少取决于一个额外的 4bit 长度，比如它是 1110b，说明后面 15Byte 都是序列号。

先这样，这就是今天要讲的故事。

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