摘要

  • 1968—1970年的IMP不是现代IP路由器的早期版本，也不是一根“聪明一点的管道”。它是ARPANET内部一个功能厚重、由承包商交付的分组交换子网。BBN对自己交付的IMP硬件、软件和Host–IMP接口拥有真实而具体的实现权威，但RFC 1已经明确显示：ARPANET软件一部分在IMP中，一部分在主机中；BBN规定IMP软件，主机团队则必须就主机软件达成协议。采购权、交付实现、接口权威与未来网络架构的授权因此从一开始就不是同一件事。
  • IMP把大量可靠性放入共同网络，却没有消除端点责任。早期RFC记录了分段、校验、重组、逻辑链路、跟踪、RFNM流量控制以及Host–IMP缓冲与多路复用等机制，同时也明确暴露了边界：拥塞控制仍要求主机合作，链路状态、确认、远端主机状态和更高层语义仍需要主机维护。后来NCP把“一个可靠ARPANET”当作前提，当需要连接分组无线电、卫星和其他独立设计的网络时，这个前提不再足够。开放架构互联随后把可恢复通信更多地移回源端，并把网关收窄为连接独立网络的黑箱式转发者。
  • 由此产生的历史教训不是“基础设施越少越好”，而是必须区分“局部有用”与“完整正确”。一个共享层功能可以提高性能、降低重复工作、缓和某些故障，却不因此获得对应用正确性的最终裁决权。后来端到端论证把这一点形式化：如果某种正确性依赖应用自身才知道的信息，网络内部机制最多只能帮助，最终完整检查仍必须由端点参与完成。
  • 同样的边界也适用于制度权威。ARPA能够采购，BBN能够按照合同交付和运行IMP，接口规范可以约束互操作，但这些事实本身并不构成一份无限期授权，使承包商、接口维护者或网络中介天然拥有主机软件、应用规则或未来独立网络的决定权。历史证据支持的是一种窄授权原则：权威应跟随实际被采购、实现、接口化和运行的功能，而不应因为某一中介曾经对共同基础设施有用，就自动扩大成永久性的架构主权。

一、在互联网之前，先出现的是一条责任线

回看ARPANET最容易犯的错误，是从后来互联网的形状倒推1969年的系统，把IMP想成今天路由器的幼年形态，再把主机想成已经运行着现代端到端协议的计算机。这样看，历史会显得过于顺滑：早期有“路由器”，后来出现TCP/IP，于是一切自然演化。

实际材料显示的结构更有张力。

ARPANET最初并不是让每一台大型主机直接承担完整的分组交换职责，而是在主机之外部署专用的Interface Message Processor，即IMP。主机通过规定好的Host–IMP接口接入由IMP组成的交换子网。1968年，BBN赢得ARPANET相关合同，并把Honeywell 516改造成IMP。到1969年，第一批主机团队必须配合BBN的交付节奏完成接口和主机软件；Steve Crocker后来回顾，第一台IMP预定于1969年9月交付UCLA，而各站点并不能等设备到场之后再决定如何接入，它们必须提前把主机侧的工作做起来。

这里已经可以看到四种经常被后世混在一起的权力。

第一种是采购权。ARPA可以决定采购一个专门的分组交换子网，可以签合同，可以规定交付目标和时间。这是真实的制度力量，没有采购、资金、设备和进度，ARPANET不会因为一份学术构想而自动出现。

第二种是交付实现权。BBN不是只写一份建议书。它要把机器做出来，把软件跑起来，解决重载、调试、恢复、线路切换和可靠性问题。Frank Heart的回忆尤其说明，IMP的工程重点不是抽象地“转发比特”，而是让一台现场设备在现实线路、现实故障和现实维护条件下持续工作。运行中的实现因此拥有一种文档之外的权威：它决定了当时网络实际上能做什么。

第三种是接口权威。Host–IMP边界必须被明确到足以让不同主机团队分别实现。如果接口模糊，每个站点都要猜测BBN设备的内部行为；如果接口改变而没有协调，主机软件就会失效。因此接口本身是一种共同约束。

