摘要

  • 1980 年 10 月 27 日，ARPANET 的 IMP 持续接收并转发编号为 8、40、44 的路由更新：六位序列号比较规则让其中每个数都能被判为比另一个数更新。
  • Eric Rosen 在 RFC 789 中提出的可能原因是硬件故障使重传内容发生变化；更新循环耗尽缓冲区，妨碍链路状态检查，也让网络自身成为一条迟缓的修复通道。

用户入口还在，节点之间却失联

故障最初不像一张路由表算错了。部分用户仍能通过电话线接入终端接口处理器（TIP），但尝试访问另一台接口消息处理器（IMP）所连接的主机时，会看到“net trouble”。已经建立的连接也被中断。TIP 还能对电话另一端的用户作出响应，IMP 间却没有可用路径。这一区分让调查者将目光从接入设备转向连接各节点的网络。

Eric C. Rosen 后来在 RFC 789 中，根据多台 IMP 的内存转储等资料重建了事故。转储显示，几乎所有设备的缓冲区都堆着尚未处理的路由更新。它们似乎都来自 IMP 50。该设备在事故前不久发生故障，事发期间已经离线。它的邻居 IMP 29 也有硬件问题，会丢失比特。重启附近的 IMP 并没有解决问题：设备重新接入网络后，邻居又会把相同的更新送回来。

为什么 8 会比 44 更新

每台 IMP 都会定期发送链路和延迟信息。更新沿网络传播，帮助节点维持共同的网络视图。每条更新带有六位序列号，按模 64 递增。接收方要判断：这个来源的本条更新，是否比上次接受的更新更晚。

规则使用序列号空间的一半来处理回绕：若新数向前相差不超过 32，就算更新；若它已从零回绕且与旧数相差大于 32，也算更新。这不是通用时钟，也不等同于日期。但对事故中同时存在的三个值，结果会循环：44 比 40 更新，40 比 8 更新，8 又比 44 更新。

内存转储记录的队列正是 8、40、44，随后又是 8、40、44。三条更新除序列号外完全相同。每条都可能把另一条挤出“最新”位置，再次转发给邻居。各 IMP 都按局部规则行动，异常在于原本不应同时存在的状态一旦出现，比较本身便无法形成全序。

Rosen 没有把三个数的起因说成已证实事实。他认为，较可能的过程是：一条编号 44 的更新从内部表格重新生成，用于重传；硬件丢失比特，使它的序列号先变成 40，之后又变成 8。网络上传输的分组有校验和，但重传时会依据内部表格重建分组，而这些表格并未持续校验。频繁校验会消耗处理器时间或内存，这两种资源当时都很有限。Rosen 也提出另一种可能：原值是 8，后来因比特增加而改变。转储能证明三个序列号构成了循环，无法让具体的硬件错误过程变成确定事实。

路由循环最终造成资源耗尽

路由更新进程具有高优先级。更新不断循环后，处理器与缓冲区大部分时间都用来处理它们，IMP 没有足够的缓冲区接收 HELLO 和 I-HEARD-YOU 消息。相邻节点依靠这些消息判断链路是否可用。检测程序无法运行，软件就把线路判为中断。控制信息因此改变了其他 IMP 正试图测量的网络拓扑。

所以，Rosen 的诊断并不是“路由器算出一条错误路径”。路由和代码仍符合其定义的规则。硬件故障制造了规则未预期的状态；有效的更新处理流程随后消耗了过多资源，却没有充分的限流或隔离机制。这是一次特定网络的事故记录，不是攻击证据，也不能直接描述今天的互联网。它说明：在部署系统中，损坏的数据可能经由重传放大，使局部故障变成更广泛的服务中断。

修复也要经过故障网络

运维人员给 IMP 下发补丁，要求忽略来自 IMP 50 的更新；尽管 IMP 50 本身已经离线，这条措施仍能切断循环。在正常情况下，网络控制中心数分钟就能广播补丁。事故期间，远程控制通常无人值守的 IMP 可能要三到四小时，因为控制通道依赖网络本身。修复路径取决于正在修复的基础设施。补丁最终奏效；Rosen 说，除中断本身外没有持续性损害。

他的方案包括微调 LATER 比较中的一个边界、在下一代 C30 硬件中检测和纠正单比特错误，以及发现高优先级进程消耗过多资源后，将 IMP 转入仍可远程控制的状态。这些措施分别针对已知循环、物理错误和节点恢复能力。它们是分层补救办法，不代表所有罕见故障都已消失。

证据范围

Rosen 的研究先发表于 1981 年 1 月的 SIGSOFT Software Engineering Notes，随后以 RFC 789 形式流通。这是本篇事故叙述的主要来源，文中清楚标出哪些内容是推断。McQuillan、Richer 与 Rosen 于 1980 年 5 月发表的研究记录了新路由算法在实际网络中的测试；它不能证明当时已经测试过“内部表被损坏”与“序列号比较成环”这两件事同时发生。计算机历史博物馆的纪念短文把相关数值称作“时间戳”；RFC 789 将它们明确描述为六位序列号。

来源：RFC 789；McQuillan、Richer 与 Rosen，《The New Routing Algorithm for the ARPANET》；计算机历史博物馆 10 月 27 日条目；1980 年论文的 IPCOMPRO 托管扫描件；Heng Lu 关于运行代码优先的文章，仅作为编辑视角。