ARPANET 通過(guò)證明可以使用標(biāo)準(zhǔn)化協(xié)議連接完全不同的制造商的計(jì)算機(jī)，永遠(yuǎn)改變了計(jì)算。在我的 關(guān)于 ARPANET 的歷史意義的文章 中，我提到了其中的一些協(xié)議，但沒(méi)有詳細(xì)描述它們。所以我想仔細(xì)看看它們。也想看看那些早期協(xié)議的設(shè)計(jì)有多少保留到了我們今天使用的協(xié)議中。

ARPANET 協(xié)議像我們現(xiàn)代的互聯(lián)網(wǎng)協(xié)議，是通過(guò)分層形式來(lái)組織的。[1] 較高層協(xié)議運(yùn)行在較低層協(xié)議之上。如今的 TCP/IP 套件有 5 層(物理層、鏈路層、網(wǎng)絡(luò)層、傳輸層以及應(yīng)用層)，但是這個(gè) ARPANET 僅有 3 層，也可能是 4 層，這取決于你怎樣計(jì)算它們。

我將會(huì)解釋每一層是如何工作的，但首先，你需要知道是誰(shuí)在 ARPANET 中構(gòu)建了些什么，你需要知道這一點(diǎn)才能理解為什么這些層是這樣劃分的。

一些簡(jiǎn)短的歷史背景

ARPANET 由美國(guó)聯(lián)邦政府資助，確切的說(shuō)是位于美國(guó)國(guó)防部的高級(jí)研究計(jì)劃局Advanced Research Projects Agency(因此被命名為 “ARPANET” )。美國(guó)政府并沒(méi)有直接建設(shè)這個(gè)網(wǎng)絡(luò);而是，把這項(xiàng)工作外包給了位于波士頓的一家名為 “Bolt, Beranek, and Newman” 的咨詢公司，通常更多時(shí)候被稱為 BBN。

而 BBN 則承擔(dān)了實(shí)現(xiàn)這個(gè)網(wǎng)絡(luò)的大部分任務(wù)，但不是全部。BBN 所做的是設(shè)計(jì)和維護(hù)一種稱為接口消息處理機(jī)Interface Message Processor(簡(jiǎn)稱為 IMP) 的機(jī)器。這個(gè) IMP 是一種定制的霍尼韋爾Honeywell小型機(jī)minicomputer，它們被分配給那些想要接入這個(gè) ARPANET 的遍及全國(guó)各地的各個(gè)站點(diǎn)。它們充當(dāng)通往 ARPANET 的網(wǎng)關(guān)，為每個(gè)站點(diǎn)提供多達(dá)四臺(tái)主機(jī)的連接支持。它基本上是一臺(tái)路由器。BBN 控制在 IMP 上運(yùn)行的軟件，把數(shù)據(jù)包從一個(gè) IMP 轉(zhuǎn)發(fā)到另一個(gè) IMP ，但是該公司無(wú)法直接控制那些將要連接到 IMP 上并且成為 ARPANET 網(wǎng)絡(luò)中實(shí)際主機(jī)的機(jī)器。

那些主機(jī)由網(wǎng)絡(luò)中作為終端用戶的計(jì)算機(jī)科學(xué)家們所控制。這些計(jì)算機(jī)科學(xué)家在全國(guó)各地的主機(jī)站負(fù)責(zé)編寫(xiě)軟件，使主機(jī)之間能夠相互通訊。而 IMP 賦予主機(jī)之間互相發(fā)送消息的能力，但是那并沒(méi)有多大用處，除非主機(jī)之間能商定一種用于消息的格式。為了解決這個(gè)問(wèn)題，一群雜七雜八的人員組成了網(wǎng)絡(luò)工作組，其中有大部分是來(lái)自各個(gè)站點(diǎn)的研究生們，該組力求規(guī)定主機(jī)計(jì)算機(jī)使用的協(xié)議。

