摘要

  • RFC 1263 于 1991 年 10 月作为信息类备忘录发布。它反对当时 RFC 1072 与 RFC 1185 所提 TCP 兼容扩展的做法，主张不要把每一种新需求都继续挤进同一个 TCP 报文头，而应为协议演进设置清楚的版本边界。
  • 兼容性可以让更新逐步扩散，不必所有节点同步切换；但这并不代表变化没有成本。RFC 1263 的判断是，成本可能被藏进单一协议不断增长的复杂度。它提出的是设计假设，没有证明自身方案曾被实现或部署。

报文头之外，还有一张账单

RFC 1263 的标题像是在否定扩展本身；更值得读的是它追问变化由谁、在哪里付费。沿用旧格式，把新行为装进选项区，看上去可以避免破坏兼容性。可是工作并未消失：能力协商、解析分支、有限选项空间、不同扩展的组合，以及长期维护规则，都可能成为新的负担。

备忘录比较三种路径：创建新协议、在保持兼容的前提下扩展旧协议，或者不再保留旧线格式而演进协议。新协议需要接口，也要等足够多的参与者采用。兼容扩展可以随着各系统自身节奏传播，不必一次性同步分发。更自由的演进则需要明确处理版本切换。

作者并没有说兼容性毫无价值。他们提醒读者，不要把兼容带来的便利误认为变化免费。写入一个报文头很容易，理解并维护不断累积的选项与组合却可能很难。两种版本也未必意味着两套互不相关的设计；共享的基础设施可以负责选择端点应该使用哪一种。

TCP 是论证的样本

RFC 1263 讨论的是 RFC 1072 和 RFC 1185 中针对高时延、高速路径的 TCP 提案。RFC 1072 讨论窗口扩大、选择性确认和回显时间戳；RFC 1185 研究高速路径扩展。RFC 1263 争论的不只是这些功能是否有用，而是应该怎样把它们装进 TCP，同时维持兼容。

它提出的替代方案，是使用更大的、但结构更清楚的报文头，并加入协议标识来区分 TCP 版本。草案将序列号与确认号扩到 64 位，将窗口扩到 32 位，还加入回显字段。用不到新能力的系统可以继续运行现有 TCP；需要它的端点则通过协议选择层启用新版本。

作者给出了多个兼容程度不同的方案：旧 TCP 完全不动，单独使用版本选择机制；在 SYN 交换中协商 TCP VERSION 选项，以满足坚持单体协议的设计偏好；或者把新增信息塞入选项，尽量保留原报文头形状。兼容得越多，旧限制带进新设计的部分也越多。

网络或许早已在维护两个版本

RFC 1263 直接提出一个判断：许多系统很可能最终仍须同时维护两个 TCP 版本。于是选择并非简单的“一个协议还是两个协议”，而是让一个协议承载越来越多条件分支，还是明确划出版本界线，由基础设施选择适用的一版。

作者认为，维护两个简单协议可能比维护一个复杂协议便宜；代价之一是保留两份协议代码所需的内存。这些都是设计判断，不是实测结果。备忘录没有给出真实系统上的实现成本比较，也没有证明版本选择或新协议分发的费用会更低。

兼容确实可以让旧系统继续工作，同时让新功能逐步扩散。但兼容方案也有自己的运行面：协商、解析规则、有限的选项字节、扩展之间的相互作用以及长期实现责任。显式版本边界能让责任更清楚，也会增加选择、分发和支持工作的成本。

新边界只是重新安排协调

版本选择机制并不能消除协调。它要知道有哪些版本可用，两端必须找到共同版本，旧端点也不能收到自己看不懂的报文。版本标识让协议软件看见区别，却不能证明中间设备和网络运营者一定能正确处理它。

RFC 1263 的主张是，应将这些成本与复杂兼容扩展的维护负担摆在一起比较。作者希望把协议分发变成可重复改进的基础设施，而不是罕见到只能藏在现有协议内部的事件。这里讨论的不只是位字段，也包括工程组织与制度激励。

不过，这不是中立的成本模型。作者偏好更简单、演进更快的设计，并尖锐批评当时的标准化流程。文中没有证明标准化程序是变化的决定性障碍，也没有证明自己的分发机制会更有效。它留下的问题更耐久：当兼容性承诺“不需要协调”时，协调和维护成本究竟转给了谁？

文献能够证明什么

RFC 1263 属于信息类文档。它比较协议创建、兼容扩展和协议演进，并评论当时的方案；它没有发布一个最终 TCP 标准，没有记录迁移完成，也没有确认版本选择层已部署或量化多套协议栈的维护成本。扩大后的报文头与版本选择方案在这份文本里仍是提议。

历史教训不是“向后兼容必然有害”。兼容可以让旧系统在新能力扩散时继续使用。但熟悉的线格式不是容纳未来所有需求的免费空间。版本边界可以把责任显化，却不会单独决定哪种架构成本更低。

来源与限制

本文依据 RFC 1263《TCP Extensions Considered Harmful》、RFC Editor 文档记录、RFC 1072《TCP Extensions for Long-Delay Paths》 和 RFC 1185《TCP Extensions for High-Speed Paths》。这些一手材料支撑协议变化方式的比较、被讨论的 TCP 提案、版本选择方案，以及作者关于复杂度、内存和分发成本的论述。

这些来源不能证明 RFC 1263 的替代方案曾被实现、被互联网社区选中、在实践中更便宜，或决定了后来的 TCP 设计。兼容性可能将成本转移到复杂度，是备忘录的论点和本文对其设计比较的解释，不是实测成本。