第四种才是架构授权：谁有权决定主机之间如何建立更高层通信？谁决定应用语义？谁决定未来出现另一张独立网络时，互联应遵循什么模型？

现有史料恰恰没有支持把前三者自动等同于第四者。

RFC 1的意义就在这里。它不是一份宏大的“ARPANET宪法”，而是一份非常早期的工作笔记，却把责任分割写得异常直白：ARPA Network的软件一部分存在于IMP，一部分存在于主机；BBN规定IMP软件，而各主机小组负责对主机软件达成一致。

这不是今天回头创造出来的“去中心化”神话。相反，它说明ARPANET一开始就非常依赖中心采购和一个强大的共同子网，同时又没有把“负责共同分组交换”解释成“负责所有网络通信”。

这条线，是理解后来互联网架构的真正起点。

二、IMP绝不是空管道

如果只强调主机自主，很容易走向另一个错误：仿佛IMP只是把字节从一边送到另一边，真正的网络都发生在主机中。

早期RFC显示，事实完全不是这样。

RFC 1描述的IMP服务包含相当多的机制。消息最大可到8,080位，IMP会把消息分割成不超过1,010位的分组，在传输过程中使用24位循环校验，并在目的IMP处重新组装。它维护逻辑链路，提供跟踪能力，并通过Request for Next Message，也就是RFNM，形成一种发送节奏和流量约束机制。

后来RFC 7进一步记录Host–IMP一侧的多路复用、缓冲处理和接口工作。RFC 528则反映出，随着系统运行，IMP软件的校验和网络可靠性依旧是持续的工程关注点。

因此，把IMP描述成“早期互联网里一个愚笨的核心”是不准确的。

它承担的至少是三类共同职责。

第一类是传输机械性工作。主机不必自己知道一条长消息如何被切成若干分组、如何逐跳前进、最后如何在目标一侧重新拼回消息。把这类机制放入子网，显然减少了每个站点重复实现的成本。

第二类是共同可靠性工作。校验、重组、恢复和设备运行可靠性不是附属品，而是当时系统能否工作的前提。Heart后来强调的调试、重载以及线路交叉切换，说明“可靠网络”首先是一套需要工程团队持续维护的运行现实。

第三类是共同可观察与约束工作。跟踪机制让网络行为可以被观察，链路和RFNM则帮助限制发送节奏以及某些拥塞形态。一个不能观察、不能缓冲、不能约束输入速度的分组网络，很难在当时主机性能和线路条件下稳定运行。

换句话说，ARPANET并没有从“边缘智能、核心极薄”的教科书图形开始。它先建立了一个能力相当强的共同网络。

问题也正是因此变得有价值：一个共同网络做了这么多之后，它还缺什么？

三、一个很强的网络，仍然不知道主机知道的事情

RFC 1和RFC 2留下的一个重要证据，是IMP功能越丰富，责任边界反而越清楚。

以拥塞为例。RFC 1描述的逻辑链路安排能够限制一部分拥塞问题，却也指出，目的IMP并没有能力同时处理所有可能链路，因此主机必须合作。

这个细节很关键。

网络设备可以拥有缓冲区，可以知道某条线路是否忙，可以知道自己当前能否继续接收某些消息；但它并不知道一个应用是否应该继续发送，也不知道某个高层会话是否可以放慢，更不知道某个应用级动作失败之后应该如何恢复。

RFC 2同样显示，主机软件需要维护链路状态、进行检查和确认，并处理远端主机状态。网络内部可以提供机制，却不能凭借内部观察自动拥有完整的端点语义。

这里第一次出现了后来端到端论证会系统表达的那个问题：功能可以被向下搬，但知识不能凭空出现。

如果一个判断只依赖交换节点自己可见的信息，那么把它放入交换层是合理的。

如果一个判断依赖端点状态，就必须让端点参与。

如果一个判断依赖应用语义，那么网络内部即使做了同名功能，也可能只能提供不完整版本。

