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

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

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

一些簡短的歷史背景

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

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

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

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

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

這些協(xié)議層被組織成一個層次結(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)是一個黑匣子，它只會傳送你提供的任意數(shù)據(jù)。因此，Level 0 是一個沒有真正協(xié)議的層，就公開已知和商定的規(guī)則集而言，它的存在可以被運(yùn)行在 ARPANET 的主機(jī)上的軟件忽略。粗略地說，它處理相當(dāng)于當(dāng)今使用的 TCP/IP 套件的物理層、鏈路層和網(wǎng)絡(luò)層下的所有內(nèi)容，甚至還包括相當(dāng)多的傳輸層，這是我將在這篇文章的末尾回來討論的內(nèi)容。

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

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

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

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

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

Host-Host 控制消息一般通過 3 個字母的助記符來表示。當(dāng)兩個主機(jī)交換一條 STR(發(fā)送端到接收端sender-to-receiver)消息和一條配對的 RTS(接收端到發(fā)送端receiver-to-sender)消息后，就建立起了一條連接 —— 這些控制消息都被稱為請求鏈接消息。鏈接能夠被 CLS(關(guān)閉close)控制消息關(guān)閉。還有更多的控制信息能夠改變從發(fā)送端到接收端發(fā)送消息的速率。從而再次需要確保較快的主機(jī)不會壓制較慢的主機(jī)。在 “Level 1” 層上的協(xié)議提供了流量控制的功能，但對 “Level 2” 層來說顯然是不夠的;我懷疑這是因?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)控制消息，主要供更高級別的協(xié)議使用。

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

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

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

與 TCP/IP 的比較

ARPANET 協(xié)議以后都會被 TCP/IP 協(xié)議替換(但 Telnet 和 FTP 協(xié)議除外，因?yàn)樗鼈兒苋菀拙湍茉?TCP 上適配運(yùn)行)。然而 ARPANET 協(xié)議都基于這么一個假設(shè)：就是網(wǎng)絡(luò)是由一個單一實(shí)體(BBN)來構(gòu)建和管理的。而 TCP/IP 協(xié)議套件是為網(wǎng)間網(wǎng)設(shè)計(jì)的，這是一個網(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)歷了一個糟糕的青春期。我不是網(wǎng)絡(luò)專家，因此我拿出大學(xué)時的網(wǎng)絡(luò)課本(讓我們跟著 Kurose 和 Ross 學(xué)習(xí)一下)，他們對傳輸層通常負(fù)責(zé)什么給出了一個非常好的概述。總結(jié)一下他們的解釋，一個傳輸層協(xié)議必須至少做到以下幾點(diǎn)。這里的 “段segment” 基本等同于 ARPANET 上的術(shù)語 “消息message”：

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

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

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

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

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

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

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