摘要

  • RFC 1913 让 Whois++ 服务器发布精简的“前向知识”：去重后的词项只说明下游某台服务器可能保存匹配记录，用于查询路由而非记录级证明。
  • 多条索引路径摆脱了单一层级，却也形成必须由客户端遍历的网格；新鲜度、环路控制、端点恢复、查询扩散与潜在费用都没有因此消失。
  • 这套思想后来被抽象为 Common Indexing Protocol；Whois++ 本身则在 2006 年经 IETF 审查后转为 Historic，并被归入“已有定义但未被采用”的协议。

有用的遗忘

RFC 1913 里的小例子比网络拓扑图更能说明设计。三条记录包含两名用户、一个域名和若干字段。质心索引为每一种模板与属性列出其中至少出现过一次的所有词，并去掉重复。无论 “Smith” 出现在一条还是一千条记录里，摘要里都只有一个 “Smith”；“Labatt Beer”中的两个词分别留下，二者曾在同一个字段值中相邻这一事实却不再存在。

这不是损坏的数据库，而是刻意缩小后的主张。索引服务器若只需判断下一次查询应不应该送往某个下游，就不必复制全部记录。它只要有足够的“前向知识”剪掉明显无关的分支。

问题也由此变得精确。压缩删除了记录标识、出现频率、词语共现、排序、提交者与当前状态。一次匹配只能说明：按照这台索引此刻掌握的摘要，这个模板的这个属性曾在某个下游出现过该词。它产生的是转介，不是结论。

把网格叠在记录之上

1995 年 8 月发布的 RFC 1835：WHOIS++ 服务架构希望突破早期 WHOIS 松散、面向人工阅读的记录模式。它引入带类型的模板和结构化属性—值对，并区分两种逻辑角色：底层服务器保存完整记录，索引服务器保存前向知识与指针。同一台机器可以兼任两者，但两类证据并没有因此合并。

这套区分回应了规模问题。一个全球中央名录会集中存储、流量与故障；一棵严格的层级树又要求查询者事先知道信息应归在哪个分支，同时把负载推向高层节点。寻找“提供某种服务的人”之类黄页问题，还可能横跨地理、组织与网络拓扑。

1996 年 2 月发布的 RFC 1913：Whois++ 索引服务架构在记录之上铺设网格。索引服务器可以收集底层服务器或其他索引服务器的质心，并再次汇总；一台服务器可以同时被不同上级索引，进入地理、行政或拓扑等多套层级。记录的唯一标识不再规定唯一发现路径。

这是一种通过间接层实现的去中心化。原始事实仍留在底层服务器，网格传播提示。专门索引可以只覆盖特定模板或字段，多重父节点可以增加替代路径，用户也无需先知道记录位置。但任何路径都没有自动获得目的地保存的现实。它只知道为什么下一台服务器值得一问。

一次变更跨过了多只时钟

前向知识若不维护，很快就会误导。RFC 1913 规定了经过认证的轮询：轮询方可以索取完整质心，也可以索取某些模板与字段的变更。被轮询方还可以发送 DATA-CHANGED，通知质心已改变；收到通知的索引方再决定是否以及何时重新轮询。

这里其实有一串不同事件：底层记录改变，质心改变，通知发出，通知被接收，轮询发生，变更报告被认证，索引写入更新，更上层索引随后才可能获知。回复码 227 把边界写得很清楚：变更传输已被接受并记录，等待后续处理。它不等于所有索引都已经应用或继续传播。

于是有两种对称风险。旧的肯定提示可能把客户端引向已经删掉该词的服务器；迟到的新提示则可能剪掉刚刚新增匹配的服务器。RFC 并未给出实际发生率，因此不能把规范没声称提供的保证反过来当作失败证据。可以确定的是：索引时间戳或接收回执不能代替端到端的新鲜度证明。

客户端接过了图的复杂性

网格在图上像层级，却不是树。一台服务器可以有多个父节点，替代路径因此出现，环路也因此必须被处理。RFC 1913 对轮询关系提出 hop count，并在当时版本中设置最大值 8；对于查询转介，它还给出另一种思路：让客户端记住已经访问过的服务器。

RFC 1914：如何与 Whois++ 网格交互把责任交代得更具体。客户端连接一台服务器、提交查询、接收记录与转介、断开连接，再决定下一台联系谁。算法维护“已经查询”的集合，还可以通过询问谁轮询谁，把搜索扩展到初始视野之外。

起点仍然重要。本地服务器只能展示自己知道的网格。扩展搜索可能接近更完整的结果，却不免费，也不必然明智。RFC 1914 警告，盲目沿全部转介扩展可能产生指数增长的资源成本；网格中的某些响应甚至可能收费。因此客户端需要黑名单、时间与费用上限，也要让用户中途停止。

“完整”不再是单次响应的属性。它取决于起始服务器、转介是否存在、环路判断、扩展规则、预算、黑名单以及每个端点是否仍然工作。规范可以描述如何遍历可达网格，实际运营者仍要决定什么叫“可达”，什么叫“值得继续”。

稳定身份只能修补过期位置

RFC 1914 还指出一个日常但致命的断层：转介中的主机名、IP 地址与端口，可能来自数周前的一次轮询。连接失败不一定意味着服务器身份消失。客户端可以拿稳定的 server handle 去 Directory of Servers 查询最新已知的主机与端口。

把身份与位置分开是合理设计。服务器搬迁时，不必要求所有旧转介同步变更。但“最新已知”仍不是“现在可达”。第二次查询得到更新地址后，连接依然可能失败。RFC 1913 甚至分别编码了目标服务器不可达，以及主机可达但服务不响应两种结果。handle 能修复一个旧指针，不能凭空创造正在运行的进程。

安全边界同样没有闭合。RFC 1913 明说该文不讨论安全问题；RFC 1914 则建议客户端维护黑名单，因为网上可能出现伪造的 Whois++ 服务器。这些文字不是已发生攻击的证据，却说明转介本身就是决策点：跟随指针意味着客户端进入另一个管理域，接受另一方关于数据内容的主张。

思想离开了产品

1999 年 8 月，RFC 2651：Common Indexing Protocol 架构把 CIP 称为 Whois++ 分布式索引思想的演进与细化。它把索引传递从名录访问协议中抽离，允许更多索引对象，并把交换内容明确称为查询路由所用的提示。客户端仍要通过另一套原生数据访问协议取得真正结果。

这条谱系很重要。一个协议没有成为长期公共服务，不代表它提出的所有区分都失效。Whois++ 把特定质心与模板名录绑在一起；CIP 尝试保留可复用机制：服务器交换精简知识，让未来查询靠近可能持有数据的节点。

退场记录同样需要准确。2006 年 3 月的 RFC 4450：清理陈旧标准的审查报告记录了一次保守的旧 Proposed Standard 审查。RFC 1835、1913 与 1914 被列入转为 Historic 的清单，Whois++ 被归入“已有定义但未被采用”的协议。这并不抹去试验或软件——RFC 2651 还提到 Digger——而是记录 IETF 当时的判断：这些文件已不再代表值得以 Proposed Standard 维护的现行实践。

所以，这段历史不是“中心化战胜去中心化”的寓言。网格确实解决了一个发现问题，它的抽象后来也继续发展。没有消失的是从提示到事实之间每一次交接的成本。

来源

  • RFC 1835、RFC 1913、RFC 1914、RFC 2651 与 RFC 4450 已在上文各链接一次。