早期ARPANET当然没有用后来Saltzer、Reed和Clark的语言表达这一点。把成熟的端到端原则投射回1969年，会制造一种并不存在的历史自觉。第一批RFC是工程工作笔记，不是后来互联网架构原则的预告片。

但是，后来的理论之所以有解释力，正因为早期系统已经把这个事实暴露出来：共享基础设施可以提高可靠性，却无法替代只有通信端点才能完成的验证。

四、NCP的真正限制，不是它“太老”，而是它信任了一张网络

当ARPANET仍然是一张由IMP构成的网络时，把很多可靠性工作放在网络里是可以成立的。

NCP的设计建立在这个环境上。Internet Society的历史材料指出，NCP依赖ARPANET提供端到端可靠性，并且它的寻址能力停留在目的IMP这一层级。它不是为“网络的网络”设计的协议。

在单一ARPANET中，这一假设有现实基础。

所有主机都接到同一种IMP子网上。

共同网络具有统一的交付模型。

可靠性问题可以在同一个运营和协议环境内被处理。

目的地可以通过ARPANET内部标识方式理解。

在这样的系统里，“网络保证足够多的可靠性，主机协议在此之上工作”并不荒谬。相反，它是一个可以运行的工程分工。

真正的问题出现在新的网络被纳入视野之后。

分组无线电网络并不是ARPANET的另一个站点。

卫星网络也不是换一种线路的IMP。

这些网络可以有自己的分组大小、时延、丢失特性、介质约束、故障模式和内部控制方式。如果互联架构要求它们先变成ARPANET，所谓“互联”实际上就是同化。

这正是开放架构问题的起点：能不能让每张网络继续作为自己的网络存在，同时仍然与其他网络通信？

一旦答案是“可以”，NCP所依赖的那个可靠共同网络就消失了。

不是网络不再需要可靠性。

而是没有任何一张底层网络有资格假定，它能替所有其他独立网络提供同一种端到端可靠服务。

五、开放架构不是削弱网络，而是拒绝让任何一张网络成为全部网络

后来开放架构互联提出的关键条件，可以看作对单一可靠网络假设的结构性修正。

独立网络应当能够维持自己的内部设计。

互联层按照尽力转发工作，而不是要求底层为整个端到端会话提供统一可靠性。

如果数据丢失，需要由源端重新发送。

连接网络的网关应尽量像简单的黑箱，不依赖维护每条端到端会话的复杂状态。

这些条件共同完成了一次责任迁移。

原来在一个ARPANET内部，可以假定网络提供某种完整的可靠交付环境。

到了互联环境，任何一条跨网络路径都可能穿过多个具有不同失效模型的系统。若一个中间网络保存了大量端到端恢复状态，而该网络或网关发生故障，这些状态本身就会成为恢复障碍。

把可恢复性重新放回端点，意义不只是“端点更聪明”。

更重要的是，端点是跨越全部路径后仍然存在的那两个参与者。

一个中间网关只见到路径的一部分。

一张独立网络只控制自己的区域。

源端和目的端才知道通信是否真正完成。

于是，恢复责任从“某一共同网络保证完成”变成“底层尽力交付，端点判断是否需要恢复”。

这是一种更适合异构性的分工。

RFC 675记录了1974年的早期Internet Transmission Control Program。它属于后来的互联阶段，不能反过来被当成1969年ARPANET已经遵循的原则。但它说明架构问题已经改变：讨论对象不再只是“如何在ARPANET主机之间通信”，而是“如何让不同网络之间形成可恢复的互联网通信”。

这就是从网络到互联网最重要的语义变化之一。

六、端到端原则真正反对的，是“错误位置上的完整性幻觉”

Saltzer、Reed和Clark后来形式化提出的端到端论证，经常被压缩成一句口号：“网络应该简单，功能都放在边缘。”

这不是材料所支持的准确理解。

端到端论证的核心不是位置偏好，而是完整正确性的放置检验。

如果一个功能只有应用端点掌握全部必要知识，那么只有端点参与，才能把这个功能完整而正确地实现。

网络内部仍然可以实现一个较低层版本。

而且这个版本可能非常有价值。

