地址解析協議
![本頁使用了標題或全文手工轉換](http://images.weserv.nl/?url=//upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Zh_conversion_icon_m.svg/35px-Zh_conversion_icon_m.svg.png)
![]() |
地址解析協議(英語:Address Resolution Protocol,縮寫:ARP)是一個通過解析網絡層地址來找尋數據鏈路層地址的網絡傳輸協議,它在IPv4中極其重要。ARP最初在1982年的RFC 826(徵求意見稿)[1]中提出並納入互聯網標準STD 37。ARP也可能指是在多數操作系統中管理其相關地址的一個進程。
ARP是通過網路位址來定位MAC地址。 ARP已經在很多網路層和數據鏈接層之間得以實現,包括IPv4、Chaosnet、DECnet和Xerox PARC Universal Packet(PUP)使用IEEE 802標準, 光纖分布式數據接口, X.25,幀中繼和異步傳輸模式(ATM),IEEE 802.3和IEEE 802.11標準上IPv4占了多數流量。
在IPv6中鄰居發現協議(NDP)用於代替地址解析協議(ARP)。
基本功能
在TCP/IP協議中,傳輸層只關心目標主機的IP地址和端口,因為它們唯一確定一個傳輸層的包要交互的目的地,即目標主機上的目標應用程序。網絡層會對傳輸層的包進行封裝,形成IP包。網絡層只關心目標機器的IP地址,並根據這個IP地址尋址到網絡上的目標機器。在以太網中,IP數據包又被封裝在以太網幀中,經過物理層(也就是網卡)發送到網絡上,以太網幀又是根據MAC地址來尋址到目的機器的網卡的。局域網中的所有機器的網卡都會接收到這個幀,而只有該幀頭部中的目的MAC地址與自己網卡的MAC地址匹配時,才會向網絡協議棧交付該幀中的數據包,否則網卡就會丟棄該幀。因此,當同一局域網中的一台主機要和另一台主機或者交換機,路由器等進行網絡通信時,必須要知道與本機用網線連接上的,目標設備那邊的那個網絡接口的MAC地址(也就是網卡的地址)。這就導致在以太網中使用IP協議向下傳遞IP包時,IP包被包含在以太網幀中。以太網幀是有自己的格式的,在幀頭部就需要填充目的機器MAC地址,而此時從ARP表裡面沒有查詢到目的IP地址對應的MAC地址,因此主機會暫存這個IP數據包,由於主機剛連接到這個局域網時或者重啟之後,是不知道目的方的MAC地址的,如果要向目的機器發送一個IP包,就需要先知道目的機器的MAC地址,於是需要一種方法,根據目的主機的IP地址,獲得其MAC地址,這個方法就是通過發送一個叫做ARP請求的數據包。ARP數據包也是被包含在以太網幀中的,發送時,幀頭部中的目的MAC地址填寫為廣播地址FF:FF:FF:FF:FF:FF,這樣屬於該局域網的所有機器接收到一個廣播幀的時候都會向協議棧遞交這個幀中的數據包:這裡是ARP數據包,廣播到該局域網中。而僅當某台機器的IP地址與該ARP請求中的要詢問的IP地址相同時,那台機器就才會返回一個ARP回應數據包。這個回應包中就包含了先前要詢問的機器的IP地址和MAC地址,本地主機接收到這個回應的ARP數據包後,會提取IP地址和MAC地址,記錄到一個叫做ARP的表的表項中,這樣就把目的主機的IP地址和MAC地址對應關係記錄下來了,隨即找到先前由於缺少目的MAC地址而暫存的數據包,並用以太網幀封裝它,用該ARP表項中的MAC地址來填充幀頭部中的MAC地址域,當這個幀被發送到局域網中之後,目標機器網卡接收到這個幀之後,判斷該MAC地址和自己的MAC地址相同,就會向上層協議棧遞交這個幀中的數據包,從而數據得以交付,而其他主機檢測到MAC地址與本機不同,會把這個幀丟棄。這就是ARP協議要做的事情。
另外,當發送主機和目的主機不在同一個局域網中時,即便知道對方的MAC地址,兩者也不能直接通信,必須經過路由器進行IP層的轉發才可以,因為路由器把這個局域網進行了鏈路層上的隔離(除非進行網絡層次的顯示轉發,否則路由器不會把一個局域網中的以太網幀自動的轉發到另一個局域網或者外網中去,如果可以自動轉發,可以想象有多可怕,無效的廣播幀可能像洪水一樣淹沒整個網絡,使得網絡癱瘓,這也就是路由器的基本功能之一,隔離網絡),所以此時,發送主機會把一個網關IP地址作為目的IP地址(這個是IP層決定的),那麼通過ARP協議獲得的將不是目的主機的真實MAC地址,而是一台可以通往局域網外的路由器的MAC地址。於是此後發送主機發往目的主機的所有幀,都將發往該路由器,通過它向外發送。這種情況稱為委託ARP或ARP代理(ARP Proxy)。
在點對點鏈路中不使用ARP,實際上在點對點網絡中也不使用MAC地址,因為在此類網絡中分別已經獲取了對端的IP地址。
數據包結構
地址解析協議的消息格式很簡單,僅包含單一的地址解析請求或響應。ARP 消息的長度取決於上下兩層地址的大小,上層地址由所使用的網絡協議類型(通常是 IPv4)決定,下層地址則由上層協議所使用的硬件或虛擬鏈路層的類型決定。消息的報頭中包含了這些類型以及對應的地址長度信息,此外還包含了表示請求(1)和應答(2)的操作碼。數據包的有效負載為收發雙方的硬件地址、協議地址,總計四個地址。
為了把IP地址映射到48位以太網地址用於傳輸,需要一個體現地址轉換協議的包格式。
以太網幀
- 目標以太網地址:目標MAC地址。FF:FF:FF:FF:FF:FF (二進制全1)為廣播地址。
- 源以太網地址:發送方MAC地址。
- 幀類型:以太類型,ARP為0x0806。
ARP報文
- 硬件類型(HTYPE):如以太網(0x0001)、分組無線網。
- 協議類型(PTYPE):如網際協議(IP)(0x0800)、IPv6(0x86DD)。
- 硬件地址長度(HLEN):每種硬件地址的字節長度,一般為6(以太網)。
- 協議地址長度(PLEN):每種協議地址的字節長度,一般為4(IPv4)。
- 操作碼:1為ARP請求,2為ARP應答,3為RARP請求,4為RARP應答。
- 源硬件地址(Sender Hardware Address,簡稱SHA):n個字節,n由硬件地址長度得到,一般為發送方MAC地址。
- 源協議地址(Sender Protocol Address,簡稱SPA):m個字節,m由協議地址長度得到,一般為發送方IP地址。
- 目標硬件地址(Target Hardware Address,簡稱THA):n個字節,n由硬件地址長度得到,一般為目標MAC地址。
- 目標協議地址(Target Protocol Address,簡稱TPA):m個字節,m由協議地址長度得到,一般為目標IP地址。
ARP協議的參數由互聯網號碼分配局(Internet Assigned Numbers Authority, 簡稱IANA)負責標準化和維護。
ARP協議的以太類型為0x0806。該類型出現於以太網幀格式中的以太類型字段。請注意區別此類型和ARP協議類型(PTYPE)。
報文格式
長度(位) | 48 | 48 | 16 | 16 | 16 | 8 | 8 | 16 | 48 | 32 | 48 | 32 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
數據類型 | 目標以太網地址 | 源以太網地址 | 幀類型 | 硬件類型 | 協議類型 | 硬件地址長度 | 協議地址長度 | 操作碼 | 源硬件地址 | 源協議地址 | 目標硬件地址 | 目標協議地址 |
組成 | 14字節 以太網首部 | 28字節 ARP請求/應答 |
原理
![](http://images.weserv.nl/?url=//upload.wikimedia.org/wikipedia/commons/thumb/c/ce/Windows_cmd_arp_a.png/320px-Windows_cmd_arp_a.png)
在每台安裝有TCP/IP協議的電腦或路由器裡都有一個ARP緩存表,表里的IP地址與MAC地址是一一對應的,如下表所示。
主機名稱 | IP地址 | MAC地址 |
---|---|---|
A | 192.168.38.10 | 00-AA-00-62-D2-02 |
B | 192.168.38.11 | 00-BB-00-62-C2-02 |
C | 192.168.38.12 | 00-CC-00-62-C2-02 |
D | 192.168.38.13 | 00-DD-00-62-C2-02 |
E | 192.168.38.14 | 00-EE-00-62-C2-02 |
... | ... | ... |
以主機A(192.168.38.10)向主機B(192.168.38.11)發送數據為例。
- 當發送數據時,主機A會在自己的ARP緩存表中尋找是否有目標IP地址。如果找到就知道目標MAC地址為(00-BB-00-62-C2-02),直接把目標MAC地址寫入幀裡面發送就可。
- 如果在ARP緩存表中沒有找到相對應的IP地址,主機A就會在網絡上發送一個廣播(ARP request),目標MAC地址是「FF.FF.FF.FF.FF.FF」,這表示向同一網段內的所有主機發出這樣的詢問:「192.168.38.11的MAC地址是什麼?」
- 網絡上其他主機並不響應ARP詢問,只有主機B接收到這個幀時,才向主機A做出這樣的回應(ARP response):「192.168.38.11的MAC地址是00-BB-00-62-C2-02」,此回應以單播方式進行。這樣,主機A就知道主機B的MAC地址,它就可以向主機B發送信息。同時它還更新自己的ARP高速緩存(ARP cache),下次再向主機B發送信息時,直接從ARP緩存表里查找就可。
ARP緩存表採用老化機制,在一段時間內如果表中的某一行沒有使用,就會被刪除,這樣可減少緩存表的長度,加快查詢速度。
無回報的ARP(gratuitous ARP),它是指主機發送ARP查詢(廣播)自己的IP地址,當ARP功能被開啟或者是端口初始配置完成,主機向網絡發送無回報的ARP來查詢自己的IP地址確認地址唯一可用。作用:
- 確定網絡中是否有其他主機使用了IP地址,如果有應答則產生錯誤消息。
- 無回報的ARP可以做更新ARP緩存用,網絡中的其他主機收到該廣播則在緩存中更新條目,收到該廣播的主機無論是否存在與IP地址相關的條目都會強制更新,如果存在舊條目則會將MAC更新為廣播包中的MAC。
協議的分層
ARP協議在互聯網協議套件和OSI模型的位置可能會造成混亂和爭議。在 RFC 1122 僅僅在數據鏈路層提及ARP協議當並未說明將此協議置於該層[2]。一些較舊的文檔將ARP置於OSI的數據鏈路層[3],但是一些新的版本卻將其與網絡層聯繫起來。[4]
參考資料
- ^ David C. Plummer. RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. Internet Engineering Task Force, Network Working Group. November 1982 [2017-09-14]. (原始內容存檔於2017-09-19).
- ^ RFC 1122
- ^ W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison Wesley, 1994, ISBN 0-201-63346-9.
- ^ W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison Wesley, 2011, ISBN 0-321-33631-3, page 14