因此，如果你設(shè)想通過(guò) ARPANET 進(jìn)行一次成功的網(wǎng)絡(luò)互動(dòng)，(例如發(fā)送一封電子郵件)，使這些互動(dòng)成功的一些工程由一組人負(fù)責(zé)(BBN)，然而其他的一些工程則由另一組人負(fù)責(zé)(網(wǎng)絡(luò)工作組和在每個(gè)站點(diǎn)的工程師們)。這種組織和后勤方面的偶然性或許對(duì)推動(dòng)采用分層的方法來(lái)管理 ARPANET 網(wǎng)絡(luò)中的協(xié)議起到很大的作用，這反過(guò)來(lái)又影響了 TCP/IP 的分層方式。

好的，回到協(xié)議上來(lái)

這些協(xié)議層被組織成一個(gè)層次結(jié)構(gòu)，在最底部是 “Level 0”。[2] 這在某種意義上是不算數(shù)的，因?yàn)樵?ARPANET 中這層完全由 BBN 控制，所以不需要標(biāo)準(zhǔn)協(xié)議。Level 0 的作用是管理數(shù)據(jù)在 IMP 之間如何傳輸。在 BBN 內(nèi)部，有管理 IMP 如何做到這一點(diǎn)的規(guī)則;在 BBN 之外，IMP 子網(wǎng)是一個(gè)黑匣子，它只會(huì)傳送你提供的任意數(shù)據(jù)。因此，Level 0 是一個(gè)沒(méi)有真正協(xié)議的層，就公開(kāi)已知和商定的規(guī)則集而言，它的存在可以被運(yùn)行在 ARPANET 的主機(jī)上的軟件忽略。粗略地說(shuō)，它處理相當(dāng)于當(dāng)今使用的 TCP/IP 套件的物理層、鏈路層和網(wǎng)絡(luò)層下的所有內(nèi)容，甚至還包括相當(dāng)多的傳輸層，這是我將在這篇文章的末尾回來(lái)討論的內(nèi)容。

“Level 1” 層在 ARPANET 的主機(jī)和它們所連接的 IMP 之間建立了接口。如果你愿意，可以認(rèn)為它是為 BBN 構(gòu)建的 “Level 0” 層的黑匣子使用的一個(gè)應(yīng)用程序接口(API)。當(dāng)時(shí)它也被稱為 IMP-Host 協(xié)議。必須編寫(xiě)該協(xié)議并公布出來(lái)，因?yàn)樵谑状谓?ARPANET 網(wǎng)絡(luò)時(shí)，每個(gè)主機(jī)站點(diǎn)都必須編寫(xiě)自己的軟件來(lái)與 IMP 連接。除非 BBN 給他們一些指導(dǎo)，否則他們不會(huì)知道如何做到這一點(diǎn)。

BBN 在一份名為 BBN Report 1822 的冗長(zhǎng)文件中規(guī)定了 IMP-Host 協(xié)議。隨著 ARPANET 的發(fā)展，該文件多次被修訂;我將在這里大致描述 IMP-Host 協(xié)議最初設(shè)計(jì)時(shí)的工作方式。根據(jù) BBN 的規(guī)則，主機(jī)可以將長(zhǎng)度不超過(guò) 8095 位的消息傳遞給它們的 IMP，并且每條消息都有一個(gè)包含目標(biāo)主機(jī)號(hào)和鏈路識(shí)別號(hào)的頭部字段。[3] IMP 將檢查指定的主機(jī)號(hào)，然后盡職盡責(zé)地將消息轉(zhuǎn)發(fā)到網(wǎng)絡(luò)中。當(dāng)從遠(yuǎn)端主機(jī)接收到消息時(shí)，接收的 IMP 在將消息傳遞給本地主機(jī)之前會(huì)把目標(biāo)主機(jī)號(hào)替換為源主機(jī)號(hào)。實(shí)際上在 IMP 之間傳遞的內(nèi)容并不是消息 —— IMP 將消息分解成更小的數(shù)據(jù)包以便通過(guò)網(wǎng)絡(luò)傳輸 —— 但該細(xì)節(jié)對(duì)主機(jī)來(lái)說(shuō)是不可見(jiàn)的。

