摘要

  • IHAVE 首先只报出一个 Message-ID。接收服务器可以说自己已有该文、暂时无法处理，或要求发送完整文章；正文并不会无条件越过链路。
  • “请发送”只是第一道门。正文抵达后，服务器仍能因群组、分发范围、格式、长度或存储条件而接收、暂缓或拒绝；正面的传输码也不保证永久留存。
  • 后来的 CHECK 与 TAKETHIS 把询问和传送拆成可并行推进的两类操作。等待变少了，但接收方的策略权和保管权没有交给发送方。

四种状态不能只写成一个“成功”

设想发送端依次报出三个标识。接收端对第一个回答“我已经有”，对第二个回答“稍后再试”，对第三个回答“把正文发来”。第一篇省去了重复流量，第二篇保留重试可能，只有第三篇正文真正经过链路。

第三篇到达以后，接收端才看到全部首部与内容。它也许发现文章投向本站不承载的群组，分发范围不合规则，首部破损，或当下空间不足，于是给出拒绝。这个拒绝不是推翻先前承诺，因为先前没有承诺接收；它只表示“值得看完再决定”。

因此，证据链上至少要保留提议、正文请求、传输结果和后续留存四层。缺少任何一层，都可能把节省重复传输、内容审查或事后丢弃误写成同一事件。

最初要解决的是昂贵的重复正文

RFC 1036 记录了更早的 ihave 与 sendme 控制消息。一个系统列出自己拥有的文章 Message-ID，另一个系统再索取缺少的项目。这些标识可以成批处理，因为逐条报出一个标识的开销，可能已经接近一篇短文章本身。

这是存储转发时代很实际的账。新闻可能经过定时拨号、低速专线或容量不稳定的路径。若先把每篇正文都推过去，才发现邻站早已收到，就会把宝贵链路花在重复内容上。先问标识，把接收端的历史记录变成了流量过滤器。

但 Message-ID 只足以回答“是否见过这个名字”。它不包含完整群组、分发范围、正文长度和首部质量，也不能替接收端执行本地政策。所以省带宽的第一判断，天然不能代替看过正文后的第二判断。

RFC 977 把两道门写进状态码

RFC 977 把这一机制正式写成 NNTP 的 IHAVE 命令。客户端先附上 Message-ID。服务器用 335 要求发送文章，用 435 表示不需要，用 436 表示当前失败但以后可以再试。

只有收到 335，客户端才发送完整文章。正文之后还有第二组结果：235 表示此次传输成功，436 表示暂时失败，437 表示拒绝且不要求重试。规范明确列出若干正文后才可能确定的原因，包括不想接收的群组或分发范围、磁盘不足、文章过长以及首部混乱。

第一组代码是在决定是否支付正文的传输成本，第二组代码是在决定收到的对象能否进入本地处理。把 335 称为“文章已被接收”，等于在第二道门出现之前就宣布了结果。

沉默也不能补成成功

RFC 3977 保留了两阶段结构，并把失败语义说得更清楚。IHAVE 不能流水线化：客户端必须等第一响应，按要求发送正文，再等最终响应。若该来的响应没有出现，应按暂时失败处理，而不是把连接中断后的沉默推断为成功。

规范也区分了中继与投稿。IHAVE 是对等服务器之间搬运已经形成的文章，POST 才是把新文章注入系统。接收一个中继对象并不是替整个网络认证作者或保证全球传播，而是在既有供稿关系和本站政策内处理一次转交。

重复提议时，服务器应利用历史识别同一标识，避免无谓正文。但历史记录也会丢失或不一致；同一 Message-ID 甚至可能出现不同字节。因此可靠审计不能只存名字，还要存所传正文的哈希。

235 不是永久保管收据

RFC 977 还留下一个很容易漏掉的边界：服务器即使返回 235，后续处理仍可能发现文章不可接受，并在没有新通知的情况下将其丢弃。这不意味着状态码没有价值，而是说明状态码只证明规范所定义的那次传输完成。

RFC 4644 对流式传送给出同样警告。TAKETHIS 收到正面的 239 后，文章仍可能在后续处理阶段被静默舍弃。要证明长期保管，必须继续观察本地存储、读者可见性或向下一跳的提议。

所以“字节已发出”“对端确认传输”“对端仍然保存”“文章继续传播”是逐层增强、互不替代的证据。NNTP 的成功码覆盖其中一层，而不是全部。

流式扩展改变的是等待队形

传统 IHAVE 对每篇文章都要等待第一响应，再等待最终响应。高时延链路会因此空转。RFC 4644 引入 CHECK 与 TAKETHIS：前者询问某个 Message-ID 是否值得发送，后者携带完整文章并取得最终接收或拒绝结果。多项询问和传送可以同时处于进行状态。

不过 CHECK 的回答只是建议。接收端不能假定发送端一定服从；在站点约定或自适应策略允许时，发送端也可以不先 CHECK 就使用 TAKETHIS。无论是哪种路径，接收端仍要对正文给出自己的最终判断。

流式机制把串行等待变成多车道，却没有把本地磁盘变成公共空间。性能优化没有更改谁能说“不”。

站点关系不藏在一个命令里

RFC 5537 把这些命令放回 Netnews 整体架构。早期 ihave 与 sendme 控制消息在互联网中已大体淘汰，虽在部分 UUCP 场景仍有使用。现代服务器之间通常先约定交换哪些内容、采用何种传输，再用相应机制执行。

Message-ID 不携带这份站点协议。335 也没有授予发送方改变接收方政策的权力。命令只把一次具体提议和两阶段结果变得可互操作；群组范围、分发规则、过滤和保留仍由站点关系与接收者决定。

IHAVE 的历史意义正在这里：它用很少的消息节省了昂贵流量，却没有为了简化统计而虚构一个全能的“接受”。分布式系统越需要高吞吐，越需要把请求、传输、确认和保管分别记录。

来源