它可以减少错误。

它可以降低重传成本。

它可以改善平均性能。

它可以在大量常见情况下提前发现问题。

但它的地位是“性能增强”或“局部可靠性机制”，而不是“因为网络已经做了，所以端点无需再验证”。

文件传输是这种逻辑最直观的抽象例子。链路校验可以发现线路错误，分组校验可以发现某些传输损坏，中间节点可以重传局部丢失的数据。但如果真正需要确认的是“接收端最终保存的文件是否与发送端要求的对象完全一致”，这个判断涉及发送端和接收端看到的最终对象。中间网络无法替代这个验证。

因此，端到端原则并不要求删掉校验。

它要求准确说明校验能证明什么。

它不要求网络不做流量控制。

它要求区分局部队列管理与应用是否已经正确完成。

它不要求核心无状态。

RFC 3439后来讨论最小化IP层时，也没有主张互联网核心可以没有路由、转发、测量和粗粒度状态。一个能运行的核心必然有技术状态。

真正应避免的是另一类状态：那些只有应用语义才能正确解释，却被放入所有参与者都必须经过的共同层中的状态。

七、IMP因此留下的不是“厚核心失败”，而是一场边界实验

如果用后来互联网的结果去评价IMP，容易得出一种过度简单的结论：ARPANET把太多功能放进网络，后来互联网把功能搬到端点，所以历史证明“厚核心错了”。

这种说法不符合史料。

IMP成功完成了大量当时极其重要的工作。

它把分组交换从每台大型主机的独立工程任务中抽离出来。

它给不同站点提供了统一接入边界。

它把可靠性、调试和线路处理集中到专门系统。

它让主机团队能够围绕共同Host–IMP接口分别工作。

更重要的是，这个系统真的被采购、制造、交付、安装和运行。

从实际部署记录看，这一点不应被制度理论抹掉。一个没有实际机器、没有接口、没有现场维护、没有交付进度的网络，不会因为拥有更纯粹的分层原则就产生现实互操作。

IMP的历史价值恰恰在于，它把共同层真正做厚之后，让边界问题从思想实验变成运行问题。

哪些事情放进去以后明显有用？

哪些事情即便放进去，主机仍然要做？

哪些共同机制适用于一张统一网络，却无法自然扩展到多张独立网络？

一旦这些问题被现实系统暴露出来，后来的开放架构才有对象可修正。

因此，更准确的历史关系不是“IMP架构被互联网推翻”。

而是：互联网从IMP时代学会了怎样把共同基础设施的能力限制在它真正能够保证的范围内。

八、运行中的实现为何重要，但为什么它仍不是永久授权

这段工程史还有一个容易被忽略的制度维度。

BBN拥有的权威是真实的。

它赢得合同。

它交付设备。

它定义和维护IMP软件。

它处理现场可靠性。

主机团队必须按照Host–IMP边界接入。

如果BBN的实现与接口行为出现问题，ARPANET就可能无法运行。

这绝不是一个可以被描述成“只是承包商，所以没有权威”的角色。

但恰恰因为这种权威非常真实，才需要说清它的边界。

采购权回答的是：“谁被授权交付这项能力？”

实现权回答的是：“实际运行的系统如何完成这项能力？”

接口权威回答的是：“独立参与者必须遵循哪些共同技术约束才能接入？”

架构授权则回答：“谁有权决定未来哪些功能必须共同、哪些决定必须由所有参与者接受？”

前面三个问题有明确证据。

第四个问题没有因为前三个问题的存在而自动获得答案。

RFC 1反而提供了相反方向的线索：即使IMP由BBN规定，主机软件依旧是主机小组自己的共同工作。

因此，从现有材料可以推出的制度结论必须保持克制。

不能说ARPANET已经拥有一套关于限制机构权力的正式宪制。

不能说当时参与者都在有意识地遵守后来形成的模块化或自愿采用原则。

也不能说承包关系不重要。

能够说的是：现实权威与功能边界是对应出现的。

BBN的权威最强的地方，正是它实际构建和运行的IMP。