鏈路號(hào)的取值范圍為 0 到 255 ，它有兩個(gè)作用。一是更高級(jí)別的協(xié)議可以利用它在網(wǎng)絡(luò)上的任何兩臺(tái)主機(jī)之間建立多個(gè)通信信道，因?yàn)榭梢韵胂蟮玫?，在任何時(shí)刻都有可能存在多個(gè)本地用戶與同一個(gè)目標(biāo)主機(jī)進(jìn)行通信的場(chǎng)景(換句話說(shuō)，鏈路號(hào)允許在主機(jī)之間進(jìn)行多路通信)。二是它也被用在 “Level 1” 層去控制主機(jī)之間發(fā)送的大量流量，以防止高性能計(jì)算機(jī)壓制低性能計(jì)算機(jī)的情況出現(xiàn)。按照最初的設(shè)計(jì)，這個(gè) IMP-Host 協(xié)議限制每臺(tái)主機(jī)在某一時(shí)刻通過(guò)某條鏈路僅發(fā)送一條消息。一旦某臺(tái)主機(jī)沿著某條鏈路發(fā)送了一條消息給遠(yuǎn)端主機(jī)后，在它沿著該鏈路發(fā)送下一條消息之前，必須等待接收一條來(lái)自遠(yuǎn)端的 IMP 的特別類型的消息，叫做 RFNM(請(qǐng)求下一條消息Request for Next Message)。后來(lái)為了提高性能，對(duì)該系統(tǒng)進(jìn)行了修訂，允許一臺(tái)主機(jī)在給定的時(shí)刻傳送多達(dá) 8 條消息給另一臺(tái)主機(jī)。[4]

“Level 2” 層才是事情真正開(kāi)始變得有趣的地方，因?yàn)檫@一層和在它上面的那一層由 BBN 和國(guó)防部全部留給學(xué)者們和網(wǎng)絡(luò)工作組自己去研發(fā)。“Level 2” 層包括了 Host-Host 協(xié)議，這個(gè)協(xié)議最初在 RFC9 中草擬，并且在 RFC54 中首次正式規(guī)定。在 ARPANET 協(xié)議手冊(cè) 中有更易讀的 Host-Host 協(xié)議的解釋。

“Host-Host 協(xié)議” 管理主機(jī)之間如何創(chuàng)建和管理連接。“連接”是某個(gè)主機(jī)上的寫(xiě)套接字和另一個(gè)主機(jī)上的讀套接字之間的一個(gè)單向的數(shù)據(jù)管道。“套接字socket” 的概念是在 “Level-1” 層的有限的鏈路設(shè)施(記住，鏈路號(hào)只能是那 256 個(gè)值中的一個(gè))之上被引入的，是為了給程序提供尋址運(yùn)行在遠(yuǎn)端主機(jī)上的特定進(jìn)程的一種方式。“讀套接字” 是用偶數(shù)表示的，而“寫(xiě)套接字”是用奇數(shù)表示的;套接字是 “讀” 還是 “寫(xiě)” 被稱為套接字的 “性別”。并沒(méi)有類似于 TCP 協(xié)議那樣的 “端口號(hào)” 機(jī)制，連接的打開(kāi)、維持以及關(guān)閉操作是通過(guò)主機(jī)之間使用 “鏈路 0” 發(fā)送指定格式的 Host-Host 控制消息來(lái)實(shí)現(xiàn)的，這也是 “鏈路 0” 被保留的目的。一旦在 “鏈路 0” 上交換控制消息來(lái)建立起一個(gè)連接后，就可以使用接收端挑選的另一個(gè)鏈路號(hào)來(lái)發(fā)送進(jìn)一步的數(shù)據(jù)消息。

Host-Host 控制消息一般通過(guò) 3 個(gè)字母的助記符來(lái)表示。當(dāng)兩個(gè)主機(jī)交換一條 STR(發(fā)送端到接收端sender-to-receiver)消息和一條配對(duì)的 RTS(接收端到發(fā)送端receiver-to-sender)消息后，就建立起了一條連接 —— 這些控制消息都被稱為請(qǐng)求鏈接消息。鏈接能夠被 CLS(關(guān)閉close)控制消息關(guān)閉。還有更多的控制信息能夠改變從發(fā)送端到接收端發(fā)送消息的速率。從而再次需要確保較快的主機(jī)不會(huì)壓制較慢的主機(jī)。在 “Level 1” 層上的協(xié)議提供了流量控制的功能，但對(duì) “Level 2” 層來(lái)說(shuō)顯然是不夠的;我懷疑這是因?yàn)閺倪h(yuǎn)端 IMP 接收到的 RFNM 只能保證遠(yuǎn)端 IMP 已經(jīng)傳送該消息到目標(biāo)主機(jī)，而不能保證目標(biāo)主機(jī)已經(jīng)全部處理了該消息。還有 INR(接收端中斷interrupt-by-receiver)、INS(發(fā)送端中斷interrupt-by-sender)控制消息，主要供更高級(jí)別的協(xié)議使用。

