介紹
在游說了網絡共同體之后，傳輸協議故障清除委員會于1971年3月8日至9日
在加利福尼亞州立大學洛杉磯分校舉行了第二次會議。委員會第一次略微擴大
會議的結果以RFC102號文件的形式備案。委員會同意就1號文件中的協議進行
個別的修改，所涉及的修改如下。
每次會議上，委員會很快地處理除了一個突出課題之外的所有的主題。第
一次會議中，大部分時間被用來考慮中斷機制，并且討論結果被概括為RFC102
號文件。在第二次會議上，委員會花費幾乎所有的時間討論字節的概念，這一
討論結果在修改列表之后加以總結。
本RFC文檔將全部取代RFC102號文件，并且作為1號文檔的官方修訂。1號文
檔的修訂版將被簡單地述及，并且與這里列出的修改列表合并。
網絡控制程序的制訂人將盡快合并這些變動。網絡控制程序的制訂人還將
估計這些網絡控制程序將于何時預備就緒，并將上述推算向SteveCrocker或他
的秘書Byrnakristel通報。

修改
1字節
迄今為止，一個聯接一直是一個位流。從今以后，它將是一個字節流，具
有字節長度S，在每一消息報文的STR命令中給出。該字節長度滿足約束：
1<=S<=255.
某一聯接字節長度的選擇是一個第三級協議的問題，但是字節長度在此聯接
的使用期限內是一個常數。每一條消息報文必須包含整數個正文字節（見下文）。

2報文格式
報文格式被轉換為如圖１所示的格式。
字段S和C分別代表字節長度與字節數。
字段S有8位，必須與創建聯接的STR中聲明的字節長度相匹配。字段C是16
位長的，它說明該消息報文中正文部分字節的數目。字段C中的零值容許存在，
但無做任何使用。
M1與M2字段長都必須為8位，且必須包含零。字段M3必須為存在，且必須全
部為零。字段M3可以用來向一個字的邊界填寫消息報文。并隨后填充補全。




32bits
<--------------------------------->

+-----------------------------------+

leader

+--------+--------+-----------------+

M1SC

+--------+--------+-----------------+
^
M2

+--------+



Text
////




+--------+

M3
v
+-----------------+--------+--------+

10---------0<--Padding

+-----------------+

TypicalMessage

圖1
正文字段由C字節組成，每個字節長S位。該正文字段開始于消息報文的開始
點72位之后。
子網必須能夠將字節流分割為消息報文。消息報文邊界上并不附加任何語
義成分。非凡地：
1. 對于C而言，盡管一個具有零值的消息報文是合法的，但其用盡了資源
分配，且是無意義的。（見后文的流控制）
2. 接收器并不期望與消息報文邊界同步的第三級控制信息。非凡地，假如
記錄被聲明為對聯接進行定義，則接收器必須等候多記錄或一個消息報
文中的記錄碎片。（然而控制信息遵守非凡的規則，見下文）

3消息報文數據類型
數據類型并不作為第二級協議的一部分而加以定義。
第三級協議則可包括該定義。數據類型不可能在消息報文邊界同步。

4重置與重置應答
添加了一對新的一位控制信號RST（reset）和RRP（resetreply）。RST
信號被解釋為一個用于由發送給RST的主人產生的所有存在的入口的網絡控制程
序表的信號。主機接收RRP信號表示對RST信號的確認。發送RST信號的主機可
以在收到一個RST信號或一個應答RRP信號之后繼續請求聯接。假如在第一個主
機之后出現第二個主機，則返回一個RST信號。