而当问题离开IMP内部实现，进入主机软件和应用知识时，这种权威自然变弱。

历史并不需要一份正式宣言，才能让这种边界显现。

运行系统本身已经在分配责任。

九、最小共同层并不等于最少工程

“最小共同层”这个概念如果被误读，很容易变成一种技术浪漫主义：只要把东西尽量赶出核心，系统就会自动开放。

IMP史并不支持这种想法。

一个可互操作系统必须有足够严格的共同部分。

接口格式必须明确。

分组如何被识别必须明确。

共同状态如何被解释必须明确。

错误如何被检测必须明确。

不同实现之间哪些行为必须一致，必须明确。

路由和转发必须存在。

安全相关的共享不变量必须存在。

真正需要最小化的，不是规范精度，而是被强制共同化的决策种类。

由此可以得到一条设计纪律：共同层应该严格规定那些若不共同就无法互操作的确定性条件，而不是把未来所有可能有争议的选择预先塞进共同底座。

IMP和Host–IMP接口提供了一个早期实例。

主机必须知道如何与IMP交互。

这部分不能每家随意理解。

但主机内部如何组织更高层协议，并没有因为IMP接口存在就全部转交给BBN。

后来开放架构进一步扩大了这种思想的适用范围。

独立网络不需要因为互联网互联而放弃自己的内部设计。

互联网需要的是足以连接它们的共同语义，不是把每张网络内部变成同一种网络。

十、真正的风险不是中介存在，而是中介变成无法绕开的语义拥有者

这段历史今天仍有意义，并不是因为我们还在使用IMP，而是因为网络系统反复面临同一类诱惑：一个中间层功能一旦证明有用，就希望让它继续积累状态、判断和政策。

安全功能可以进入中间层。

身份判断可以进入中间层。

应用状态可以进入中间层。

策略执行可以进入中间层。

流量优化可以进入中间层。

其中许多功能都可能有合理工程价值。

历史提出的检验并不是“中间层能不能做”。

而是三个更严格的问题。

第一，它是否拥有完成该判断所需的全部知识？

如果最终正确性取决于端点或应用知道的事实，中间层无法因为自己离流量更近就获得这些知识。

第二，它是局部帮助，还是系统唯一裁判？

一个可选的缓存服务、加速器、过滤器或安全增强，可以显著改善性能。但一旦它成为所有通信都必须经过、所有状态都必须由它确认的唯一位置，原本的工程优化就获得了制度性后果。

第三，参与者还能否独立验证、替换或绕开它？

只要接口充分明确，多家实现就可以替代同一功能。

如果接口逐渐退化为“相信这一家服务返回的状态”，技术依赖就变成了控制依赖。

这正是IMP史最值得保留的一条边界：一个共同中介可以非常重要，可以是网络成立的前提，甚至可以在现实中比任何单个端点都更可靠；但它的重要性本身不能证明，它应该拥有所有后续语义。

十一、从单一可靠网络到可替换的共同底座

NCP的困难揭示了另一种集中风险：不是机构垄断，而是架构假设垄断。

当所有参与者都依赖同一张可靠网络时，很多问题看起来已经解决。

一旦网络异构，隐藏在共同基础设施内部的假设才会暴露。

如果可靠性只能由ARPANET式服务提供，那么其他网络必须模仿ARPANET。

如果地址只能表达目的IMP，那么新网络无法保持自己的命名和内部结构。

如果网关要维护大量端到端会话状态，那么网关失效会破坏跨网络恢复。

开放架构的突破在于，不再要求所有网络继承同一组内部假设。

共同层因此变得更窄，但其覆盖范围反而变得更广。

这是一个重要的经济与制度逻辑。

厚共同层通常能够降低短期异质性成本。

大家不需要重复实现。

统一运维更容易。

错误模式更可控。

但共同层越厚，加入者需要接受的假设就越多。

当参与者高度同质时，这是规模经济。

当参与者开始异构时，同样的结构会变成进入成本。

开放架构选择的是另一种成本结构：把更多恢复和差异处理交还端点与独立网络，换取共同层能够跨越更多实现、更多介质和更多运营主体。

