摘要

  • RFC 977 让读者从一台或少数几台本地服务器中的中央数据库取回所选文章，避免每台工作站都保留完整副本。
  • Kantor 与 Lapsley 把这种阅读路径和服务器之间交换文章的路径分开说明。文档也提出中间缓存服务器，但明确不规定其运行方式。
  • RFC 记录的是预期的存储节省，并未给出实测数据或普遍部署证明。局部集中存储并不等于把整个 Usenet 变成一套全球中央系统。

工作站不必背着整座新闻库

读 RFC 977 时，先把尺度缩小到一组通过局域网连接的机器。大型服务器旁边可能有磁盘有限的工作站。若每台机器都接收和保存全部新闻，许多从未被打开的文章也会占用本地空间。Brian Kantor（UC San Diego）和 Phil Lapsley（UC Berkeley）提出的问题很具体：能否让这些终端阅读新闻，却不要求它们各自变成完整档案库？

1986 年 2 月发布的 NNTP 提案把文章集合和索引放在中央新闻服务器上。读者通过 TCP 连接，请求自己想看的条目。RFC 977 还把索引、交叉引用与旧消息过期纳入这一存储模型。客户端负责呈现和导航；终端不需要复制一份完整仓库，才能参加讨论。

这样安排同时处理了容量和异构系统的问题。规范认为，在较大的局域网中，把新闻集中到一台或少数几台主机，可以少存重复副本，也让磁盘空间紧张的工作站使用新闻服务。它还强调 TCP 流可以为不同硬件和操作系统提供通用接口，避免假设所有机器共享同一种网络文件系统。共同的是访问协议，不是各台计算机的磁盘组织。

因此，“中央”有明确范围：这里是服务一组本地机器的新闻主机，并非一台存放全网 Usenet 的机器。一个大学局域网可以共享阅读仓库，同时继续与别的新闻主机交换文章。

两种不同方向的共享

NNTP 还负责新闻主机之间的文章交换。RFC 977 把这一过程和读者访问本地新闻库区分开：一台主机可以向邻居查询新组和新文章，选择希望接收的内容，并说明自己已有的文章。目标是只传需要且不重复的条目。

这两个路径解决的问题不同。本地共享库减少同一组工作站中的重复存储；主机之间的交换决定副本如何在站点间传播。前者把阅读仓库放到共享服务上，后者仍由多个主机协商各自需要的内容。若只把 NNTP 描写为“集中化”，就会忽略它保留的服务器对服务器分发。

服务器本身也只是接口。RFC 977 把它描述为程序和新闻数据库之间的边界，并把用户交互与内容呈现留给客户端程序。协议可以规定客户端如何通过 TCP 查询，却不需要统一每种软件的界面或阅读习惯。

缓存被提出，却没有被规定

针对用户较多的组织，Kantor 和 Lapsley 设想增加中间服务器，由它转接阅读请求，并缓存最近取回的文章。客户端可以先尝试本地服务；若连接失败，站点可拒绝访问，也可回退到中央主机。

这个设想承认共享仓库会带来可用性问题：主机故障时怎么办，是否应在用户附近放一份临时副本？但 RFC 977 明确说，辅助服务器如何运行不在本文范围内。文档没有定义完整的故障切换协议，也没有承诺缓存内容始终新鲜。每个部署者仍需决定副本何时更新、如何回退以及如何恢复。

负担转移到服务端

设计意图很明确：不让每台工作站保存全部文章。但存储并没有消失，而是集中到新闻服务器，索引和过期规则也随之集中。用户得到更轻的终端，服务运营者则承担更大的容量与连续服务责任。

这是从 RFC 结构推导出的运营后果，不是文档提供的实测结论。RFC 977 认为较大集群能获得可观节省，却没有统计实际节省的磁盘、部署数量、服务器利用率或读者体验。设计理由与历史效果不能混为一谈。

可用性也遵循同一逻辑。如果许多读者依赖同一新闻主机，它的停机、索引延误和保留规则会同时影响多人。缓存可以降低直接依赖，但其实现被留在规范之外，因此可靠性必须由具体站点安排。共享存储以服务边界取代许多本地副本；这个边界需要有人负责。

后续规范保留了两条路径

2006 年 10 月，RFC 3977 将 RFC 977 列为被取代的规范，并说明自己是替代文本，对早期规则作了澄清和扩展。新文本仍把读者阅读描述为从中央数据库取回文章。同月的 RFC 4644 则通过 CHECK 和 TAKETHIS 正式规定服务器间的异步流式传送。

这些后来的 RFC 不能证明某个站点如何部署 NNTP，却能看到两类功能继续发展：读者从仓库取文，服务器向同伴传送副本。两者相连，但并不是同一项操作。

把 Kantor 放回共同署名与运维经历中

UC San Diego 的纪念文章记载，Kantor 在校工作 47 年，曾任大学邮政主管、运行名称服务器并参与网络基础设施管理，也将 NNTP 的设计归于他。1986 年 RFC 的作者栏则给出更精确的技术署名：Kantor 与 Lapsley 共同撰写。前者把协议置于长期运营网络服务的职业背景中，后者保留了合作完成规范的记录。

这份设计最值得保留的边界，不是“所有新闻都集中”，而是不同工作放在不同位置：本地读者共享文章库，客户端负责呈现，主机之间另外交换副本。这样可以减少小终端的重复存储，同时把容量、索引和可用性责任推向服务端。现有来源说明设计机制和初衷，并未量化它带来的实际效果。

来源