更高級(jí)別的協(xié)議都位于 “Level 3”，這層是 ARPANET 的應(yīng)用層。Telnet 協(xié)議，它提供到另一臺(tái)主機(jī)的一個(gè)虛擬電傳鏈接，其可能是這些協(xié)議中最重要的。但在這層中也有許多其他協(xié)議，例如用于傳輸文件的 FTP 協(xié)議和各種用于發(fā)送 Email 的協(xié)議實(shí)驗(yàn)。

在這一層中有一個(gè)不同于其他的協(xié)議：初始鏈接協(xié)議Initial Connection Protocol(ICP)。ICP 被認(rèn)為是一個(gè) “Level-3” 層協(xié)議，但實(shí)際上它是一種 “Level-2.5” 層協(xié)議，因?yàn)槠渌?“Level-3” 層協(xié)議都依賴它。之所以需要 ICP，是因?yàn)?“Level 2” 層的 Host-Host 協(xié)議提供的鏈接只是單向的，但大多數(shù)的應(yīng)用需要一個(gè)雙向(例如：全雙工)的連接來(lái)做任何有趣的事情。要使得運(yùn)行在某個(gè)主機(jī)上的客戶端能夠連接到另一個(gè)主機(jī)上的長(zhǎng)期運(yùn)行的服務(wù)進(jìn)程，ICP 定義了兩個(gè)步驟。第一步是建立一個(gè)從服務(wù)端到客戶端的單向連接，通過(guò)使用服務(wù)端進(jìn)程的眾所周知的套接字號(hào)來(lái)實(shí)現(xiàn)。第二步服務(wù)端通過(guò)建立的這個(gè)連接發(fā)送一個(gè)新的套接字套接字號(hào)給客戶端。到那時(shí)，那個(gè)存在的連接就會(huì)被丟棄，然后會(huì)打開(kāi)另外兩個(gè)新的連接，它們是基于傳輸?shù)奶捉幼痔?hào)建立的“讀”連接和基于傳輸?shù)奶捉幼痔?hào)加 1 的“寫(xiě)”連接。這個(gè)小插曲是大多數(shù)事務(wù)的一個(gè)前提——比如它是建立 Telnet 鏈接的第一步。

以上是我們逐層攀登了 ARPANET 協(xié)議層次結(jié)構(gòu)。你們可能一直期待我在某個(gè)時(shí)候提一下 “網(wǎng)絡(luò)控制協(xié)議Network Control Protocol”(NCP) 。在我坐下來(lái)為這篇文章和上一篇文章做研究之前，我肯定認(rèn)為 ARPANET 運(yùn)行在一個(gè)叫 “NCP” 的協(xié)議之上。這個(gè)縮寫(xiě)有時(shí)用來(lái)指代整個(gè) ARPANET 協(xié)議，這可能就是我為什么有這個(gè)想法的原因。舉個(gè)例子，RFC801 討論了將 ARPANET 從 “NCP” 過(guò)渡到 “TCP” 的方式，這使 NCP 聽(tīng)起來(lái)像是一個(gè)相當(dāng)于 TCP 的 ARPANET 協(xié)議。但是對(duì)于 ARPANET 來(lái)說(shuō)，從來(lái)都沒(méi)有一個(gè)叫 “網(wǎng)絡(luò)控制協(xié)議” 的東西(即使 大英百科全書(shū)是這樣認(rèn)為的)，我懷疑人們錯(cuò)誤地將 “NCP” 解釋為 “網(wǎng)絡(luò)控制協(xié)議Network Control Protocol” ，而實(shí)際上它代表的是 “網(wǎng)絡(luò)控制程序Network Control Program” 。網(wǎng)絡(luò)控制程序是一個(gè)運(yùn)行在各個(gè)主機(jī)上的內(nèi)核級(jí)別的程序，主要負(fù)責(zé)處理網(wǎng)絡(luò)通信，等同于現(xiàn)如今操作系統(tǒng)中的 TCP/IP 協(xié)議棧。用在 RFC 801 的 “NCP” 是一種轉(zhuǎn)喻，而不是協(xié)議。

