摘要

  • Cronus 在 IP 与实体局域网之间放了一层虚拟局域网接口；只要接口的行为不变，底层网络便可以替换。
  • 这层接口需要兑现具体承诺：单点、广播、组播寻址，通往外部的网关，虚拟地址到实体地址的映射，以及明确的数据报大小和交付规则。

一条网线贵了、慢了，或者根本扛不住现场环境，换掉它听上去很合理。麻烦在于：上层程序要是把旧网络的脾气记得太牢，换线就会变成一次软件总动员。William I. MacGregor 和 Daniel C. Tappan 在 1982 年的 RFC 824 里，为 Cronus 分布式操作系统画出另一条路。先给程序一层稳定的 Virtual Local Network，简称 VLN，再让这层接口去处理实体局域网。IP 继续上班，底下的布线悄悄换鞋。

文件里的分层图很直白：TCP 和 UDP 在 IP 上面，IP 在 VLN 上面，VLN 才坐在实体局域网上。作者把目标写成两个词：兼容与可替换。兼容意味着 IP 无须修改或扩展，基于它的 TCP 也能照常工作；可替换意味着 Cronus 的上层软件只依赖 VLN 接口，不依赖接口背后的某种具体网络。条件也写得很清楚：新实体网络上的 VLN 实现必须守住同样的接口语义。接口不是魔术斗篷，而是一份有人要履行的合同。

换网的动机非常现实。文件提到成本、性能，以及机械和电气环境中的耐用程度。不同的 Cronus 集群可能选择不同的实体局域网。主机之间如何表示接口操作，可以因机器而异；接口提供的功能却要一致。因此，换一个实体网络意味着在各台 Cronus 主机上重新实现 VLN。工作的范围被圈在一层里面，工作本身并没有消失。这正是设计的价值：别让一根新电缆逼着整套软件改口音。

集群内的主机连在同一个实体局域网上。通往集群外部的流量由互联网网关接手，VLN 负责把外发数据报送到网关，把进来的数据报交给正确的主机。对互联网而言，VLN 本身是一个有网络号的网络；其下实体网络的号码可以相同，也可以不同。上层看到一个稳定身份，下面仍然要做路由和地址的细账。一个接口稳定，并不等于可以忘记出口在哪里。

地址规则更能看出这层设计有多具体。VLN 客户端可以指定一台主机、向全体广播，也可以给一个组发送。RFC 的本地地址表把 0 到 1,023 留给特定主机，1,024 到 65,534 留给组播，65,535 用作广播。为了装下完整范围，作者建议 VLN 使用当时的 A 类或 B 类网络。这是 Cronus 在 1982 年的设计数字。重点在于：三种投递方式必须由同一套接口清楚表达，实体网络的差异由下层消化。

用以太网实现 VLN 的例子揭开了后台工作。每台主机维护一张 VPMap，把 32 位的 VLN 特定主机地址对应到 48 位以太网地址。如果某台机器换了实体地址，VLN 地址却保持原样，其他主机保存的旧映射便会出错。文件讨论了重置接口、重建动态表的办法。上层程序可以不关心搬家，负责投递的那一层却得更新通讯录。通讯录过期时，抽象层会以一种很礼貌的方式把数据报送丢。

交付承诺同样有边界。VLN 保证任意两位客户端之间能传送不超过 576 字节的数据报；更大的数据报只可能在部分主机组合间成功。VLN 自己不替 IP 分片或重组，也不处理 IP 选项。它没有承诺每个数据报都送达，也不对损坏或丢弃发否定回执。它要求送达的内容与发送的内容一致；对每个预期接收者，一份数据报要么收到一次，要么收不到。集群内收到的数据报依旧保持发送顺序，尽管中间可能有缺席者。像一叠信少了几封，留下的信仍按原顺序排着。

RFC 824 有趣的地方就在这里。它没有只喊一句“底层可替换”，而是逐项写出为了让替换成立，谁必须承担什么：地址怎么解释，网关怎么走，能共同保证多大的包，丢包之后又该如何理解序列。实体网络可以更换，因为接口上的承诺足够具体，VLN 的实现者也知道自己该背哪一口锅。