軟考網(wǎng)絡(luò)管理員備考：TCP/IP基礎(chǔ)之ARP協(xié)議

　　ARP 協(xié)定

　　這里我們要介紹的是 Address Resolution Protocol (ARP)。 ARP 是 TCP/IP 設(shè)計(jì)者利用乙太網(wǎng)的廣播性質(zhì)﹐設(shè)計(jì)出來的位址解釋協(xié)定。它的主要特性和優(yōu)點(diǎn)是它的位址對應(yīng)關(guān)系是動(dòng)態(tài)的﹐它以查詢的方式來獲得 IP 位址和實(shí)體位址的對應(yīng)。它的工作原理非常簡單﹕

　　1. 首先﹐每一臺(tái)主機(jī)都會(huì)在 ARP 快取緩沖區(qū) (ARP Cache)中建立一個(gè) ARP 表格﹐用來記錄 IP 位址和實(shí)體位址的對應(yīng)關(guān)系。這個(gè) Table 的每一筆資料會(huì)根據(jù)自身的存活時(shí)間遞減而最終消失﹐以確保資料的真實(shí)性。

　　2. 當(dāng)發(fā)送主機(jī)有一個(gè)封包要傳送給目的主機(jī)的時(shí)候﹐并且獲得目的主機(jī)的 IP 位址﹔那發(fā)送主機(jī)會(huì)先檢查自己的 ARP 表格中有沒有該 IP 位址的實(shí)體位址對應(yīng)。如果有﹐就直接使用此位址來傳送框包﹔如果沒有﹐則向網(wǎng)路發(fā)出一個(gè) ARP Request 廣播封包﹐查詢目的主機(jī)的實(shí)體位址。這個(gè)封包會(huì)包含發(fā)送端的 IP 位址和實(shí)體位址資料。

　　3. 這時(shí)﹐網(wǎng)路上所有的主機(jī)都會(huì)收到這個(gè)廣播封包﹐會(huì)檢查封包的 IP 欄位是否和自己的 IP 位址一致。如果不是則忽略﹔如果是則會(huì)先將發(fā)送端的實(shí)體位址和 IP 資料更新到自己的 ARP 表格去﹐如果已經(jīng)有該 IP 的對應(yīng)﹐則用新資料覆蓋原來的﹔然后再回應(yīng)一個(gè) ARP Reply 封包給對方﹐告知發(fā)送主機(jī)關(guān)于自己的實(shí)體位址﹔

　　4. 當(dāng)發(fā)送端接到 ARP Reply 之后﹐也會(huì)更新自己的 ARP 表格﹔然后就可以用此紀(jì)錄進(jìn)行傳送了。

　　5. 如果發(fā)送端沒有得到 ARP Reply ﹐則宣告查詢失敗。

　　前面說的 ARP 表格﹐只有在 TCP/IP 協(xié)定被載入核心之后才會(huì)建立﹐如果 TCP/IP 協(xié)定被卸載或關(guān)閉機(jī)器﹐那么表格就會(huì)被清空﹔到下次協(xié)定載入或開機(jī)的時(shí)候再重新建立﹐而同時(shí)會(huì)向網(wǎng)路發(fā)出一個(gè) ARP 廣播﹐告訴其它機(jī)器它的目前位址是什么﹐以便所有機(jī)器都能保持最正確的資料。

　　然而﹐ARP cache 的大小是有所限制的﹐如果超過了界限﹐那么越長時(shí)間沒被使用過渡資料就必須清理掉﹐以騰出空間來儲(chǔ)存更新的資料。所以﹐當(dāng)機(jī)器收到 ARP equest 封包時(shí)﹐如果查詢對象不是自己﹐則不會(huì)根據(jù)發(fā)送端位址資料來更新自己的 ARP 表格﹐而是完全忽略該封包。同時(shí)﹐每筆存在 cache 中的資料﹐都不是永久保存的﹕每筆資料再更新的時(shí)候﹐都會(huì)被賦予一個(gè)存活倒數(shù)計(jì)時(shí)值﹐如果在倒數(shù)時(shí)間到達(dá)的時(shí)候﹐該資料就會(huì)被清掉。然而﹐如果該資料在倒數(shù)時(shí)間到達(dá)之前被使用過﹐則計(jì)時(shí)值會(huì)被重新賦予。

　　當(dāng)然了﹐ARP 尚有一套機(jī)制來處理當(dāng) ARP 表格資料不符合實(shí)際位址資料的狀況(例如﹐在當(dāng)前連線尚未結(jié)束前﹐收到目的端的位址資料更新訊息)﹔或是目的主機(jī)太忙碌而未能回答 ARP 請求等狀況。

　　RARP 協(xié)定

　　剛才介紹的 ARP 協(xié)定是透過向網(wǎng)路查詢而找出實(shí)體位址﹐那我們接下來探討的 RARP 協(xié)定則相反﹕它是籍由查詢網(wǎng)路上其它主機(jī)而得到自己的 IP 位址。

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

　　和 ARP 協(xié)定一樣﹐RARP 也是用廣播的形式來進(jìn)行查詢﹐只不過這時(shí)候問的 IP 位址不是別人﹐而是自己的 IP 位址而已。

　　首先是查詢主機(jī)向網(wǎng)路送出一個(gè) RARP Request 廣播封包﹐向別的主機(jī)查詢自己的 IP。在時(shí)候﹐網(wǎng)路上的 RARP 伺服器就會(huì)將發(fā)送端的 IP 位址用 RARP Reply 封包回應(yīng)給查詢者。這樣查詢主機(jī)就獲得自己的 IP 位址了。

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

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

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