《TCP/IP詳解卷1：協議》第4章 ARP:地址解析協議

時間 2019-11-13

原文原文鏈接

4.1 引言

本章咱們要討論的問題是隻對TCP/IP協議簇有意義的IP地址。數據鏈路如以太網或令牌環網都有本身的尋址機制（經常爲48 bit地址），這是使用數據鏈路的任何網絡層都必須聽從的。一個網絡如以太網能夠同時被不一樣的網絡層使用。例如，一組使用TCP/IP協議的主機和另外一組使用某種PC網絡軟件的主機能夠共享相同的電纜。html

當一臺主機把以太網數據幀發送到位於同一局域網上的另外一臺主機時，是根據48 bit的以太網地址來肯定目的接口的。設備驅動程序從不檢查IP數據報中的目的IP地址。web

地址解析爲這兩種不一樣的地址形式提供映射：32 bit的IP32位Internet地址地址和數據鏈路層使用的任何類型的地址。RFC 826[Plummer 1982]是ARP規範描述文檔。算法

本章及下一章咱們要討論的兩種協議如圖4-1所示：ARP（地址解析協議）和RARP（逆地址解析協議）。緩存

圖4-1 地址解析協議:ARP和RARP服務器

ARP爲IP地址到對應的硬件地址之間提供動態映射。咱們之因此用動態這個詞是由於這個過程是自動完成的，通常應用程序用戶或系統管理員沒必要關心。網絡

RARP是被那些沒有磁盤驅動器的系統使用（通常是無盤工做站或X終端），它須要系統管理員進行手工設置。咱們在第5章對它進行討論。tcp

4.2一個例子

任什麼時候候咱們敲入下面這個形式的命令：ide

% ftp bsdi函數

都會進行如下這些步驟。這些步驟的序號如圖4-2所示。性能

應用程序FTP客戶端調用函數gethostbyname(3)把主機名（bsdi）轉換成32 bit的IP地址。這個函數在DNS（域名系統）中稱做解析器，咱們將在第14章對它進行介紹。這個轉換過程或者使用DNS，或者在較小網絡中使用一個靜態的主機文件（/etc/hosts）。
FTP客戶端請求TCP用獲得的IP地址創建鏈接。
TCP發送一個鏈接請求分段到遠端的主機，即用上述IP地址發送一份IP數據報（在第18章咱們將討論完成這個過程的細節）。
若是目的主機在本地網絡上（如以太網、令牌環網或點對點連接的另外一端），那麼IP數據報能夠直接送到目的主機上。若是目的主機在一個遠程網絡上，那麼就經過IP選路函數來肯定位於本地網絡上的下一站路由器地址，並讓它轉發IP數據報。在這兩種狀況下，IP數據報都是被送到位於本地網絡上的一臺主機或路由器。
假定是一個以太網，那麼發送端主機必須把32 bit的IP地址變換成48 bit的以太網地址。從邏輯Internet地址到對應的物理硬件地址須要進行翻譯。這就是ARP的功能。ARP原本是用於廣播網絡的，有許多主機或路由器連在同一個網絡上。
ARP發送一份稱做ARP請求的以太網數據幀給以太網上的每一個主機。這個過程稱做廣播，如圖4-2中的虛線所示。ARP請求數據幀中包含目的主機的IP地址（主機名爲bsdi），其意思是「若是你是這個IP地址的擁有者，請回答你的硬件地址。」
目的主機的ARP層收到這份廣播報文後，識別出這是發送端在尋問它的IP地址，因而發送一個ARP應答。這個ARP應答包含IP地址及對應的硬件地址。
收到ARP應答後，使ARP進行請求—應答交換的IP數據報如今就能夠傳送了。
發送IP數據報到目的主機。

第4章 ARP:地址解析協議39

圖4-2 當用戶輸入命令「ftp主機名」時ARP的操做

在ARP背後有一個基本概念，那就是網絡接口有一個硬件地址（一個48 bit的值，標識不一樣的以太網或令牌環網絡接口）。在硬件層次上進行的數據幀交換必須有正確的接口地址。可是，TCP/IP有本身的地址：32 bit的IP地址。知道主機的IP地址並不能讓內核發送一幀數據給主機。內核（如以太網驅動程序）必須知道目的端的硬件地址才能發送數據。ARP的功能是在32 bit的IP地址和採用不一樣網絡技術的硬件地址之間提供動態映射。

點對點鏈路不使用ARP。當設置這些鏈路時（通常在引導過程進行），必須告知內核鏈路每一端的IP地址。像以太網地址這樣的硬件地址並不涉及。

40TCP/IP詳解，卷1：協議

圖4-3 用於以太網的ARP請求或應答分組格式

