摘要

  • RFC 849 指出：SRI-NIC 的主文件即使正确且最新，各站点实际使用的本地副本仍可能停留在旧版本。
  • 它偏好的组合方案用一次推送争取速度，用版本号避免无效下载，再由开机轮询与周期轮询补回推送错过的更新。

一台主机在更新发生时恰好关机。推送只尝试一次，当然没有人接收。主机次日开机，名字解析照常工作，应用也未必报错；它只是继续相信昨天的地址表。

主文件没有损坏，登记机构也已经完成修改。陈旧发生在另一处：从权威记录到本地运行状态的途中。

RFC 849《Suggestions for Improved Host Table Distribution》只有两页，却准确切开了这个问题。Mark Crispin 在开篇特别说明，四项方案当时都不是标准，只是希望通过征求意见形成共识。因而，这份文件的史料价值不在于证明某个协议被部署，而在于它把一句含混的“主机表已更新”还原为若干可以分别失败的动作。

一份主表，不等于一种现实

RFC 608 记载了早期的集中式安排：NIC 维护一个源文件，并定期——例如每周或在需要时——生成机器可读的 ASCII 主机名文件。生成后的 <NETINFO>HOSTS.TXT 可通过 FTP 获取。集中维护解决的是“哪个源文件代表当前登记”这个问题，并没有自动解决所有主机何时取回它。

到 1982 年，RFC 810 为 DoD Internet 规定了新的主机表格式，内容扩大到网络、网关、主机以及部分协议信息。站点既可以匿名 FTP 下载，也可以通过 NIC Host Name Server 获取同一张表。但文件还明确说，使用者要负责把它转换成本地所需的格式。

“下载”和“可用”之间于是出现了一条边界。源文件、传到本地的字节、转换后的数据库、以及解析程序当前真正读取的状态，是四件事。

RFC 811 又提供了一个运行在 SRI-NIC、TCP 端口 101 上的服务。客户端可以用 HNAME 查名字、用 HADDR 查地址，也可以用 ALL 取得由 BEGIN 和 END 包住的整张表。这让读取权威信息更方便，却仍不能回答一个本地问题：我已经装入系统的那一版是不是最新？

陈旧并不总会发出警报

RFC 849 对当时的运行条件直言不讳。站点之所以必须保留本地 HOSTS.TXT，是因为 SRI-NIC 不足以成为唯一、随时可依赖的名字服务器。NIC 可以导出完整登记表，也允许匿名 FTP；问题在于，仍然需要有人知道“现在该去取新版了”。Crispin 还说，更新通知并非一直都做得谨慎。

这产生两种相反的浪费。第一种是无声的陈旧：主表已经变了，站点却不知道。第二种是无效的搬运：站点无法自动比较版本，只好再次下载其实已经安装的同一份文件。

这两种失败不能靠“再发一次完整文件”同时解决。前者缺少变化证据，后者缺少相同证据。

先问版本，再决定是否搬文件

RFC 849 的第二项建议，是让 NIC 报告当前主机表的“version”。对于 Tenex 和 TOPS-20，文件 generation number 正好可以承担这个角色。Crispin 当时已经让本地 SYSTEM:HOSTS.TXT 保留与 NIC 文件相同的代号，再不时检查远端代号是否改变；他希望把这一步自动化。

版本号的价值很窄，却很关键。它不能证明表内每一项都正确，也不能证明解析器已经载入文件。它只回答：本地持有的是不是同一个版本？

正因为问题被压缩成这个便宜的比较，轮询不必等于每次传输整张表。版本未变，检查就此结束；版本改变，站点才进入取回、验证、转换和启用的后续步骤。证据与动作分开了。

纯推送把停机历史变成中央负担

第一项建议走相反方向：在每个合作站点设置监听进程，只接受来自若干“trusted”站点的登记表更新，主要指 SRI-NIC。接收主机在线时，更新可以几乎立即抵达。