互联网的可扩展性因此不仅来自包格式。

它还来自减少“所有参与者必须同意的事情”。

十二、何时应该把功能放在共同基础设施中

从IMP到端到端论证，可以提炼出一个比“核心薄、边缘厚”更实用的放置方法。

若一个功能满足以下条件，它更可能属于共同底座：

它维持所有参与者都必须共享的互操作不变量；

它可以只依据共同层可见的信息被正确执行；

如果每个端点分别实现，重复成本非常高；

它的失败不会让端点失去独立判断最终正确性的能力；

它能够通过公开接口被多个独立实现替换；

参与者可以观察其状态并验证关键结果。

反过来，如果一个功能需要应用语义、用户意图、商业关系或只有端点知道的状态才能最终判断，它就不适合成为唯一的共同裁决层。

这并不排除在网络内部放一个辅助实现。

真正重要的是保留端点的最终检查能力。

这正是端到端论证中最容易被忽略的细节：低层实现不是错误，只要人们不把它误认为完整性证明。

十三、采购最容易制造一种“权威延伸错觉”

1968年的合同也给现代基础设施管理提供了另一层启示。

采购方通常需要挑选一个供应商。

供应商需要做出真实产品。

产品需要接口。

接口需要被生态系统采用。

这条链条很容易在长期运行中产生一种错觉：既然某个参与者最初被选择来实现共同能力，它就天然适合继续决定该能力以后如何扩张。

但采购只能证明当时的交付授权。

它不能单独证明未来功能的架构必要性。

运行成功也只能证明某种实现曾经有效。

它不能证明后来所有参与者都必须持续接受同一个实现者的扩展判断。

接口被广泛使用，说明协调成本已经围绕它形成。

这仍然不能证明接口维护者拥有接口之外的应用权力。

如果把这些层次混为一谈，最初为了降低协调成本而设立的中介，就可能因为已经成为基础设施而不断扩大自己的范围。

IMP史之所以具有约束力，正在于我们知道BBN的工程贡献有多重要。

只有承认这种重要性，才能认真回答：重要到什么程度，才算越过原有边界？

答案不是依据机构身份。

应当依据功能。

十四、现实实现：规范必须接受实际系统的检验

实现记录最有价值的地方，不是把1969年的工程师重新描述成今天某种制度理论的先驱，而是迫使后来者以实际运行结果检验架构主张。

什么让IMP成为现实？

不是一份声明说ARPANET应该存在。

而是合同、Honeywell 516、BBN软件、线路、接口、主机团队、调试、安装和实际运行一起构成了一套可工作的系统。

同理，后来互联架构之所以成为现实，也不是因为文档宣布“开放架构优于单一网络”。

新规则必须被实现。

网关必须运行。

端点必须重传。

不同网络必须真的互通。

参与者必须接受这些实现产生的兼容关系。

这给“架构授权”设下了一个很高的门槛。

一项后来的扩展不能仅因为被某个既有机构发布，就自动获得和原始共同底座相同的正当性。

它首先需要回答：这是不是维持互操作所必需的共同规则？

如果不是，它是否可以作为可选扩展存在？

不同参与者是否可以拒绝，而不破坏其他仍然兼容者之间的运行？

多个实现是否仍然可能？

状态能否被本地验证？

如果这些问题没有答案，扩张就可能不是技术必需，而是把已有协调位置转化为未来控制位置。

这不是说标准制定、文档或协调组织没有价值。

它只是恢复一条ARPANET时代已经可以观察到的简单边界：定义某个接口，不等于拥有接口之外的一切。

十五、端点自治的代价是真实的

任何把责任移向端点的设计，都不能只描述自由，而忽略成本。

如果共同网络承担更多可靠性：

端点实现可以更简单。

错误处理可以集中。

运维经验可以积累在更少的位置。

共同服务可以提供更一致的性能。

某些故障甚至可以在端点意识到之前被网络处理。

如果责任移向端点：

每种实现需要承担更多恢复逻辑。

不同端点质量可能差异很大。