以太網報頭中的前兩個字段是以太網的源地址和目的地址。目的地址爲全1的特殊地址是廣播地址。電纜上的全部以太網接口都要接收廣播的數據幀。

兩個字節長的以太網幀類型表示後面數據的類型。對於ARP請求或應答來講，該字段的值爲0x0806。

形容詞hardware(硬件)和protocol(協議)用來描述ARP分組中的各個字段。例如，一個ARP請求分組詢問協議地址（這裏是IP地址）對應的硬件地址（這裏是以太網地址）。

硬件類型字段表示硬件地址的類型。它的值爲1即表示以太網地址。協議類型字段表示要映射的協議地址類型。它的值爲0x0800即表示IP地址。它的值與包含IP數據報的以太網數據幀中的類型字段的值相同，這是有意設計的（參見圖2-1）。

接下來的兩個1字節的字段，硬件地址長度和協議地址長度分別指出硬件地址和協議地址的長度，以字節爲單位。對於以太網上IP地址的ARP請求或應答來講，它們的值分別爲6和4。

操做字段指出四種操做類型，它們是ARP請求（值爲1）、ARP應答（值爲2）、RARP請求（值爲3）和RARP應答（值爲4）（咱們在第5章討論RARP）。這個字段必需的，由於ARP請求和ARP應答的幀類型字段值是相同的。

接下來的四個字段是發送端的硬件地址（在本例中是以太網地址）、發送端的協議地址（IP地址）、目的端的硬件地址和目的端的協議地址。注意，這裏有一些重複信息：在以太網的數據幀報頭中和ARP請求數據幀中都有發送端的硬件地址。

第4章 ARP:地址解析協議41

當咱們在另外一個系統（sun）上運行帶有-e選項的tcpdump命令時，顯示的是硬件地址（在咱們的例子中是48 bit的以太網地址）。

圖4-4中的tcpdump的原始輸出如附錄A中的圖A-3所示。因爲這是本書第一個tcpdump輸出例子，你應該去查看附錄中的原始輸出，看看咱們做了哪些修改。

圖4-4 TCP鏈接請求產生的ARP請求和應答

咱們刪除了tcpdump命令輸出的最後四行，由於它們是結束鏈接的信息（咱們將在第18章進行討論），與這裏討論的內容不相關。

在第1行中，源端主機（bsdi）的硬件地址是0:0:c0:6f:2d:40。目的端主機的硬件地址是ff:ff:ff:ff:ff:ff，這是一個以太網廣播地址。電纜上的每一個以太網接口都要接收這個數據幀並對它進行處理，如圖4-2所示。

第1行中緊接着的一個輸出字段是arp，代表幀類型字段的值是0x0806，說明此數據幀是一個ARP請求或回答。

在每行中，單詞arp或ip後面的值60指的是以太網數據幀的長度。因爲ARP請求或回答的數據幀長都是42字節（28字節的ARP數據，14字節的以太網幀頭），所以，每一幀都必須加入填充字符以達到以太網的最小長度要求：60字節。

42TCP/IP詳解，卷1：協議

tcpdump命令的輸出如圖4-5所示。

第4章 ARP:地址解析協議43

圖4-5 對不存在主機的ARP請求

這一次，咱們沒有用-e選項，由於已經知道ARP請求是在網上廣播的。

使人感興趣的是看到屢次進行ARP請求：第1次請求發生後5.5秒進行第2次請求，在24秒以後又進行第3次請求（在第21章咱們將看到TCP的超時和重發算法的細節）。tcpdump命令輸出的超時限制爲29.5秒。可是，在telnet命令使用先後分別用date命令檢查時間，能夠發現Te lnet客戶端的鏈接請求彷佛在大約75秒後才放棄。事實上，咱們在後面將看到，大多數的BSD實現把完成TCP鏈接請求的時間限制設置爲75秒。

在第18章中，當咱們看到創建鏈接的TCP報文段序列時，會發現ARP請求對應於TCP試圖發送的初始TCPSYN（同步）段。

注意，在線路上始終看不到TCP的報文段。咱們能看到的是ARP請求。直到ARP回答返回時，TCP報文段才能夠被髮送，由於硬件地址到這時纔可能知道。若是咱們用過濾模式運行tcpdump命令，只查看TCP數據，那麼將沒有任何輸出。

4.5.3 ARP高速緩存超時設置

在ARP高速緩存中的表項通常都要設置超時值（在4.8小節中，咱們將看到管理員能夠用arp命令把地址放入高速緩存中而不設置超時值）。從伯克利系統演變而來的系統通常對完整的表項設置超時值爲20分鐘，而對不完整的表項設置超時值爲3分鐘（在前面的例子中咱們已見過一個不完整的表項，即在以太網上對一個不存在的主機發出ARP請求。）當這些表項再次使用時，這些實現通常都把超時值從新設爲20分鐘。

