摘要

  • Ginny Strazisar 在 BBN 编写并跨站部署早期网关软件；PDP-11、驱动、本地接口和安装顺序都必须真正对上，三种异构网络才可能完成端到端传输。
  • 留存史料把“已经安装”“实际经过”和“能够长期运行”分得很清楚，还保留了 1977 年演示日期的矛盾；这比一条圆满的英雄叙事更有运维价值。

Ginny Strazisar 到达奥斯陆时，预定承载网关软件的硬件还没有准备好。她本想在一次 TCP/IP 会议之后完成安装，只得先与挪威研究者 Paal Spilling 相处几日，又去别处旅行，等机器就绪后再回来。多年以后，她在 Computer History Museum 的口述史中平静地讲起这段插曲。它却点出了早期互联网最实际的一道约束：没有那台 PDP-11，协议再漂亮，也没有边界可以跨越。

Strazisar 于 1975 年 4 月加入 Bolt Beranek and Newman。她很快参与当时称为“gateway”的设备开发，即负责连接不同网络的机器。BBN 的实验性 Resource Computer Network 与 ARPANET 之间已有一处网关；随后，她又参与 ARPANET 与 Packet Radio Network、ARPANET 与 Atlantic Satellite Network 之间的连接。Computer History Museum 将她描述为新兴 TCP/IP 协议编写首个互联路由器软件的人——在“router”成为常用称谓之前，它就是网关。

这个定位既重要，也有边界。Strazisar 不是 TCP、ARPANET、无线分组网或卫星网的唯一创造者，更不是整个互联网的单独发明者。她承担的是一个可辨认的工程责任：让两侧机制完全不同的网络，在不被改造成同一种网络的前提下转送数据报。

差异并不抽象。无线分组网面对移动终端、无线中继与实验网络时开时停；ARPANET 有自己的接口和主机接入方式；SATNET 横跨大西洋，需要多个国家的设备和团队协同。互联的价值恰恰在于保留这些差异。网关必须在一侧接收，在另一侧发送，同时处理速度、帧格式、可用性和故障方式的不对称。

物理形态也因边界而变。Strazisar 回忆，无线分组站的代码与网关代码曾共同运行在一台 PDP-11 上。连接 ARPANET 与卫星网的网关则是独立的 PDP-11：一端面对 ARPANET，另一端面对 SATNET，由软件把数据包导向另一张网。共同的是互联职能，不同的是本地实现。

她记忆中的安装路线，比任何概念图都更能说明依赖关系：1976 年夏天在 BBN，1976 年 12 月在伦敦，1977 年夏天在挪威。硬件安装与软件安装由不同的人负责，出差必须配合机器交付和接口准备。伦敦的硬件先到，软件随后落地；奥斯陆则因硬件延误而打乱顺序。所谓架构落地，最终是一个个站点能否按次序完成准备。

验证也是逐步进行的。Computer History Museum 2002 年的一期杂志记载，1976 年夏季的早期无线测试只离承载 Strazisar 双向 ARPANET 网关软件的分组无线站一个无线跳，并把一次两网仪式性传输标为 8 月 27 日。更难的目标，是证明这套方法不是只对某一对网络有效的临时补丁。

1977 年的三网演示中，移动实验车在加州道路上行驶，数据经过 SRI 的无线基础设施、ARPANET 和卫星网络，跨越大西洋后又到达位于 USC 的服务器。它验证的是组合能力：三类物理网络、多个实现和多家机构，仍能形成一条端到端会话。

不过，史料没有给出一条毫无皱褶的时间线。Computer History Museum 2017 年文章说演示发生在 11 月 22 日星期三；同一机构 2002 年杂志的图注却写 11 月 27 日。地点也不能随意拼接。Strazisar 确实在挪威装过软件，但 Vint Cerf 在口述讨论中回忆，演示流量并未真正进入挪威，实际使用的是其他卫星链路上的网关。

保留这些差异，不是吹毛求疵。设备在某处安装，只能证明代码与机器在那里结合过；一条端到端传输，只能证明当时配置下的一条路径；两者都不能自动证明备用路线、所有接口或长期运行状态。把安装地点全部画进数据路径，会制造并不存在的证据。

这次演示也不是一人完成的。博物馆列出超过 35 名参与者和八家机构：Bob Kahn 与 Vint Cerf 负责 TCP 概念，Jim Mathis 与 Dave Retz 负责客户端，Ray Tomlinson 与 Bill Plummer 负责服务器；SRI、Collins Radio、Linkabit、BBN、UCL 和挪威方面的团队分别承担无线分组、卫星和站点工作；Virginia Strazisar 被列在 BBN 网关项下。她的贡献放进系统之后反而更清楚：她负责两张网之间的边界，却不拥有任何一张完整网络。

演示之后，网关逐步从团队经验变成可传递的技术记录。RFC 823 说，设计先写入 IEN 30《Gateway Routing: An Implementation Specification》，之后由 Strazisar 在 IEN 109《How to Build a Gateway》中更新。RFC 特别致谢 V. Strazisar、M. Brescia、E. Rosen 和 J. Haverty。运行中的软件开始拥有可被外部检查的文字结构。

IEN 30 最值得注意的不是自信，而是克制。它把路由算法写到足以实现，并希望在部件失效时绕行；同时坦承，分析无法证明网关始终正确转发，也无法保证某些目的地不会无限期收不到数据。脆弱性有时只有在实验和实际运行后才显现。算法可能没错，路由信息仍会因软硬件故障而损坏，编码实现也可能把正确设计写错。

RFC 823 又记录了一次从研究到运行的迁移。早期软件使用 BCPL 与 ELF 操作系统，之后改用 MOS 提高性能。1981 年末开始的新实现，目标不再只是研究测试床，而是运行中的通信设施。团队用 MACRO-11 节省空间，以容纳更多缓冲区和监测机制；文档同时强调，底层架构仍与较早的研究实现基本一致。

“可运行”因此意味着限制必须看得见。每个接口的输出队列都有上限，避免慢速网络吃掉全部缓冲区；无法入队的数据报会被丢弃并触发监测告警。运维人员可以查看接口、邻居、可达网络、吞吐和丢弃原因。RFC 823 甚至明确称自己只是当前实现的“快照”，不是永恒的规范。

今天评估任何异构边界，都可以沿用这套证据次序：具体运行哪个二进制，它依赖哪版硬件和驱动，哪些接口真正被测试，发生拥塞或断路时又留下什么计数。架构图证明意图；到达的数据包证明一条路径；只有可复现部署和可解释故障，才证明边界可被经营。

网关代码之所以比数据包更早出发，是因为互操作始终有地理位置。它落在安装介质、板卡修订、现场线缆、维护窗口和能读懂远端状态的人身上。协议让互联网成为可能；这些不显眼的现场工作，让可能变成事实。

Sources