摘要

  • 计算机历史博物馆把 1973 年的网络间通信设计与 Vint Cerf、Robert Kahn 联系起来，也把 1977 年三种分组网络环境的联通描述为多个机构和实现者共同完成的试验。[2] [3]
  • 1974 年 12 月发布的 RFC 675 把 Vinton Cerf、Yogen Dalal 和 Carl Sunshine 列为共同作者。它证明了 Cerf 的具体贡献，但不能证明单独发明、单独实现或控制所有参与网络。[1]
  • Jon Postel 在 IEN 2 中主张把互联网分组传递与端到端传输分开。Cerf 的 IEN 48 则描述 catenet 模型，并保留 Louis Pouzin 的概念来源。这些记录说明协议边界经过批评和修订，而不是一次定型。[4] [5] [12]
  • IEN 98 和 IEN 175 记录了 BBN、UCLA、SRI、MIT、UCL、NDRE 等机构的实现工作。可部署性来自多个环境中的运行代码，而不是文档发布本身。[6] [11]
  • RFC 790 维护已分配编号，RFC 791 和 RFC 793 在 1981 年分别记录 Internet Protocol 与 Transmission Control Protocol。台账提供唯一性和共同参照，真实采用与连续运行仍需由实现者和运营者证明。[7] [8] [9]

起点不是“一张网”，而是彼此不同的多张网

早期分组网络并非等待统一接管的一套同质设施。不同项目可能使用不同的分组长度、寻址方式、时延假设、错误处理和本地管理规则。一个在某张网络上运行良好的程序，无法自动理解另一张网络内部的全部约定。

互联网互联要解决的核心问题，是让这些网络保持自身运行方式的同时，仍能在端点之间交换数据。设计必须提供一个共同的分组边界，网关需要在网络之间转发，主机需要处理端到端状态，编号还必须在更大的范围内保持清晰。任何一个环节含糊，独立实现就可能把同一字段解释成不同含义。

计算机历史博物馆的时间线把 Cerf 和 Kahn 放在 1973 年的这一设计问题上，并记录随后跨三种网络环境的试验。[2] [3] 这足以支持一个明确的人物贡献：Cerf 参与了如何让异构网络通过共同协议互联的设计。它不支持“一个人创造了整个互联网”的结论。

更准确的说法也更能解释技术。分组交换、数据报、网关、主机协议和网络间连接都已有更广泛的研究基础。Kahn 是早期设计的关键共同参与者；Postel 参与边界修订和后来的规范、编号记录；Pouzin 与 CYCLADES 构成数据报和 catenet 的重要来源；不同机构的工程人员把文字变成可执行程序。

这种分工并非历史注脚。要让由独立运营者管理的网络互联，设计本身就必须允许多方在同一边界上工作。没有任何人的声望能够替代互操作试验，也没有任何一份文档能够替代真实网关、主机和链路的行为。

因此，评估这段历史时必须区分四种不同的命题：谁参与了设计，谁在公开文档中类型化了边界，谁把规范实现成可运行软件，又是谁在特定网络上运营它。这四个问题有时相互交叉，但绝不等价。时间线可以证明 Cerf 与 Kahn 参与早期构思，却不能代替 RFC 对字段和状态的说明；RFC 可以给实现者一个共同起点，却不能自己产生一次成功的跨网通信。

这种区分也会改变对“部署”的理解。部署不是规范发布时自动发生的事件，而是一系列可检查的转换：主机软件实现了边界，网关能在不同本地网络之间搬运数据报，编号不发生冲突，失败能被定位，不同团队还能在不共享同一套内部实现的情况下相互通信。只有这些结果都有记录，“可部署”才不是一个对名人或文档地位的赞美词。

RFC 675 记录了一个重要阶段，而不是最终形态

RFC 675 的价值首先来自清晰署名。文档把 Vinton Cerf、Yogen Dalal 和 Carl Sunshine 列为 1974 年版 Internet Transmission Control Program 规范的共同作者。[1] 因此可以准确地说，Cerf 共同撰写了一份重要的早期协议规范；不能说他单独定义了其中所有机制。

