RARP：逆位址解析通訊協定

具有本地磁碟的系統引導時，一般是從磁碟上的設定檔中讀取IP地址。但是無盤機，如X終端或無盤工作站，則需要採用其他方法來獲得IP地址。
網路上的每個系統都具有唯一的硬體地址，它是由網路介面生產廠家配置的。無盤系統的RARP實現過程是從介面卡上讀取唯一的硬體地址，然後發送一份RARP請求（一幀在網路上廣播的資料），請求某個主機響應該無盤系統的IP地址（在RARP應答中）。
在概念上這個過程是很簡單的，但是實現起來常常比ARP要困難，其原因在本章後面介紹。RARP的正式規範是RFC903[Finlaysonetal.1984]。

RARP的分組格式

RARP分組的格式與ARP分組基本一致（見圖4-3）。它們之間主要的差別是RARP請求或應答的框架類型代碼為0x8035，而且RARP請求的作業碼為3，應答作業碼為4。對應於ARP，RARP請求以廣播方式傳送，而RARP應答一般是單播(unicast)傳送的。

RARP舉例

在互連網中，我們可以強制sun主機從網路上引導，而不是從本地磁碟引導。如果在主機bsdi上運行RARP服務程式和tcpdump命令，就可以得到5-1那樣的輸出。-e參數使得tcpdump命令列印出硬體地址：
 

圖5-1 RARP請求和應答R A R P請求是廣播方式（第1行），而第2行的R A R P應答是單播方式。第2行的輸出中a t s u n表示R A R P應答包含主機s u n的I P地址（1 4 0 . 2 5 2 . 1 3 . 3 3）。
在第3行中，我們可以看到，一旦s u n收到I P地址，它就發送一個T F T P讀請求（R R Q）給檔案8 C F C0 D 2 1 . S U N 4 C（T F T P表示簡單檔案傳送協議。我們將在第1 5章詳細介紹）。檔案名稱中的8個十六進位數字表求主機s u n的I P地址1 4 0 . 2 5 2 . 1 3 . 3 3。這個I P地址在R A R P應答中返回。檔案名稱的尾碼S U N 4 C表示被引導系統的類型。
t c p d u m p在第3行中指出I P資料報的長度是6 5個位元組，而不是一個U D P資料報（實際上是一個U D P資料報），因為我們運行t c p d u m p命令時帶有-e參數，以查看硬體層的地址。在圖5 - 1中需要指出的另一點是，第2行中的乙太網路資料幀長度比最小長度還要小（在4 . 5節中我們說過應該是6 0位元組）。其原因是我們在發送該乙太網路資料幀的系統（b s d i）上運行t c p d u m p命令。應用程式r a r p d寫4 2位元組到B S D分組過濾裝置上（其中1 4位元組為乙太網路資料幀的前序，剩下的2 8位元組是R A R P應答），這就是t c p d u m p收到的副本。但是乙太網路裝置驅動程式要把這一短幀填充空白字元以達到最小傳輸長度（6 0）。如果我們在另一個系統上運行t c p d u m p命令，其長度將會是6 0。
從這個例子可以看出，當無盤系統從R A R P應答中收到它的I P地址後，它將發送T F T P請求來讀取引導映象。在這一點上我們將不再進一步詳細討論無盤系統是如何引導的（第1 6章將描述無盤X終端利用R A R P、B O O T P以及T F T P進行引導的過程）。
當網路上沒有R A R P伺服器時，其結果5 - 2所示。每個分組的目的地址都是乙太網路廣播位址。在w h o-後面的乙太網路地址是目的硬體地址，跟在t e l l後面的乙太網路地址是發送端的硬體地址。
請注意重發的頻度。第一次重發是在6 . 5 5秒以後，然後增加到4 2 . 8 0秒，然後又減到5 . 3 4 秒和6 .5 5秒，然後又回到4 2 . 7 9秒。這種不確定的情況一直繼續下去。如果計算一下兩次重發之間的時間間隔，我們發現存在一種雙倍的關係：從5 . 3 4到6 . 5 5是1 . 2 1秒，從6 . 5 5到8 . 9 7是2 . 4 2秒，從8 . 9 7到1 3 . 8 0是4 . 8 3秒，一直這樣繼續下去。當時間間隔達到某個閾值時（大於4 2 . 8 0秒），它又重新置為5 . 3 4秒。逾時間隔採用這樣的遞增方法比每次都採用相同值的方法要好。在圖6 - 8中，我們將看到一種錯誤的逾時重發方法，以及在第2 1章中將看到T C P的逾時重發機制。

圖5-2 網路中沒有RARP伺服器的RARP請求
RARP伺服器的設計

雖然R A R P在概念上很簡單，但是一個R A R P伺服器的設計與系統相關而且比較複雜。相反，提供一個A R P伺服器很簡單，通常是T C P / I P在核心中實現的一部分。由於核心知道I P地址和硬體地址，因此當它收到一個詢問I P地址的A R P請求時，只需用相應的硬體地址來提供應答就可以了。

作為使用者進程的RARP伺服器

R A R P伺服器的複雜性在於，伺服器一般要為多個主機（網路上所有的無盤系統）提供硬體地址到I P地址的映射。該映射包含在一個磁碟檔案中（在U n i x系統中一般位於/ e t c / e t h e r s目錄中）。由於核心一般不讀取和分析磁碟檔案，因此R A R P伺服器的功能就由使用者進程來提供，而不是作為核心的T C P / I P實現的一部分。
更為複雜的是，R A R P請求是作為一個特殊類型的乙太網路資料幀來傳送的（框架類型欄位值為0 x 8 0 3 5，2 - 1所示）。這說明R A R P伺服器必須能夠發送和接收這種類型的乙太網路資料幀。在附錄A中，我們描述了B S D分組過濾器、S u n的網路介面栓以及S V R 4資料鏈路提供者介面都可用來接收這些資料幀。由於發送和接收這些資料幀與系統有關，因此R A R P伺服器的實現是與系統捆綁在一起的。

每個網路有多個RARP伺服器

R A R P伺服器實現的一個複雜因素是R A R P請求是在硬體層上進行廣播的，5 - 2所示。這意味著它們不經過路由器進行轉寄。為了讓無盤系統在R A R P伺服器關機的狀態下也能引導，通常在一個網路上（例如一根電纜）要提供多個R A R P伺服器。當伺服器的數目增加時（以提供冗餘備份），網路流量也隨之增加，因為每個伺服器對每個R A R P請求都要發送R A R P應答。發送R A R P請求的無盤系統一般採用最先收到的R A R P應答（對於A R P，我們從來沒有遇到這種情況，因為只有一台主機發送A R P應答）。另外，還有一種可能發生的情況是每個R A R P伺服器同時應答，這樣會增加乙太網路發生衝突的機率。