错误更容易以不同形式暴露。

互操作测试成本会上升。

升级也可能形成多个兼容集合。

互联网选择端到端方向，并不是因为这些成本不存在。

它是在异构互联条件下判断，另一类成本更危险：如果所有可靠性都依赖一个共同网络模型，那么新网络必须放弃独立性；如果全部会话状态都保存在中间网关，那么中间失效会破坏恢复；如果应用正确性必须相信共享层，那么端点就无法独立判断通信结果。

因此，端点自治是用实现复杂度换取替代性和跨网络生存能力。

这是一笔架构交易，而不是道德选择。

十六、最难逆转的不是设备，而是共享层中的语义状态

硬件可以替换。

线路可以切换。

一个IMP也可以重新加载。

真正昂贵的锁定往往来自共享层积累的语义状态。

如果共同中间层只转发数据，替换它主要是接口和运行问题。

如果它同时保存用户身份、应用授权、策略历史、商业资格、会话语义和执行结果，那么替换它会要求迁移越来越多只有该中间层能够解释的状态。

此时，基础设施不再只是“帮忙”。

它成为系统记忆。

一旦所有端点都依赖这段记忆，制度权威甚至不需要被正式授予。它会从切换成本中自然长出来。

IMP时代的共同状态相对接近网络运行本身：链路、分组、缓冲、跟踪、交付。

端到端原则后来给出的重要警告，是不要因为一个中间层能够看到数据，就把应用完整性也一起交给它。

对今天的架构来说，同样应该问：某项新增状态究竟是共同转发所需要的，还是某种应用、身份、商业或政策判断？

如果是后者，把它永久嵌入共享网络层会产生比性能收益更长期的控制后果。

十七、接口的真正价值，是允许实现更换

ARPANET的Host–IMP接口不仅让主机接上网络。

它还把IMP内部实现与主机工作隔开。

主机团队不需要重写BBN内部交换程序。

BBN也不需要决定每一种主机操作系统内部如何组织应用协议。

一个好的接口因此同时完成两件事：

它创造依赖。

也限制依赖。

参与者必须依赖接口定义。

但它们不必依赖接口另一边所有内部细节。

这正是基础设施可替代性的核心。

如果今天一个系统声称有“开放接口”，真正应监测的不是是否存在API文档，而是一个更严格的问题：仅凭这个接口，另一种独立实现能否取代现有服务，而不需要获得原服务提供者的额外许可、隐藏状态或政策认可？

如果答案是否定的，那么所谓接口可能只是接入表面，不是架构边界。

IMP史提供了一种更强的接口观：接口不是把一切统一起来，而是使两边可以分别承担不同责任。

十八、历史证据证明了什么，又没有证明什么

到这里，需要重新收紧结论。

可以确定的是：

1968年BBN获得了ARPANET相关合同，并把Honeywell 516改造成IMP。

1969年的交付计划迫使主机团队围绕Host–IMP接口并行工作。

RFC 1明确区分IMP软件与主机软件的责任。

IMP承担了分段、重组、校验、链路、跟踪和流量约束等功能。

主机仍需要参与拥塞处理、维护状态、确认和更高层通信。

NCP建立在ARPANET能够提供可靠服务的假设上，并没有为独立网络间互联提供足够模型。

开放架构互联后来要求独立网络保持自身、网关更简单、互联层按尽力方式转发，并让源端承担重传。

端到端论证进一步形式化说明：需要应用知识的正确性功能，不能仅靠低层完成。

同样需要明确，材料没有证明：

ARPANET参与者在1969年已经自觉奉行后来成熟的端到端原则。

第一批RFC构成了一份完整的制度宪章。

所有ARPANET合同指令、争议和内部实施决定都已经保留下来。

BBN的贡献可以被描述为“独自发明分组交换”。

薄核心等于无状态、无管理或无可靠性机制。

一个中介因为不是端点，就天然不合法。

从事实到制度结论之间，还存在一层编辑推论。

这层推论应当明确标识，而不是伪装成历史原话。