这份文档讨论网络标识、TCP 标识与端口组合成的 socket，也讨论连接、确认、重传、流量控制、用户接口和一种概念性实现。[1] 它试图让异构网络中的端点获得可靠通信能力，已经足够详细，可以成为实现和测试的共同参照。

但 1974 年文档中的 TCP 仍把后来分开的功能放在同一整体中。若把它直接等同于今天熟悉的 IP 与 TCP，就会抹掉架构变化。真正值得观察的不是一套方案从一开始就完美，而是公开规范让问题可以被其他实现者发现和指出。

文档中的编号模型尤其说明台账为何重要。一个本地进程或端口名，只在本机范围内有效；当多个网络和主机互联时，端点标识必须避免冲突。规范可以定义结构，编号记录则要维护共同含义。两者都不能单独保证真实连接成功。

RFC 675 还涉及授权与冒充风险。[1] 不能把这些早期文字包装成现代安全保证，但可以看出，身份、唯一性和允许谁使用连接从一开始就是同一现实问题的不同侧面。准确编号如果没有实现层的权限检查，仍可能被误用；实现如果没有共同编号，也无法可靠识别远端。

Cerf 的贡献应停留在证据允许的范围：他与 Dalal、Sunshine 共同写作并参与设计。主机软件、网关程序、每个字段的后续修改和所有网络的运营结果，属于其他文档、实现者和运营机构。

Postel 的批评让“可修订”成为架构能力

Jon Postel 的 IEN 2 对早期合并设计提出了关键批评：互联网分组传递与端到端主机传输应该分开。[4] 这不是名称调整，而是重新分配责任。互联网层负责让数据报跨越不同网络，传输层则在端点之间维护可靠通信所需的状态。

边界移动之后，中间网络不必理解每个应用连接的全部细节。端点可以根据共同传输规范处理顺序、确认和重传。互联网层也可以为不同传输协议提供共同的分组服务。这样做减少了所有网络必须共同接受的状态，但同时要求层间接口更明确。

从运营角度看，边界决定故障由谁观察和修复。如果网关承担端到端连接状态，它的失败方式与只转发数据报的网关不同。如果可靠性由主机处理，运营者就需要把“分组是否到达”与“传输连接是否成功”分开检查。

IEN 2 也限制了英雄叙事。最终边界并非由 Cerf 一人完整交付，再由其他人照抄。Postel 公开指出合并模型的问题，设计随后发生变化。[4] Cerf 的贡献仍然重要，但其价值存在于可以被批评、试验和修订的合作过程里。

对今天的技术负责人而言，这是一条可执行原则：允许对协议边界提出有证据的反对意见，并保存修改理由。承认早期边界需要调整，不等于否定整个项目；它说明运行经验已经产生新的信息。

catenet 模型要求保留思想来源

Cerf 在 IEN 48 中描述 catenet，即由多个分组网络连接而成的系统。[5] 这种模型不要求把所有网络改造成同一内部技术，而是要求它们理解共同的互联网数据报和网关边界。

IEN 48 同时保留了 Louis Pouzin 的术语来源。Internet Hall of Fame 对 Pouzin 的介绍也支持 CYCLADES 与数据报、catenet 概念的影响边界。[12] 在使用 Cerf 的文档时保留这条来源，不会削弱 Cerf，反而让技术演进更准确：已有思想被吸收、重组、公开和检验。

catenet 的自治并不等于无需协调。共同分组必须有可理解的格式；网络和协议编号不能冲突；网关必须知道如何处理路径上的差异；主机还要在端到端层面发现丢失、重复或乱序。

因此，注册和编号台账承担一种窄而重要的权威。它记录某个数值在共同空间中的含义，帮助独立实现避免冲突。它并不拥有使用这些数值的机器，也不替代运营者观察路由和服务状态。

同样，Cerf 撰写 catenet 模型，不意味着他运营所有网关、控制 CYCLADES 或对每条路径的连续性负责。[5] 文档提供可测试的结构，真实结果仍由多个系统和运营者产生。

多机构的运行代码让设计面对现实

IEN 98 列出了来自 BBN、UCLA、SRI、MIT、NDRE 等机构的实现报告。[6] IEN 175 又记录了更多实现者、网关、性能和寻址问题。[11] 这些来源把“部署”从抽象名词还原成许多不同环境中的程序和设备。

