新闻组传送基本（建议）标准
本备忘录地位
NNTP定义说明了一个在ARPA-Internet
community中发送、检索、获取、张贴新闻文
本的可靠的基本方法。NNTP具有可计划性，所有的新闻都存储在一个中央数据库中，允
许用户只选择他所感兴趣的主题阅读，索引、参照、删除过期消息等。本标准为ARPA-In
ternet
community上的应用提出一个建议协议，提交广泛讨论并请求改进意见，本备忘
录允许无限制分发。
1. 导言
几年前，ARPA-Internet
community就支持及时的发送公告、信息、数据给所有的人
员共享。我们共同称这种可分类的消息为“新闻组”。这些新闻组被用来快速的传递共
同感兴趣的事物，如软件臭虫的修复、新产品讨论、尖端技术、规划，以及讨论和计算
机工作人员有关的事件。新闻组在所有网络使用者中非常受欢迎。
现在比较流行的两种新闻发送方式是：Internet邮件系统和USENET新闻组系统。
1.1 Internet邮件列表
Internet组织根据用户邮件列表发送新闻。他保存了所有已经订阅的用户的邮件地址
和回复地址。邮件列表将信息的副本发送给每个已订阅的用户。但当一个邮件列表的定户
超过一定数量时，邮件列表的发送效率将降低。发送每一个拷贝给列表中的每个人将占用
大量的网络带宽，CPU资源，以及珍贵的主机磁盘空间。他自身的维护也是一个大问题如：
用户从一个主题换到其他的主题；新用户的加入和老用户的离开；服务器服务内容的增加
和减少。
Kantor & Lapsley [Page
1]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
1.2. USENET新闻组系统
毫无疑问，如果用存储在中央数据库中的信息内容代替每个用户的邮箱，对总的资
源占用会有大的减少。USENET新闻组系统给出了实现这一目标的方法。它将新闻组信息
存储在中央存储仓库中并存放于一个位置（通常是一些分类目录），通过软件的管理允
许用户选择订阅他们感兴趣的主题阅读，索引、参照,删除过期消息等。
1.3. 新闻组的中央存储仓库
由于大量的主机经由快速的局域网（以太网一类）连接，这要求消息要发送到多个
或更多的主机上，并且允许使用客户/服务器模式访问新闻组文章。用户可以请求他们
想看的消息，不需要不经济的存储每个主机的每个分类下的所有信息。
1.4. 中心新闻组服务器
要做到这样经济节约，中央计算机系统要向网络上其他系统提供新闻组服务。这些
服务需要管理新信息文本和索引文件的收集，让网络上的每个人都能得到新闻标题公报
。由于存在众多的计算机系统，所以总的存储空间的效率提高了。同样，这允许工作站
用较少的存储空间参与新闻组，不存在由于下载大量的消息而对磁盘空间造成的压力。
我们现在听到一些使用IBIS或其他共享及分布式文件系统作为中央新闻组服务器的传闻。
这在使用相似的文件系统的计算机网络中也许可以正常工作，但这种方案不能全面的满
足大量不同的客户机系统的需求，特别是在一个客户群体中存在众多种类的操作系统的
时候。但是现在有部分（或者全部）的网络（共享）文件系统都可以在Internet
TCP协
议上提供一般性的服务，这显著的尊重、考虑、改善了广泛的主机硬件及操作系统的互
连问题。
NNTP定义了一个基于可靠连接（使用TCP）的，客户/服务器模式的，发送、查询、获取
、发布新闻组文章的协议。
Kantor & Lapsley [Page
2]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
在一个（推测中心）数据存储中心的主机上，用户在其他的主机上通过LAN连接到
新闻组服务器主机上，就可以读取新闻消息。
NNTP的新闻文章（文本）规范模型在RFC
850中定义，那描述了USENET新闻组系统
。无论如何，NNTP在组织结构、内容、新闻文章的存储方面处理满足了一些要求。因
此我们相信他能够轻易的匹配其他的非USENET新闻组系统。
具有特色的是，NNTP服务器在主机上以后台模式运行，而且可以接受来自LAN上其
他主机的连接请求。并能工作在由几个计算机组成的小系统，以及大的中心系统。
1.5. 新闻服务器的中介媒介
在有许多机器和用户的情况下（可能是大学或大的工业机构），可以使用中介服务
器。这个中介服务器或者“从属”服务器运行在各自的计算机系统上，为新闻组的阅读
提供可靠的中转作用或者为本地用户提供最新的新闻组文章的缓存。
具有代表性的是，当一个客户端请求获得新闻组服务，将首先请求连接到在本地机
器的新闻组服务器端口。如果这个请求失败，表明服务器有一个错误，这时计算中心可
以选择拒绝(放弃)新闻组访问，或允许连接到“主要”的新闻组中央服务器。
在工作站或者其他小的系统上，直接连接到主服务器也许是正常的操作方式。
这份规范不适用于从属（备用）的NNTP服务器。我们仅建议在大型的地区网络上合理的
增加NNTP服务器作为从属服务器来提高系统运转性能。
1.6. 新闻组的发送
NNTP使用命令行提供一个在协作的多个主机间交换信息（文章项目）的简单方法。
主机可以在连接到一个本地网范围，也可以和其他快速网络中想要获取新闻组信息（
文本）的使用传统的传输方法（如UUCP"译者注：UNIX间的拷贝"）的主机用NNTP传输。
Kantor & Lapsley [Page
3]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
在传统的新闻组文章发送方法中，新闻组是使用灌的方法从主机到主机的传播，
每个主机都发送所有新的新闻组文章到每个其他主机上，这个主机再转发到别的主机
上。显然，当接收一个新闻组文章的一个主机上已经从别的主机上得到了这个文章的
拷贝（众多的主机都会收到多余重复的消息）时，就会浪费时间和通信资源，（此处
暂留一段未翻译）
使用NNTP，主机间交换新闻组文章使用一个交互机制以决定文章是否已经传送。
当主机希望得到最新的消息，或者要决定哪个新消息需要发送时，主机会使用NNTP向
周围的一个或多个主机进行联系。第一个动作会询问，在主机上是否有新的新闻组群
组（使用NEWGROUPS命令创建的）。如果是的话,有适当的或需要（随站点本地的规定
而定）的群组，可以新建立新闻组。
客户端主机将询问所有的或者希望收取的几个新闻组群组的新文章是否到达，这
使用NEWNEWS命令。这将会收到来自服务器的新文章列表，并可以请求传送。
最后，客户端会向服务器建议最近的接受位置。服务器会说明那些已经获得副本
的文章，并决定哪些文章需要发送和接受。
在这种方式中，只有那些没有得到过副本的和希望请求得到的文章会发送。
Kantor & Lapsley [Page
4]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
2. NNTP 规范说明
2.1 总论
这个新闻组说明文档定义了使用TCP连接和类似于SMTP的指令和应答的规范。它从
主机上接受连接，并为新闻组数据库提供一个简单的操作界面。
这种服务器只是程序和（新闻组）数据库之间的一个界面。它不和任何用户交互，提
供任何层次的函数。对于他的用户友好性的要求是更好的服务于客户程序，在操作中
更好更方便的配合外界环境。
在通过（使用）Internet TCP协议连接时，为这个服务分配的通信端口是：119
。
2.2. 代码特性
指令和应答都是由ASCII码字符集组成。传输服务使用8-bit
byte（8位字节）传
送，当在8位字节中有7位作为数据正常传送时，最高位清零。
2.3. 指令
指令由一串命令字符组成，在有些时候还需要跟参数。指令带参数时参数和指
令必须由一个或几个空格分开。命令行必须包括所有必要的参数，并只能包含一条命
令。
指令和参数都不区分大小写。简单的说，就是一个指令和参数字符可以用大写，
也可以用小写，或者大小写混合。
每个命令行必须以一对回车换行符（CR-LF）结束。
每个命令行长度不能超过 512
个字符，包括空格、分隔符、标点符号，和回车
换行符（因此命令和参数字符的长度实际上最多只有510个字符）。不接受超出长度
规定的命令行。
Kantor & Lapsley [Page
5]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
2.4. 应答
服务器的应答有两种种类，原文和状态。
2.41. 文本应答
文本只在一个数字状态应答行发送后跟在状态数字字符的后面发送。文本是按原文
内容按行连续发送，用回车换行符（CR-LF）结束。一个单行包含一个句点（.）表示文
本结束（服务器将在文本最后一行后面发送一个回车换行符。也就是一个句点.和一个
回车换行）。
如果在文本原文的第一个字符包含一个句点，那么第一个句点是两个（多的一个）
。因此，客户端必须检查接收的每一行的第一个字符是否是句点符号(.)，以判断它是
一个文本结束还是将两个（多的）句点改成一个。
这是因为文本信息通常是要显示在客户端的，然而，命令和状态的应答在做任何显
示之前都会由客户端程序作说明、解释。
2.4.2 状态应答
是来自服务器的，对客户端发送的上一条指令的应答状况报告。
状态应答行由 3
个数字开始，由每个数字充分的区别所有的应答类型。它们中的
一些可以预报后面要发送的文本信息。
应答的第一个数字广泛的代表了，成功、错误，和正在执行上一条指令。
1xx - 资料消息
2xx - 指令正常
3xx - 指令至今为止正常,发送指令的其余部分
4xx - 指令正确,但由于一些原因不能完成功能
5xx - 指令不能执行、错误，或者发生了严重的程序错误
Kantor & Lapsley [Page
6]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
在代码中的第二个数字的响应状态种类
x0x - 连接、设置，和各类其他信息
x1x - 新闻组（主题）选择
x2x - 文章（条目）选择
x3x - 发送功能
x4x - 上贴
x8x - 非标准的扩展
x9x - 调试输出
精确的响应代码会在其他指令的描述中详细说明。另外，下面要列出的常规响应
代码，被认为是一种普遍承认的标准。
有些状态应答包含想数字和名称那样的参数，这些数字和参数是对响应代码的简
单解释。
参数要被数字的响应码，或一个空格分隔开。所有的数字的参数都以十进制表示
，而且第一位可以是零。所有的文本参数在单独的空格后面开始，并在下一个空格或
一行结束的回车换行后结束（文本参数可以没有，会包含空格）。所有的文本，即使
在应答中没有参数也要在上一个参数由空格分隔。同样，在一个应答数字后面的文本
记录可以在不同的服务器上有不同。3 位数字代码将决定应该发送什么应答。
对任何其他种类的附加指令响应代码在这个标准中不作详细说明。那些应该选择
符合 x8x 定义的规范的范围（注意：调试代码是在 x9x
应答代码中有明确的规定）
。在标准指令中使用非标准的响应代码是被禁止的。
如果在调试中要使用 x9x
响应模式。那么之后的调试输出都归为“资料消息”
一类，可以认为，因此在从 190 到 199
的响应中都可以使用来作为各种调试输出。
在本规范中对调试输出没有要求，但如果是对已连接的流测试，它们将用到这些代码
。如果需要适当的执行细节，那么在调试时可以使用其他的 x9x
代码。(有一个例子
，代码 290 将答复一个远程调试请求)
Kantor & Lapsley [Page
7]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
2.4.3. 常规应答
下面列出了由 NNTP
服务器发送的常规应答代码。它们不具体的针对某一个指令，
但可以返回一个连接、错误，或特殊情况的结果。
通常，1xx 代码是可以不理会和不想显示的；代码 200 或 201
是在首次连接到
NNTP服务器确认上贴许可时发送；代码 400
将在NNTP服务器停止服务是发送（如，操
作人员要求）； 5xx 代码表示由于一些不寻常的原因，指令不能执行。
100 帮助文本
190 through
199 调试输出
200 服务器准备好 - 允许上帖
201 服务器准备好 - 不允许上帖
400 服务器停止
500 指令不可辨认
501 指令语法错误
502 访问限制或拒绝许可
503 程序错误 - 指令没有执行
3. 指令和应答详细资料
在下列各页中，将详细描述NNTP服务器上的每个标准指令以及将返回的应答。
每个指令都将看到清楚的示例，虽然示例不能很完善的解释NNTP服务器上的指令。
所有参数都是小写字母。在[方括号]中的是可选参数。
在这个部分描述的每一个指令，都可以在所有的NNTP标准服务器上执行。
Kantor & Lapsley [Page
8]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
这里不禁止增加额外的附加指令；然而，推荐在任何一种附加指令前加入字母“
X”以避免和本规范的后续版本冲突。
程序可以提示附加指令可以不重新定义状态响应代码。但禁止对标准指令使用其
他非标准响应码。
3.1. ARTICLE，BODY，HEAD，STAT 指令
ARTICLE指令有两种格式（和BODE，HEAD，STAT指令相关），对可以被检索的文
章使用不同的说明方法。ARTICLE指令后面跟随一个尖括号（"<" and
">"）中的mes
sage-id（消息号）,这是第一中使用方法；在只有一个数字参数或没有参数，是第二
种方法。
文章的原文由文本应答返回这个文档的基本描述。
HEAD 和 BODY 指令和 ARTICLE
指令一样，只是它们分别返回文章的标题行和
主体。
STAT指令也是和ARTICLE指令相似的指令，不过它没有文本返回来。当在一个主
题组里面选择了一个消息的号码，STAT指令将把它设置成当前文章而不发送文本本
身。返回的确认应答将包含message-id（消息号）。当一个message-id不是一个“
当前文章”时，使用STAT指令可选择一个有效的message-id。
3.1.1. ARTICLE （选定的message-id）
ARTICLE <message-id>
显示标题，一个空行，一个指定文章的主体（body
"text"）。message-id是
一个当查看一个文章的标题时的消息号。它由客户端通过 NEWNEWS
指令在列表中预
先获得，或者包含在不同的文章的索引中，或者从其他指令的应答中返回。
请注意在内部已经确定的“当前文章”在使用这个命令是不会改变。（漏掉一段）
Kantor & Lapsley [Page
9]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
3.1.2. ARTICLE （选择的号码）
ARTICLE [nnn]
显示标题，一个空行，一个当前或指定文章的主体（body
"text"）。可选参数
nnn
是在当前新闻群组（主题）和在已选择的新闻群组（主题）的范围内选择的文章
的数字标识符。如果忽略，那么当前文章将被选定。
如果有效的文章号码被指定，那么内部的“当前文章”可以由这个指令设定。
[下列应用表明ARTICLE的两种形式。]一个响应表示了当前文章号，一个message
-id字符串，其他的文本也会跟着返回。
返回的message-id字符串是一个包含在尖括号"<>"里的验证字符串，来自文章本
身的标题。message-id标题行（需要RFC850定义）来自的文章必须供给这个信息。如
果在来源文章中没有message-id标题行，那么由一个数字“0”代替在尖括号中。
因为message-id部分是每个文章的唯一标识符，如果新闻组阅读程序跳过了显示
文章的副本，会造成重复上贴（post）已有文章，或者上贴到其他群组（主题）。
3.1.3. 应答
220 n <a> 取回文章 - 标题和主体跟随
（n=文章号，<a>=message-id）
221 n <a> 取回文章 - 标题跟随
222 n <a> 取回文章 - 主体跟随
223 n <a> 取回文章 - 请求分离文本
412 no 新闻组群组（主题）已经选择
420 no 当前文章已经选择
423 no 文章号在这个群组中
430 no 文章没找到
Kantor & Lapsley [Page
10]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
3.2. GROUP 指令
3.2.1. GROUP
GROUP ggg
必须参数 ggg
是要选择的新闻组群组（主题）名称。要获得有效的新闻组群组
（主题）列表可以使用 LIST 指令。
成功的选取应答将返回在这个新闻组群组中的第一个和最后一个文章的号码，并
评估在这个群组中的文章数量。这个评估不一定必定是完全正确的。虽然这回很有用处
；但它必定和文件中的文章数相等或大于。（一些工具将可以计算文件中文章的实际数
量，另外，将最后的文章号减去第一个文章号可得到评估数量。）
当用这个指令选取了一个有效的新闻组（主题）后，新闻组中的第一个文章将被
设置为“当前文章（贴）”。如果指定了一个错误的组，那么以前选择的组和贴将保持
。如果选择一个空的组，“当前文章（贴）”将是不确定状态并不会使用。
注意，当新闻组（主题）名称在新闻组上没有相应的组存在。可以用LIST指令获
取别的匹配的新闻组名称或者会产生一个错误的计算结果。
3.2.2. 应答
211 n f l s group selected
（n=估计的组中的文章（帖）数量，
f=组中第一个文章的号码，
l=组中最后一个文章的号码
s=组名称。）
411 no such news group（组不存在）
Kantor & Lapsley [Page
11]
***************************************************************************
RFC 977 February
1986
Network News Transfer Protocol
文章来源于领测软件测试网 https://www.ltesting.net/
