摘要

  • TCP 的基础规范 RFC 793 发布于 1981 年。此后数十年间，规范性变更、澄清和勘误分散在多份文件中。
  • 2022 年发布的 RFC 9293 将这段规范变迁汇入一份更新后的 TCP 规范。文件署名 Wesley Eddy 为编辑，并记载了 IETF 社群共识、公开审查和 IESG 批准。
  • 这次汇总也划定了不纳入的内容：设计说明和若干复杂算法仍在配套文档中。共同规范更容易查到，但这并不能证明所有已部署 TCP 协议栈都符合每项要求。

协议可能比它的文件目录更长寿

维护 TCP 的工程师翻开旧规范，又发现后续变更散落在其他 RFC 中时，需要回答两个问题：哪些要求仍然有效，为什么会有这些要求，又在哪里解释？TCP 早已广泛实现，但基础文本仍需与不断增加的更新文件一并阅读。首先遇到的是文档维护负担：评估一次修改或核对某个实现前，必须先拼出当前规则集。

RFC 9293 明确描述了这个问题。数十年来，RFC 793 与其他文件共同构成 TCP 的核心规范，而安全、性能等方面的改进一直分散记录。该文件的目标是收集对基础功能规范作出的 IETF 标准轨道变更及其他澄清，并把它们统一进更新版本。这是对规范资料结构的维护，不是重新设计 TCP 架构。

从首页可以看出汇总的范围。RFC 9293 取代 RFC 793，也取代了修改过其部分内容的六份文件：RFC 879、2873、6093、6429、6528 和 6691。它还更新 RFC 1011 与 RFC 1122 中关于 TCP 要求的部分。实际承诺并不是把每种功能都塞进一个文件，而是为共同的规范性行为提供一个现行起点。

编辑职责本身也是结果的一部分

RFC 9293 的署名是“W. Eddy, Ed.”，也就是 Wesley Eddy 担任该文件的编辑。文件将自身标为 IETF 标准轨道文档，并记载社群共识、公开审查和 IESG 批准。这样的归属避免了两种简化：把要求看成某个人的私人解释，或把编辑写成 TCP 的发明者以及所有旧修订的作者。

文件也清楚说明了没有纳入什么。RFC 793 包含设计目标、工作示例和协议运行说明。RFC 9293 没有重写其导言和设计理念，而是聚焦于规范性协议行为，并引用保留理论、理由和设计决策的其他文件。对长期维护软件的人来说，这样的划分把两件重要但不同的事分开：必须实现的规则，以及帮助理解规则的说明。

这条边界不代表规范完全没有语义变化。RFC 9293 说明，它在 SYN-RECEIVED 状态下对 RST 处理加入了对 RFC 5961 的一项小澄清；它也根据 RFC 3168 更新了 TCP 首部中的控制位。把这份文件说成纯粹重新排版，会抹去其明示的变化。汇总可以收集已有要求，也可以包含有限的澄清；变更清单让两者保持可区分。

一份基础规范装不下所有算法

TCP 的共同互通规则并不等于整个传输层文献。RFC 9293 把拥塞控制、高级丢包恢复和多路径运行等算法指向配套文件。它解释说，基础规范可以与独立开发的多种算法共同使用；有些复杂主题今后也可能各自得到汇总。

RFC 7414 为这批资料提供索引。该路线图由 Martin Duke、Robert Braden、Wesley Eddy、Ethan Blanton 和 Alex Zimmermann 合著。它按作用整理相关规范，包括必须支持的行为、强烈建议的增强和实验性方案。但它是信息性文件：路线图明确说，自己不是规定 TCP 必须实现什么的严格标准，也不应单独左右具体实现决策。阅读指南不能因为方便就自动成为规范要求。

RFC 9293 还用另一种方式方便核对要求：它标注大写的 BCP 14 术语，并在附录 B 汇总实现要求。文件表示，它可以用来检查现有实现或编写新实现。这是预期用途，并不是已发表的合规性调查。规范可以减少读者需要拼接的文件数量，但要判断某个协议栈实际做了什么，仍须检查代码、测试和报文记录。

汇总能带来什么，又不能保证什么

对长期维护传输协议实现的团队来说，拥有一份现行的共同规范，可能减少评审前查找资料的工作。工程师可以定位要求、追踪其引用的解释，再将条款与实现对照。这是由文档结构带来的合理好处，不是 RFC 所测量的时间节省。

运行层面的界线依然存在。现行规范不会证明某个内核、设备或中间盒符合要求，也无法替代对后续扩展、勘误和配套规范的跟进。只写“TCP”或 RFC 793 的评审可能漏掉后续更新；只看 RFC 9293 的评审也可能漏掉某种算法专属的要求。更可靠的做法是记录确切的 RFC 条款和要求，再与所检查的软件版本和测试证据对应起来。

这项编辑工作的启示并不夸张，却能长期适用：汇总可以让共同技术契约更容易检查，但不必假装一份文件就包含所有理由、扩展和实现情况。RFC 9293 署名给 Wesley Eddy 的工作处在这条边界上：汇集规范性基础，标明有限变更，并让解释性记录继续可查。标准整理了实现应当遵循的要求；运行中的代码和测试才说明它实际上做了什么。

参考文献

Heng Lu 的“Running-Code Primacy”札记仅作为编辑视角，用来区分已发布规范与实际部署的软件；它不是关于 Eddy 或 TCP 的事实来源。