5流量控制
流量控制方法從兩方面發生了變化。首先，中止機制被停用。10HI和11HI
消息報文將不再被辨別為Imps，并且該Imps也將不再生成10HI、11HI或12HI消息
報文。
其次，分配機制此刻處理二個量：位與消息報文。接收器給這些量中間的
每一個分別地分派。發送器與接收器必須為消息報文保留一個16位無符號計數
器，并為位保留一個32位無符號計算器。
發送消息報文時，發送器從該消息報文計數器減一，并且將位計數器的正文
長度也減一。接收器在收到該消息報文的時候同樣地遞減其計數器。假如任何
一個計數器將要遞減至低于零，則禁止發送器繼續發送。同樣地，也禁止接收
器生產當前消息報文的大于2**16-1的分配，以及超過2**32-1的當前位的分配。
消息報文的正文長度是S（字節長度）和C（字節數）的乘積。如報文格式
內所述，這些值總出現在消息報文的第一部分。
ALL、GVB和RET命令將被修正以便處理上述二個數值。
如下，它們的格式由控制命令給出。GVB命令被進一步修改以使其可以請求
返回空分配。新的GVB命令有4個8位字段。如前所述，開頭兩個字段是該操作
碼和連接。
下兩個字段包含號碼fM和fB，用于控制返回消息報文和分配的多少。假如
這些號碼在0到128的范圍內，則被解釋為："當前分配的第128個"。假如這些號
碼在128到255的范圍內，則被解釋為："當前分配的全體"。

6控制信號
控制連接被改為鏈接0；連接1不再使用。因此，新舊協議可以共存。
根據上面對報文格式的描述，控制鏈路中發送的消息報文與其他常規消息報
文具有同樣的格式。字節長度字段必須包含值8。
控制信號不能包含多于120字節的正文。因此，字節數字段的值最大為120。
這些限制是為了對小型主機有所幫助。
控制信號必須包含整數個控制命令。
因此，控制命令不能夠被控制信號分開。

7連接指派
當前連接被分配如下：
0控制連接
1舊協議控制連接，將被逐步淘汰
2-31聯接的連接
32-190保留
191僅為加利福尼亞大學洛杉磯分校的網絡測量中心使用
192-255對任何獨立實驗有效

8定長控制命令
ECO、ERP和ERR命令具有固定長度。ECO和ERP命令的長度為16位，包括8位
操作碼和8為數據。ERR命令目前長度為96位，包括8位操作碼，8位錯誤碼，以及
80位文本。80位對于保存最長的非ERR控制命令來說也是足夠的。

9控制命令的格式
如上所述，STR、ALL、GVB、RET、ECO、ERP和ERR命令的格式已經變動。;并
添加了RST和RRP命令。
這些命令的格式如下：





832328
+-----+-----------------------+-----------------------+-----+

1.STRsendsocketreceivesocket
^
+-----+-----------------------+-----------------------+----+

881632+--bytesize
+-----+-----+-----------+-----------------------+

2.ALLlinkmsgspacebitspace

+-----+-----+-----------+-----------------------+
881632
+-----+-----+-----------+-----------------------+

3.RETlinkmsgspacebitspace

+-----+-----+-----------+-----------------------+
8888
+-----+-----+-----+-----+

4.GVBlinkfMfB
^^
+-----+-----+----+----+

+--bitfraction
+--------messagefraction
88
+-----+-----+

5.ECOdata

+-----+-----+
88
+-----+-----+

6.ERPdata

+-----+-----+
8880
+-----+-----+----------------------//-----------------------+

7.ERRtext
^
+-----+----+----------------------//-----------------------+

+--errorcode
8
+-----+

8.RST

+-----+
8
+-----+

9.RRP

+-----+

操作碼的值為：
NOP=0
RTS=1
STR=2
CLS=3
ALL=4
GVB=5
RET=6
INR=7
INS=8
ECO=9
ERP=10
ERR=11
RST=12
RRP=13

