反向地址轉換協議

出自 MBA智库百科(https://wiki.mbalib.com/)

反向地址轉換協議(Reverse Address Resolution Protocol; RARP)

　　反向地址轉換協議是指一種網路協議，允許區域網的物理機器從網關伺服器的ARP表或者緩存上請求其IP地址。

　　RARP使用與ARP相同的報頭結構，作用與ARP相反。RARP用於將MAC地址轉換為IP地址。其因為較限於IP地址的運用以及其他的一些缺點，因此漸為更新的BOOTP或DHCP所取代。

　　RARP以與ARP相反的方式工作。RARP發出要反向解析的物理地址並希望返回其對應的IP地址，應答包括由能夠提供所需信息的RARP伺服器發出的IP地址。雖然發送方發出的是廣播信息，RARP規定只有RARP伺服器能產生應答。許多網路指定多個RARP伺服器，這樣做既是為了平衡負載也是為了作為出現問題時的備份。

　　具有本地磁碟的系統引導時，一般是從磁碟上的配置文件中讀取IP地址。但是無盤機，如X終端或無盤工作站，則需要採用其他方法來獲得IP地址。網路上的每個系統都具有唯一的硬體地址，它是由網路介面生產廠家配置的。無盤系統的RARP實現過程是從介面卡上讀取唯一的硬體地址，然後發送一份RARP請求（一幀在網路上廣播的數據），請求某個主機響應該無盤系統的IP地址（在RARP應答中）。為用戶進程的RARP伺服器的複雜性在於：伺服器一般要為多個主機（網路上所有的無盤系統）提供硬體地址到IP地址的映射。該映射包含在一個磁碟文件中（在Unix系統中一般位於/etc/ethers目錄中）。由於內核一般不讀取和分析磁碟文件，因此RARP伺服器的功能就由用戶進程來提供，而不是作為內核的TCP/IP實現的一部分。

　　更為複雜的是，RARP請求是作為一個特殊類型的乙太網數據幀來傳送的（幀類型欄位值為0x8035）。這說明RARP伺服器必須能夠發送和接收這種類型的乙太網數據幀。由於發送和接收這些數據幀與系統有關，因此RARP伺服器的實現是與系統捆綁在一起的。 每個網路有多個RARP伺服器實現的一個複雜因素是RARP請求是在硬體層上進行廣播的。這意味著它們不經過路由器進行轉發。為了讓無盤系統在RARP伺服器關機的狀態下也能引導，通常在一個網路上（例如一根電纜）要提供多個RARP伺服器。當伺服器的數目增加時（以提供冗餘備份），網路流量也隨之增加，因為每個伺服器對每個RARP請求都要發送RARP應答。發送RARP請求的無盤系統一般採用最先收到的RARP應答。另外，還有一種可能發生的情況是每個RARP伺服器同時應答，這樣會增加乙太網發生衝突的概率。

　　1. 將源設備和目標設備的MAC地址欄位都設為發送者的MAC地址和IP地址，發送主機發送一個本地的RARP廣播，能夠到達網路上的所有設備，在此廣播包中，聲明自己的MAC地址並且請求任何收到此請求的RARP伺服器分配一個IP地址；

　　2. 本地網段上的RARP伺服器收到此請求後，檢查其RARP列表，查找該MAC地址對應的IP地址；

　　3. 如果存在，RARP伺服器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用；如果不存在，RARP伺服器對此不做任何的響應；

　　4. 源主機收到從RARP伺服器的響應信息，就利用得到的IP地址進行通訊；如果一直沒有收到RARP伺服器的響應信息，表示初始化失敗。

　　解決RARP回應問題的兩種方法。

1. 為每一個做 RARP 請求的主機分配一主伺服器，正常來說，只有主伺服器才會做出 RARP 回應，其它主機只是記錄下接收到 RARP 請求的時間。假如主伺服器不能順利做出回應，那麼查詢主機在等待逾時再次用廣播方式發送 RARP 請求，其它非主伺服器假如在接到第一個請求後很短時間內再收到相同請求的話，才會做出回應動作。
2. 正常來說，當主伺服器收到 RARP 請求之後，會直接做出回應；為避免所有非主伺服器同時傳回 RARP 回應，每台非主伺服器都會隨機等待一段時間再做出回應。如果主伺服器未能做出回應的話，查詢主機會延遲一段時間再進行第二次請求，以確保這段時間內獲得非主伺服器的回應。當然，設計者可以精心的設計延遲時間至一個合理的間隔。

• 網際網路
• 網橋