與 TCP/IP 的比較

ARPANET 協(xié)議以后都會(huì)被 TCP/IP 協(xié)議替換(但 Telnet 和 FTP 協(xié)議除外，因?yàn)樗鼈兒苋菀拙湍茉?TCP 上適配運(yùn)行)。然而 ARPANET 協(xié)議都基于這么一個(gè)假設(shè)：就是網(wǎng)絡(luò)是由一個(gè)單一實(shí)體(BBN)來(lái)構(gòu)建和管理的。而 TCP/IP 協(xié)議套件是為網(wǎng)間網(wǎng)設(shè)計(jì)的，這是一個(gè)網(wǎng)絡(luò)的網(wǎng)絡(luò)，在那里一切都是不穩(wěn)定的和不可靠的。這就導(dǎo)致了我們的現(xiàn)代協(xié)議套件和 ARPANET 協(xié)議有明顯的不同，比如我們現(xiàn)在怎樣區(qū)分網(wǎng)絡(luò)層和傳輸層。在 ARPANET 中部分由 IMP 實(shí)現(xiàn)的類似傳輸層的功能現(xiàn)在完全由在網(wǎng)絡(luò)邊界的主機(jī)負(fù)責(zé)。

我發(fā)現(xiàn) ARPANET 協(xié)議最有趣的事情是，現(xiàn)在在 TCP 中的許多傳輸層的功能是如何在 ARPANET 上經(jīng)歷了一個(gè)糟糕的青春期。我不是網(wǎng)絡(luò)專家，因此我拿出大學(xué)時(shí)的網(wǎng)絡(luò)課本(讓我們跟著 Kurose 和 Ross 學(xué)習(xí)一下)，他們對(duì)傳輸層通常負(fù)責(zé)什么給出了一個(gè)非常好的概述?？偨Y(jié)一下他們的解釋，一個(gè)傳輸層協(xié)議必須至少做到以下幾點(diǎn)。這里的 “段segment” 基本等同于 ARPANET 上的術(shù)語(yǔ) “消息message”：

• 提供進(jìn)程之間的傳送服務(wù)，而不僅僅是主機(jī)之間的(傳輸層多路復(fù)用和多路分解)
• 在每個(gè)段的基礎(chǔ)上提供完整性檢查(即確保傳輸過(guò)程中沒(méi)有數(shù)據(jù)損壞)

像 TCP 那樣，傳輸層也能夠提供可靠的數(shù)據(jù)傳輸，這意味著：

• “段” 是按順序被傳送的
• 不會(huì)丟失任何 “段”
• “段” 的傳送速度不會(huì)太快以至于被接收端丟棄(流量控制)

似乎在 ARPANET 上關(guān)于如何進(jìn)行多路復(fù)用和多路分解以便進(jìn)程可以通信存在一些混淆 —— BBN 在 IMP-Host 層引入了鏈路號(hào)來(lái)做到這一點(diǎn)，但結(jié)果證明在 Host-Host 層上無(wú)論如何套接字號(hào)都是必要的。然后鏈路號(hào)只是用于 IMP-Host 級(jí)別的流量控制，但 BBN 似乎后來(lái)放棄了它，轉(zhuǎn)而支持在唯一的主機(jī)對(duì)之間進(jìn)行流量控制，這意味著鏈路號(hào)一開(kāi)始是一個(gè)超載的東西，后來(lái)基本上變成了虛設(shè)。TCP 現(xiàn)在使用端口號(hào)代替，分別對(duì)每一個(gè) TCP 連接單獨(dú)進(jìn)行流量控制。進(jìn)程間的多路復(fù)用和多路分解完全在 TCP 內(nèi)部進(jìn)行，不會(huì)像 ARPANET 一樣泄露到較低層去。