真正困难的是“在线时”三个字。若要让纯推送承诺完整交付，发送者就必须记住哪些主机没有响应，并在以后重试。NIC 除了维护名字登记，还要维护订阅对象、每次发送结果、离线主机和未清重试债务。接收者越多，这个第二份动态登记越大。

Crispin 建议给更新后的登记表加校验和，确认它完整、无缺地到达。这个证据也有明确边界。RFC 849 没有把它写成密码学身份认证，没有声称它能抵抗恶意替换，更没有说校验成功就能证明表内事实正确。它检查的是传输结果，不是发布者权限、内容语义或本地启用。

邮件只是把未完成状态藏进队列

第三项建议把表寄给一组“host table update”收件者，再让各站点自行决定更新程序。这对 NIC 最容易实现，但 RFC 849 认为邮件不适合把越来越大的文件批量发给越来越多的接收者。

邮件的另一个问题是，它容易把“已投递”误写成“已安装”。邮件进入队列、到达邮箱、被提取、被转换、再被系统启用，中间每一步都可能停下。运输渠道完成了自己的任务，不等于名字服务完成了状态转换。

第四项方案不追求一条永不失败的路径

Crispin 最赞成的是第一项与第二项的组合。NIC 对登记接收者推送一次，不承担无限重试。每个站点在系统启动时主动查询是否有更新，有则取回；此外还可每天轮询一次作为后备。

这不是简单地“推送加轮询”，而是给两种路径分派不同职责。推送负责快：主机在线时尽早得到变化。启动轮询负责补：关机期间错过通知的主机，在恢复运行时检查自己的版本。周期轮询再处理那些既未收到推送、又长期没有重启的系统。

版本比较使补救成本可控。NIC 不必永远记住每台主机的停机史，本地站点也不必每天搬回一份可能完全相同的表。失败恢复被放在最能观察本地状态的一方。

当然，组合方案仍不保证瞬时一致。主机可能错过推送，开机时又遇到 NIC 不可达；传输可能中断；校验和可能不符；转换程序可能失败；新文件也可能没有成为解析器的活动状态。方案真正改进的，是让这些失败不再都躲在“HOSTS.TXT 已经更新”这一个结论里。

DNS 没有消灭陈旧，只是重新定义它

六个月后的 RFC 881 仍说，当时几乎所有 Internet 主机都使用某种基于 NIC 主文件 HOSTS.TXT 的主机表。它为域名式命名安排了阶段性迁移，并允许新旧机制并存。

RFC 882 随后指出，全球表的规模，尤其是更新频率，已接近集中管理的极限，因此需要分布式数据库。RFC 883 把名字空间分布到多台服务器，区分权威区域数据与缓存数据，并规定周期刷新和超时。它也坦白说明：主副本改变后，更新不会立刻出现在所有副本中，而会逐步扩散。

不能因此把 RFC 849 写成 DNS 的实施草图。RFC 849 自己说它不是标准，两者的架构尺度和协议内容也不同。可以确认的连续性只有一条：一旦数据存在副本，更新传播就必须有版本、时限、刷新与失败恢复；“分布式”并不会自动等于“处处最新”。

运行状态以最后完成的转换为准

RFC 849 留下的不是对推送或轮询的永久偏好，而是一种证据语法：权威源是哪一版，通知是否尝试，字节是否完整抵达，本地是否转换，活动系统是否真的采用，以及错过快速路径后谁来修复。

登记记录可以描述最新被接受的映射，却不能凭一句声明更新一台关机主机。通知也不能替代转换，校验和不能替代启用。真正决定网络使用哪一版名字的，是运行中的本地系统完成了哪一步。

1983 年的 Internet 正处在中央主机表与分布式名字服务之间。RFC 849 抓住了这个过渡期最容易被忽略的事实：发布发生在源头；新鲜度必须在使用者一端被验证。主文件可以已经是今天，网络仍可能活在昨天。

来源