新聞組傳送基本（建議）標準
本備忘錄地位
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"）�？蛇x參數
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 指令。
成功的選取應答將返回在這個新聞組群組中的第一個和最后一個文章的號碼，并
評估在這個群組中的文章數量。這個評估不一定必定是完全正確的。雖然這回很有用處
；但它必定和文件中的文章數相等或大于。（一些工具將可以計算文件中文章的實際數
量，另外，將最后的文章號減去第一個文章號可得到評估數量。）
當用這個指令選取了一個有效的新聞組（主題）后，新聞組中的第一個文章將被
設置為“當前文章（貼）”。如果指定了一個錯誤的組，那么以前選擇的組和貼將保持
。如果選擇一個空的組，“當前文章（貼）”將是不確定狀態并不會使用。
注意，當新聞組（主題）名稱在新聞組上沒有相應的組存在�？梢杂肔IST指令獲
取別的匹配的新聞組名稱或者會產生一個錯誤的計算結果。
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
文章來源于領測軟件測試網 http://www.kjueaiud.com/