關于字節流的討論
之前關于聯接應成為位流的管道的規范具有最廣泛的普遍性，然而效率卻最
低。這里考慮了來自提高效率的壓力及其相關問題。
位流產生了低效率的兩種類型。
1. 接收方主機被請求進行費用浩大的轉型工作，以使相繼的消息報文的正
文串聯在一起。發送方主機還不得不經常變換正文域，以使它們在字
的邊界上相匹配。
2. 假如有可能，哪怕是僅發送一位，也禁止發送方網絡控制程序將ANY文
本以不確定的時間保存。這些條件對防止任何可能的停頓來說是必須
的。例如：假定進程A和B在一對聯接上正在進行會話，每個進程一個
方向。同時還假設這些進程對于輸入的每一位也剛好只生成一位輸出。
那么，假如進程A的網絡控制程序由于想要將一個等待位和在其之后的
來自進程A的計算輸出包裝起來，而沒能及時發送這一等待位，則進程B
將不能進行輸出，B也同樣。于是很明顯，除非發送方網絡控制程序
的緩沖中存在一定量的不為接收放所必須的的數據，發送方網絡控制程
序必須假定別的方式并且及時發送數據。
這些考慮導致了"傳輸單位"這一概念，并須為網絡控制程序所知。這個問
題即變為典型的及可能的傳輸單位大小為何的問題。對于面向字符的交互，8位
的傳輸單位傳遞單位似乎很合理。而對于面向鏈路的交互，該傳輸單位最好為
該鏈路本身，并且長度可變。換句話說，最好認為該傳輸單位是一個字符。對
于文件傳輸，傳輸單位最好為兩機器字長度的倍數。然而，假如傳輸單位過大的
話，文檔的最后一部分可能不來自整個傳輸單位。此時，要想取得一致，則該
傳輸單位應該任意可分，且應足夠小。于是，該傳輸單位的概念似乎與字節等
量，且傳輸單位的限制也降低了。
隨后關于停頓和喚醒方面的討論顯示出，可能會有二個字節與單個聯接關
聯：
1. 來自發送方進程向發送方網絡控制程序的傳輸的長度為S。發送方網
絡控制程序必須在連接被解鎖時發送一個消息報文。消息報文計數器最
少為1。位計數器最少為S，并且正文的最小S位已經就緒。該消息報文
必須包含整數個字節。
2. 在接收端，對于從接收方網絡控制程序到接收方進程的傳輸可能有一個
不同的字節長度R。R<>S處的一例子由UCSB給出，它為透明地存儲二進
制文件提供了一個文件系統。使用中的主機隨36位字節發送是合理的，
盡管UCSB文件系統想要的接收可能多于32位。
很明顯，從網絡協議的觀點來看，僅字節S是相關的，并且為在每個消息報
文中的STR命令中通信的量。字節長度R的選擇取決于接收方用戶，并且它的意
指接收方網絡控制程序將喚醒接收方處理的頻率。同時也可能出現這種情況：
即接收方進程與接收方網絡控制程序之間建立了一個比"請每R位喚醒我"更復雜
的協定。例如：網絡控制程序可以在喚醒接收方進程之前掃瞄并捕捉換行字符。
在新協議中，接收器可以根據提供的字節長度來判定是否拒絕某一聯接請
求。
從概念出發，我們可以想象網絡控制程序能夠處理全部字節長度，并且這種
選擇可以一直維持到第三級程序（用戶程序、日志記錄器、遠程登錄等等）。一
些主機，非凡是小型主機，可以把握足夠的關于它們的三級程序的知識，以限制
字節的種類，以及哪個可以被發送，哪個可以被接收。盡管它是一個局部政策
的問題，委員會仍然強烈建議網絡控制程序能夠對全部字節進行處理。此外，
我們的委員會之一強烈地感覺到網絡控制程序應被寫成能夠為到用戶進程的傳
輸提供不同字節長度R，以及能夠接收全部字節S的程序。

[本RFC文檔由EnricoBertone于97年4月]
[編為機器可讀形式以便錄入RFC在線檔案]
RFC107——OutputoftheHost-HostPRotocolGlitchCleaningCommittee
主機-主機協議故障清除委員會的說明