Host Requirements RFC代表即便表項正在使用時，超時值也應該啓動，可是大多數從伯克利系統演變而來的系統沒有這樣作—它們每次都是在訪問表項時重設超時值。

4.6 ARP代理

若是ARP請求是從一個網絡的主機發往另外一個網絡上的主機，那麼鏈接這兩個網絡的路由器就能夠回答該請求，這個過程稱做委託ARP或ARP代理(Proxy ARP)。這樣能夠欺騙發起ARP請求的發送端，使它誤覺得路由器就是目的主機，而事實上目的主機是在路由器的「另外一邊」。路由器的功能至關於目的主機的代理，把分組從其餘主機轉發給它。

舉例是說明ARP代理的最好方法。如圖3-10所示，系統sun與兩個以太網相連。可是，咱們也指出過，事實上並非這樣，請把它與封內圖1進行比較。在sun和子網140.252.1之間實際存在一個路由器，就是這個具備ARP代理功能的路由器使得sun就好像在子網140.252.1上同樣。具體安置如圖4-6所示，路由器Telebit NetBlazer，取名爲netb，在子網和主機sun之間。

當子網140.252.1（稱做gemini）上的其餘主機有一份IP數據報要傳給地址爲140.252.1.29的sun時，gemini比較網絡號（140.252）和子網號（1），由於它們都是相同的，於是在圖4-6上面的以太網中發送IP地址140.252.1.29的ARP請求。路由器netb識別出該IP地址屬於它的一個拔號主機，因而把它的以太網接口地址140.252.1做爲硬件地址來回答。主機gemini經過以太網發送IP數據報到netb，netb經過撥號SLIP鏈路把數據報轉發到sun。這個過程對於全部140.252.1子網上的主機來講都是透明的，主機sun其實是在路由器netb後面進行配置的。

44TCP/IP詳解，卷1：協議

圖4-6 ARP代理的例子

若是在主機gemini上執行arp命令，通過與主機sun通訊之後，咱們發如今同一個子網140.252.1上的netb和sun的IP地址映射的硬件地址是相同的。這一般是使用委託ARP的線索。

圖4-6中的另外一個須要解釋的細節是在路由器netb的下方（SLIP鏈路）顯然缺乏一個IP地址。爲何在撥號SLIP鏈路的兩端只擁有一個IP地址，而在bsdi和slip之間的兩端卻分別有一個IP地址？在3.8小節咱們已經指出，用ifconfig命令能夠顯示撥號SLIP鏈路的目的地址，它是140.252.1.183。NetBlazer不須要知道撥號SLIP鏈路每一端的IP地址（這樣作會用更多的IP地址）。相反，它經過分組到達的串行線路接口來肯定發送分組的撥號主機，所以對於鏈接到路由器的每一個撥號主機不須要用惟一的IP地址。全部的撥號主機使用同一個IP地址140.252.1.183做爲SLIP鏈路的目的地址。

ARP代理能夠把數據報傳送到路由器sun上，可是子網140.252.13上的其餘主機是如何處理的呢？選路必須使數據報能到達其餘主機。這裏須要特殊處理，選路表中的表項必須在網絡140.252的某個地方制定，使全部數據報的目的端要麼是子網140.252.13，要麼是子網上的某個主機，這樣都指向路由器netb。而路由器netb知道如何把數據報傳到最終的目的端，即經過路由器sun。

ARP代理也稱做混合ARP（promiscuousARP）或ARP出租(ARP hack)。這些名字來自於ARP代理的其餘用途：經過兩個物理網絡之間的路由器能夠互相隱藏物理網絡。在這種狀況下，兩個物理網絡可使用相同的網絡號，只要把中間的路由器設置成一個ARP代理，以響應一個網絡到另外一個網絡主機的ARP請求。這種技術在過去用來隱藏一組在不一樣物理電纜上運行舊版TCP/IP的主機。分開這些舊主機有兩個共同的理由，其一是它們不能處理子網劃分，其二是它們使用舊的廣播地址（全部比特值爲0的主機號，而不是目前使用的全部比特值爲1 的主機號）。

第4章 ARP:地址解析協議45

圖4-7 免費ARP的例子

（咱們用-n選項運行tcpdump命令，打印出點分十進制的地址，而不是主機名）。對於ARP請求中的各字段來講，發送端的協議地址和目的端的協議地址是一致的：即主機bsdi的地址140.252.13.35。另外，以太網報頭中的源地址0:0:c0:6f:2d:40，正如tcpdump命令顯示的那樣，等於發送端的硬件地址（見圖4-4）。