同樣有趣的是，鑒于 Kurose 和 Ross 如何開(kāi)發(fā) TCP 背后的想法，ARPANET 一開(kāi)始就采用了 Kurose 和 Ross 所說(shuō)的一個(gè)嚴(yán)謹(jǐn)?shù)? “停止并等待stop-and-wait” 方法，來(lái)實(shí)現(xiàn) IMP-Host 層上的可靠的數(shù)據(jù)傳輸。這個(gè) “停止并等待” 方法發(fā)送一個(gè) “段” 然后就拒絕再去發(fā)送更多 “段” ，直到收到一個(gè)最近發(fā)送的 “段” 的確認(rèn)為止。這是一種簡(jiǎn)單的方法，但這意味著只有一個(gè) “段” 在整個(gè)網(wǎng)絡(luò)中運(yùn)行，從而導(dǎo)致協(xié)議非常緩慢 —— 這就是為什么 Kurose 和 Ross 將 “停止并等待” 僅僅作為在通往功能齊全的傳輸層協(xié)議的路上的墊腳石的原因。曾有一段時(shí)間 “停止并等待” 是 ARPANET 上的工作方式，因?yàn)樵?IMP–Host 層，必須接收到請(qǐng)求下一條消息Request for Next Message(RFNM)以響應(yīng)每條發(fā)出的消息，然后才能發(fā)送任何進(jìn)一步的消息。客觀的說(shuō) ，BBN 起初認(rèn)為這對(duì)于提供主機(jī)之間的流量控制是必要的，因此減速是故意的。正如我已經(jīng)提到的，為了更好的性能，RFNM 的要求后來(lái)放寬松了，而且 IMP 也開(kāi)始向消息中添加序列號(hào)和保持對(duì)傳輸中的消息的 “窗口” 的跟蹤，這或多或少與如今 TCP 的實(shí)現(xiàn)如出一轍。[5]

因此，ARPANET 表明，如果你能讓每個(gè)人都遵守一些基本規(guī)則，異構(gòu)計(jì)算系統(tǒng)之間的通信是可能的。正如我先前所說(shuō)的，這是 ARPANET 的最重要的遺產(chǎn)。但是，我希望對(duì)這些基線規(guī)則的仔細(xì)研究揭示了 ARPANET 協(xié)議對(duì)我們今天使用的協(xié)議有多大影響。在主機(jī)和 IMP 之間分擔(dān)傳輸層職責(zé)的方式上肯定有很多笨拙之處，有時(shí)候是冗余的。現(xiàn)在回想起來(lái)真的很可笑，主機(jī)之間一開(kāi)始只能通過(guò)給出的任意鏈路在某刻只發(fā)送一條消息。但是 ARPANET 實(shí)驗(yàn)是一個(gè)獨(dú)特的機(jī)會(huì)，可以通過(guò)實(shí)際構(gòu)建和操作網(wǎng)絡(luò)來(lái)學(xué)習(xí)這些經(jīng)驗(yàn)，當(dāng)?shù)搅耸菚r(shí)候升級(jí)到我們今天所知的互聯(lián)網(wǎng)時(shí)，似乎這些經(jīng)驗(yàn)變得很有用。

1. 協(xié)議分層是網(wǎng)絡(luò)工作組發(fā)明的。這個(gè)論點(diǎn)是在 RFC 871 中提出的。分層也是 BBN 如何在主機(jī)和 IMP 之間劃分職責(zé)的自然延伸，因此 BBN 也值得稱贊。
2. “level” 是被網(wǎng)絡(luò)工作組使用的術(shù)語(yǔ)。 詳見(jiàn) RFC 100
3. 在 IMP-Host 協(xié)議的后續(xù)版本中，擴(kuò)展了頭部字段，并且將鏈路號(hào)升級(jí)為消息 ID。但是 Host-Host 協(xié)議僅僅繼續(xù)使用消息 ID 字段的高位 8 位，并將其視為鏈路號(hào)。請(qǐng)參閱 ARPANET 協(xié)議手冊(cè) 的 “Host-Host” 協(xié)議部分。
4. John M. McQuillan 和 David C. Walden。 “ARPA 網(wǎng)絡(luò)設(shè)計(jì)決策”，第 284頁(yè)，https://www.walden-family.com/public/whole-paper.pdf。 2021 年 3 月 8 日查看。
5. 同上。