RARP協(xié)議是ARP協(xié)議相反的流程操作。那么它的具體規(guī)則我們在這里也來為大家呈現(xiàn)一下，希望能和ARP協(xié)議的流程做個對比學習，肯定會對您有所幫助的。剛才介紹的 ARP協(xié)議是透過向網(wǎng)路查詢而找出實體地址﹐那我們接下來探討的 RARP協(xié)議則相反﹕它是籍由查詢網(wǎng)路上其它主機而得到自己的 IP協(xié)議地址。

通常﹐我們使用的乙太網(wǎng)卡﹐在出廠的時候就有生產(chǎn)廠家把網(wǎng)卡的實體地址燒在 ROM 里面﹐這個地址是不能改變的(某些型號的網(wǎng)路卡﹐或是透過其它技術(shù)手段﹐是允許您修改實體地址的)。不管系統(tǒng)是否起來﹐這個地址都會存在﹐而且要讓系統(tǒng)獲得它也很容易。然而，在一些無磁碟(diskless)工作站上面﹐系統(tǒng)檔案都存放在遠端的伺服器﹐當它在啟動的時候﹐因為本身沒有 IP協(xié)議地址﹐也就無法和伺服器溝通﹐更不能將系統(tǒng)檔案載入。那么﹐我們就必須要有一個辦法﹐讓這樣的無磁碟工作站在和伺服器溝通之前獲得自己的 IP協(xié)議地址。RAPR 協(xié)定就是為解決此問題而設(shè)計出來的。

和ARP協(xié)議一樣﹐RARP也是用廣播的形式來進行查詢﹐只不過這時候問的 IP協(xié)議地址不是別人﹐而是自己的 IP協(xié)議地址而已。我們可以從下圖看出RARP協(xié)議的運作﹐其實和 ARP是極其相似的：

RARP的查詢過

RARP的查詢過程

首先是查詢主機向網(wǎng)路送出一個 RARPRequest 廣播封包﹐向別的主機查詢自己的 IP。在時候﹐網(wǎng)路上的 RARP伺服器就會將發(fā)送端的 IP協(xié)議地址用 RARPReply 封包回應給查詢者。這樣查詢主機就獲得自己的 IP協(xié)議地址了。

然而不像 ARP﹐查詢主機將 RARPRequest 封包丟出去之后﹐可能得到的 RARPReply 會不止一個 (在 ARP查詢中﹐我們可以確定只會獲得一個回應而已)。因為網(wǎng)路上可能存在不止一臺 RARP伺服器(基于備份和分擔考量﹐極有可能如此設(shè)計)﹐那么﹐所有收到 RARP請求的伺服器都會嘗試向查詢主機作出 RARPReply 回應。如果這樣的話﹐網(wǎng)路上將充斥這種 RARP回應﹐做成額外的負荷。這時候﹐我們有兩種方法來解決RARP的回應問題。

***種方法﹐為每一個做 RARP請求的主機分配一主伺服器﹐正常來說﹐只有主伺服器才回做出 RARP回應﹐其它主機只是記錄下接收到 RARP請求的時間而已。假如主伺服器不能順利作出回應﹐那么查詢主機在等待逾時再次用廣播方式發(fā)送RARP協(xié)議請求﹐其它非主伺服器假如在接到***個請求后很短時間內(nèi)再收到相同請求的話﹐才會作出回應動作。

第二種方法也很類似﹕正常來說﹐主伺服器當收到RARP協(xié)議請求之后﹐會直接作出回應﹔為避免所有非主伺服器同時傳回 RARP回應﹐每臺非主伺服器都會隨機等待一段時間再作出回應。如果主伺服器未能作出回應的話﹐查詢主機會延遲一段時間才會進行第二次請求﹐以確保這段時間內(nèi)獲得非主伺服器的回應。當然﹐設(shè)計者可以精心的設(shè)計延遲時間至一個合理的間隔。

PROXY ARP

代理 (Proxy) ARP通常用來在路由器上代為回答。