独立实现的价值，在于它会暴露规范中的隐含假设。两个团队可能都认真阅读同一段文字，却在超时、分组边界、错误处理或状态转换上写出不同程序。只有当它们相互通信时，差异才会变成可以复现的问题。

1977 年跨三种网络环境的演示也应按这个边界理解。[2] 它说明一组协议、网关和主机程序能在当时的试验条件下共同工作。它不证明所有主机已经完成迁移，也不证明互联网从此不会出现性能、安全或连续性问题。

把实现机构写进文章，会让责任更加清楚。规范作者负责公开接口和论证；实现者负责具体代码行为；网络运营者负责本地设备、路由和变更；项目协调者负责目标、资源和协作。角色彼此依赖，但不能因为一个人更有名就合并成一个责任主体。

这正是“运行代码优先”的现实含义。文档不可缺少，因为它提供共同检查点；但只有独立代码和真实链路能显示共同检查点是否足够精确。一次失败也不是项目污点，它可能是发现边界含糊的最有价值证据。

IEN 98 和 IEN 175 之所以重要，不只因为它们列出了多家机构，还因为这些名单暗示了多个实际运行环境。[6] [11] 不同主机的进程模型、内存约束和用户接口会改变协议栈的写法；不同分组网的最大分组、时延和丢失特性，又会让网关遇到不同的边界条件。一个实现在本机环回测试中通过，不代表它在经过另一种网络或遇到另一个独立实现时仍会如预期行事。

故障样本应该保留具体层次。编程错误、规范歧义、底层网络丢包、编号配置错误和网关不兼容，都可以表现为“连接失败”，但修复责任并不相同。如果试验报告只保留最终成功的一次，就会把边界如何变得精确的过程删掉。相反，把每次观察的版本、路径、实现、分组特征和结果留下，才能让后续团队区分“文字被误解”与“代码写错”。

1977 年演示的价值也应从这个角度理解。[2] 它不是一个对所有未来网络的承诺，而是一个有边界的观察：在当时的设备、代码、网关、路径和参与机构组合下，数据能够跨越三种分组网环境。这一结果足以支持继续实现和修订，却不能被扩写成普遍性能、安全性或持续可用性的证明。

RFC 790 把编号唯一性变成共享设施

当互联网层、传输层和应用端口逐渐分开，各层都需要共同编号。不同团队如果把同一数值赋予不同协议，分组即使到达，也会被错误解释。

Jon Postel 编写的 RFC 790 记录当时已分配的网络号、协议号和其他数值。[7] 它的作用不是运行网络，而是提供一份大家可以核对的准确台账。独立实现无需私下猜测同一个数字的含义。

这类台账的权威必须保持边界。记录准确，不代表路由已经存在；分配完成，不代表软件已经配置；编号可查，也不代表使用者拥有永久的运营连续性。反过来，某条路由正在传播，也不能自动证明它与台账、授权和安全元数据一致。

因此，编号基础设施需要同时维护唯一性、准确性、变更历史和安全信息。运营者还要把这些记录与实际配置、路由和流量观察进行核对。台账是现实层的一部分，却不是现实层的全部。

在这一段历史中，也应把贡献归给正确的人。Cerf 的早期规范包含寻址结构，他的项目角色属于更广泛的互联网计划；RFC 790 本身是 Postel 的编号记录。[1] [7] 技术需要两类工作，不能因为文章以 Cerf 为人物线索就把它们合并。

从运营角度看，编号记录是一个“预期状态”。它告诉实现者某个数值应该表示什么，但真实系统中还存在本地配置、路由、过滤、安全对象和依赖程序。运营者必须把记录与这些现象对照，还要保留观察时间。编号可能没有冲突，但配置尚未更新；路由可能存在，但使用方与公开记录不一致。两种情况都不能靠“台账里有一行”就宣告问题已解决。

台账也不应被描述为对网络的所有权。它的正当作用来自可核对的唯一性、准确性和连续性，而不是把实际运营者的职责吸收进一个中心记录。这也是为什么 RFC 790 必须与 IEN 98、IEN 175 一起阅读：前者显示共同数值如何被记录，后者显示独立机构如何在软件与网络中面对这些数值。[6] [7] [11]