免費ARP能夠有兩個方面的做用：

一個主機能夠經過它來肯定另外一個主機是否設置了相同的IP地址。主機bsdi並不但願對此請求有一個回答。可是，若是收到一個回答，那麼就會在終端日誌上產生一個錯誤消息「以太網地址：a:b:c:d:e:f發送來重複的IP地址」。這樣就能夠警告系統管理員，某個系統有不正確的設置。
若是發送免費ARP的主機正好改變了硬件地址（極可能是主機關機了，並換了一塊接口卡，而後從新啓動），那麼這個分組就可使其餘主機高速緩存中舊的硬件地址進行相應的更新。一個比較著名的ARP協議事實[Plummer 1982]是，若是主機收到某個IP地址的ARP請求，並且它已經在接收者的高速緩存中，那麼就要用ARP請求中的發送端硬件地址（如以太網地址）對高速緩存中相應的內容進行更新。主機接收到任何ARP請求都要完成這個操做（ARP請求是在網上廣播的，所以每次發送ARP請求時網絡上的全部主機都要這樣作）。

文獻[Bhide、Elnozahy和Morgan 1991]中有一個應用例子，經過發送含有備份硬件地址和故障服務器的IP地址的免費ARP請求，使得備份文件服務器能夠順利地接替故障服務器進行工做。這使得全部目的地爲故障服務器的報文都被送到備份服務器那裏，客戶程序不用關心原來的服務器是否出了故障。

不幸的是，做者卻反對這個作法，由於這取決於全部不一樣類型的客戶端都要有正確的ARP協議實現。他們顯然碰到過客戶端的ARP協議實現與規範不一致的狀況。經過檢查做者所在子網上的全部系統能夠發現，SunOS 4.1.3和4.4 BSD在引導時都發送免費ARP，可是SVR4卻沒有這樣作。

4.8 arp命令

咱們已經用過這個命令及參數-a來顯示ARP高速緩存中的全部內容。這裏介紹其餘參數的功能。

超級用戶能夠用選項-d來刪除ARP高速緩存中的某一項內容（這個命令格式能夠在運行一些例子以前使用，以讓咱們看清楚ARP的交換過程）。

46TCP/IP詳解，卷1：協議

另外，能夠經過選項-s來增長高速緩存中的內容。這個參數須要主機名和以太網地址：對應於主機名的IP地址和以太網地址被增長到高速緩存中。新增長的內容是永久性的（好比，它沒有超時值），除非在命令行的末尾附上關鍵字temp。

位於命令行末尾的關鍵字pub和-s選項一塊兒，可使系統起着主機ARP代理的做用。系統將回答與主機名對應的IP地址的ARP請求，並以指定的以太網地址做爲應答。若是廣播的地址是系統自己，那麼系統就爲指定的主機名起着委託ARP代理的做用。

4.9 小結

在大多數的TCP/IP實現中，ARP是一個基礎協議，可是它的運行對於應用程序或系統管理員來講通常是透明的。ARP高速緩存在它的運行過程當中很是關鍵，咱們能夠用arp命令對高速緩存進行檢查和操做。高速緩存中的每一項內容都有一個定時器，根據它來刪除不完整和完整的表項。arp命令能夠顯示和修改ARP高速緩存中的內容。

咱們介紹了ARP的通常操做，同時也介紹了一些特殊的功能：委託ARP（當路由器對來自於另外一個路由器接口的ARP請求進行應答時）和免費ARP（發送本身IP地址的ARP請求，通常發生在引導過程當中）。

習題

當輸入命令以生成相似圖4-4那樣的輸出時，發現本地ARP快速緩存爲空之後，輸入命令bsdi % rsh svr4 arp -a若是發現目的主機上的ARP快速緩存也是空的，那將發生什麼狀況？(該命令將在svr4主機上運行arp -a命令）。
請描述如何判斷一個給定主機是否能正確處理接收到的非必要的ARP請求的方法。
因爲發送一個數據包後ARP將等待響應，所以4.2節所描述的步驟7可能會持續一段時間。你認爲ARP將如何處理在這期間收到相同目的IP地址發來的多個數據包？
在4.5節的最後，咱們指出Host Requirements RFC和伯克利派生系統在處理活動ARP表目的超時時存在差別。那麼若是咱們在一個由伯克利派生系統的客戶端上，試圖與一個正在更換以太網卡而處於關機狀態的服務器主機聯繫，這時會發生什麼狀況？若是服務器在引導過程當中廣播一份免費ARP，這種狀況是否會發生變化？

文章同步發佈： https://www.geek-share.com/detail/2752945344.html

《TCP/IP詳解卷1：協議》在線整理版目錄導航