IP地址是不能直接用來進行通信的。這是因為IP地址只是主機在抽象的網絡層中的地址。若要將網絡層中傳送的數據報交給目的主機,還要傳到鏈路層轉變成MAC幀后才能發送到實際的網絡上。因此,不管網絡層使用的是什么協議,在實際網絡的鏈路上傳送數據幀時,最終還是必須使用硬件地址。
由於IP地址有32 bit,而局域網的硬件地址是48bit,因此它們之間不存在簡單的映射關系。此外,在一個網絡上可能經常會有新的主機加入進來,或撤走一些主機。更換網卡也會使主機的硬件地址改變。可見在主機中應存放一個從IP地址到硬件地址的映射表,並且這個映射表還必須能夠經常動態更新。地址解析協議ARP很好地解決了這些問題。
每一個主機都設有一個ARP高速緩存(ARP cache),里面有所在的局域網上的各主機和路由器的IP地址到硬件地址的映射表,這些都是該主機目前知道的一些地址。
如果不使用ARP高速緩存,那么任何一個主機只要進行一次通信,就必須在網絡上用廣播方式發送ARP請求分組,這就使網絡上的通信量大大增加。ARP將已經得到的地址映射保存在高速緩存中,這樣就使得該主機下次再和具有同樣目的地址的主機通信時,可以直接從高速緩存中找到所需的硬件地址而不必再用廣播方式發送ARP請求分組。(詳解過程請參考第2頁)
ARP將保存在高速緩存中的每一個映射地址項目都設置生存時間(例如,10~20分鍾)。凡超過生存時間的項目就從高速緩存中刪除掉。設置這種地址映射項目的生存時間是很重要的。設想有一種情況。主機A和B通信。A的ARP高速緩存里保存有B的物理地址。但B的網卡突然壞了,B立即更換了一塊,因此B的硬件地址就改變了。A還要和B繼續通信。A在其ARP高速緩存中查找到B原先的硬件地址,並使用該地址向B發送數據幀。但B原先的硬件地址已經失效了,因此A無法找到主機B。但是過了一段時間,A的ARP高速緩存中已經刪除了B原先的硬件地址(因為它的存在時間到了),於是A重新廣播發送ARP請求分組,又找到了B。
這里需要指出,ARP是解決同一個局域網上的主機或路由器的IP地址和硬件地址的映射問題。如果所要找的主機和源主機不在同一個局域網上,例如,在TCP/IP詳解卷1中,第29頁的例子,那么這時就要借助於網絡層的協議,配合鏈路層協議才能將數據報成功的發送到目的主機上。(詳解過程請參考第3頁)
這里要指出的是,這種從IP地址到硬件地址的解析是自動進行的,主機的用戶對這種地址解析過程是不知道的。只要主機或路由器要和本網絡上的另一個已知IP地址的主機或路由器進行通信,ARP協議就會自動地將該IP地址解析為鏈路層所需要的硬件地址。
那么就可能會產生這樣的問題:既然在網絡鏈路上傳送的幀最終是按照硬件地址找到目的主機的,那么為什么我們不直接使用硬件地址進行通信,而是要使用抽象的IP地址並調用ARP來尋找出相應的硬件地址呢?
這個問題必須弄清楚。
由於全世界存在着各式各樣的網絡,它們使用不同的硬件地址。要使這些異構網絡能夠互相通信就必須進行非常復雜的硬件地址轉換工作,因此幾乎是不可能的事。但統一的IP地址把這個復雜問題解決了。連接到因特網的主機都擁有統一的IP地址,它們之間的通信就像連接在同一個網絡上那樣簡單方便,因為調用ARP來尋找某個路由器或主機的硬件地址都是由計算機軟件自動進行的,對用戶來說是看不見這種調用過程的。
設想有兩個主機可以直接使用硬件地址進行通信(具體實現方法暫不必管)。再假定其兩個主機的網卡都同時壞了,然后又都更換了一塊,因此它們的硬件地址也都改變了。這時,這兩個主機怎樣能夠知道對方的硬件地址呢?顯然很難。但IP地址是獨立於主機或路由器的硬件地址的。硬件地址的改變不會影響使用IP協議的主機的通信。
因此,在虛擬的IP網絡上用IP地址進行通信給廣大的計算機用戶帶來很大的方便
轉自http://blog.sina.com.cn/s/blog_4031f99e010008l7.html