1981 年规范固定了更清楚的责任分界

1981 年 9 月的 RFC 791 和 RFC 793 分别记录 Internet Protocol 与 Transmission Control Protocol。[8] [9] 两份文档体现了从早期合并设计到分层边界的变化。

IP 提供跨互联网的数据报传递，处理地址、转发和分片等问题，但不承诺可靠的端到端交付。TCP 在端点之间维护可靠、有序的字节流。两层分开后，其他传输协议也可以使用共同互联网层，中间网关则无需维护每条传输连接的全部状态。

这种分工也改善故障判断。运营者可以分别询问：主机是否形成正确数据报；地址是否有效；网关是否转发；分片是否处理；TCP 是否建立状态、确认数据并在需要时重传。多层仍会相互影响，但诊断不必从一个模糊的“网络坏了”开始。

最终规范再次说明不能把所有字段归给 Cerf。Postel 与 DARPA Internet Program 的文档角色必须保留，早期共同设计、批评和多方实现也共同构成背景。[4] [8] [9] Cerf 的价值不依赖夺取这些贡献。

规范发布日期也不是部署完成日期。每台主机仍需软件，网关仍需配置，组织仍需安排过渡。1983 年 NCP 停止、例外和中继治理属于另一篇文章的证据边界，本文只把它作为后续交接，不重复其论点。

项目协调不是对所有网络的主权控制

RFC 1160 回顾了互联网相关机构，支持对 Cerf 的 DARPA 项目经理角色作有限描述，也记录后续组织和责任变化。[10] 项目经理可以设定目标、协调研究、安排试验和推动问题解决，这些都是可归因的人物贡献。

但项目经理不是所有主机、网关和参与网络的运营者。不同机构保留本地管理权，实施团队控制具体软件，规范编辑者维护公开文本，编号维护者保证共同记录。项目协调能推动合作，却不能替代这些角色。

责任能够移交，恰恰说明基础设施没有停留在个人权威上。规范成为公共参照，编号记录由持续机构维护，代码知识分散到多个团队，运营控制继续属于实际运行系统的组织。

这种制度安排与互联网互联的技术结构相似：共同边界连接独立网络，而不是把它们变成一台由中心控制的机器。协调的合法性来自解决共同问题和留下可复核记录，不来自对全部资源的所有权想象。

可部署性是一条证据链

这些来源组合成一条清楚的证据链。历史资料记录问题与参与者；RFC 675 记录早期详细规范；IEN 2 记录边界批评；IEN 48 记录 catenet 模型与思想来源；IEN 98、IEN 175 记录多机构实现；RFC 790 维护共同编号；RFC 791、793 固定 1981 年分层规范；RFC 1160 记录有限的项目角色与交接。[1]-[12]

任何一层都不能代替其他层。历史时间线不能代替协议字段；规范不能证明代码互通；实现试验不能消除编号冲突；编号记录不能证明真实路由；项目协调不能替代本地运营。

它们结合起来，才说明架构如何成为可部署设施：问题被明确，方案被公开，批评推动修改，多方写出代码，试验暴露差异，台账保持共同含义，修订规范固定接口，责任随后可以跨团队持续。

这条证据链比“互联网之父”一类称号更有解释力。称号只提供地位，证据链说明谁做了什么、哪份文档支持、哪些结果仍未证明。它既能肯定 Cerf 的重要贡献，也能防止把敬意扩大成技术上不准确的控制权。

来源

  1. RFC Editor，RFC 675：Specification of Internet Transmission Control Program。
  2. Computer History Museum，1973 timeline。
  3. Computer History Museum，Internet History: the 1970s。
  4. RFC Editor History，IEN 2。
  5. RFC Editor History，IEN 48。
  6. RFC Editor History，IEN 98。
  7. RFC Editor，RFC 790：Assigned Numbers。
  8. RFC Editor，RFC 791：Internet Protocol。
  9. RFC Editor，RFC 793：Transmission Control Protocol。
  10. RFC Editor，RFC 1160：Internet Activities Board。
  11. RFC Editor History，IEN 175。
  12. Internet Hall of Fame，Louis Pouzin。
  13. Wikimedia Commons，Joi 拍摄的 Vint Cerf 照片，CC BY 2.0。