推论是：当一个共同中介的权威来自其实际交付的功能时，最稳妥的架构纪律是让其权威停留在该功能及其必要接口之内。

IMP史没有证明这是一条法律。

但它展示了违反这条纪律会产生什么技术压力：共同层承担越来越多它无法独立完成的正确性判断，独立网络必须接受越来越多共同假设，而可替代接口逐步变成依赖单一中介的状态入口。

互联网后来之所以能够跨越ARPANET，不是因为它否定了IMP。

而是因为它拒绝让任何一个IMP式共同网络成为所有未来网络必须服从的世界模型。

十九、真正被继承的，是边界，而不是盒子

今天已经没有必要把IMP当作现代互联网设备的直接模板。

它运行在IP之前。

它处理的是ARPANET内部的分组交换。

它承担了后来互联网核心不会以同样方式承担的一部分可靠性。

它也产生于一种集中采购、有限站点和特定主机环境。

但它留下了比具体设备寿命更长的东西：共享网络与使用网络的主机之间必须有一条能被解释、能被实现、能被检验的责任边界。

后来NCP遇到异构网络时，旧边界不再适用。

互联网没有因此取消边界。

它重新画了一次。

独立网络保留内部自由。

网关负责跨网转发。

互联层减少对单一底层可靠模型的依赖。

端点重新承担可恢复通信。

应用最终检查依赖自身知识的正确性。

这次重画之所以重要，是因为它让基础设施仍然可以很强，却不必成为所有更高层语义的所有者。

二十、互联网最深的扩展能力，来自允许“不共同”

互联网架构通常被赞美为“开放”。

如果把开放理解为任何人都可以发表意见，这个词没有多少技术含义。

IMP到开放架构的历史给出的是一种更严格的开放。

独立网络可以拥有不同内部设计。

端点可以拥有不同实现。

共同层只要求那些维持互操作所必须的条件。

后来的变化需要通过实现和采用进入运行现实。

没有必要为了维护一套单一机构或单一网络的完整世界模型，而把所有参与者未来的选择都提前共同化。

这种“允许不共同”的能力，才使系统能够容纳未知参与者。

它也解释了为什么一个看似高效的基础设施功能必须被不断追问边界。

共同层每增加一个应用特定状态，都在增加参与者必须共同接受的东西。

每增加一个不可替代判断，都在增加退出成本。

每把一个可由端点独立验证的事实改成“必须相信中间层”，都在把技术协调转化为制度依赖。

1969年的IMP并没有回答今天所有问题。

但它留下了一个仍然有效的判断方法。

先问系统为了运行究竟需要什么共同功能。

再问这项功能实际能看见什么信息。

再问它能完整保证什么。

再问端点是否仍然能够验证、恢复和替换。

最后才问，负责这个中间层的人或机构应该拥有什么范围的权威。

顺序不能反过来。

基础设施可以先成为必要工具，再因为工具重要而被解释成永久裁判；也可以像互联网后来所做的那样，把共同能力保持在可运行、可验证、可替换的边界内。

IMP的真正遗产，不是一台早期分组交换机。

而是互联网在成为互联网之前，就已经遭遇了那个以后会一再出现的问题：

一个共同层应该帮所有人做多少事，才不会开始替所有人决定他们自己的事？

来源与证据边界

https://www.rfc-editor.org/rfc/rfc1.html

https://www.rfc-editor.org/rfc/rfc2.html

https://www.rfc-editor.org/rfc/rfc7.html

https://www.rfc-editor.org/rfc/rfc528.html

https://www.rfc-editor.org/rfc/rfc1000.html

https://archive.computerhistory.org/resources/access/text/2012/11/102706168-05-01-acc.pdf

https://archive.computerhistory.org/resources/access/text/2017/11/102702222-05-01-acc.pdf

https://www.internetsociety.org/internet/history-internet/brief-history-internet/

https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/

https://datatracker.ietf.org/doc/html/rfc675

https://groups.csail.mit.edu/ana/People/DDC/ebook-arch-V1.pdf

https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

https://www.rfc-editor.org/rfc/rfc3439.html