IP旨在讓最終目標主機收到數據包,可是在這一過程當中僅僅有IP是沒法實現通訊的。必須還要有可以解析主機名稱和MAC地址功能,以及技術包在發送過程當中異常狀況處理的功能。
這篇主要介紹下DNS、ARP、ICMP、DHCP等協議數據庫
TCP/IP網絡中要求每個互連的計算機都具備其惟一的IP地址,並基於這個IP地址進行通訊。可是IP地址太長了,很差記。緩存
人們但願主機有本身本身的名字,這個名字是惟一的,並且容易記住。因而,誕生了主機名「域名」的概念。域名是一種爲了識別主機名稱和機構名的具備分層的名稱,好比在域名 neu.edu.cn中,neu是主機名,edu 和 cn 是不一樣層次下的機構名。服務器
爲了實現這樣的功能,主機每每會利用一個叫作hosts的數據庫文件網絡
可是隨着網絡規模的不斷擴大,接入計算機的個數不斷增長,這種集中在本地電腦管理的方式就不可取了。架構
因而出現了DNS,當咱們輸入主機名(域名)時,DNS會先在互聯網上先自動檢索那個註冊了主機名和IP地址的數據庫,並迅速定位到對應的IP地址。分佈式
域名和 IP 地址均可以惟一對應一臺主機,DNS 協議的做用就是將自身具備意義的域名轉換成不容易記住的 IP 地址。性能
域名是分層的,每層都有本身的 DNS 服務器用於處理 DNS 解析的請求。這樣的好處在於每層的服務器不用關注過多的信息,它只要知道本身這一層下的域名服務器信息便可。以解析域名: www.abc.com爲例:翻譯
根服務器其實並不知道 www.abc.com 的 IP 地址,可是它知道 abc.com 域名服務器的地址,因此它把這條查詢請求轉發給 abc.com 域名服務器。DNS請求被逐層下發,直到找到對應的 IP 地址爲止。
解析器和域名服務器將最新瞭解到的信息暫時保存在緩存中醬紫能夠減小每次查詢時的性能消耗。3d
DNS就如同互聯網中的分佈式數據庫代理
只要肯定了IP地址,就能夠向這個目標地址發送IP數據報。然而在底層數據鏈路層,進行實際通訊時,卻須要知道每一個IP地址所對應的MAC地址
ARP 協議(Address Resolution Protocol)用於經過目標 IP 地址,定位下一個接收數據包的網絡設備的 MAC 地址。若是目標主機處在同一個數據鏈路上,那麼能夠直接獲得目標主機的 MAC 地址,不然會獲得下一條路由器的 MAC 地址。
ARP 協議的工做原理能夠分爲兩部分:ARP 請求和 ARP 響應。 首先,源主機會經過廣播發送一個 ARP 請求包:「我要與 IP 地址爲 xxx 的主機通話,誰知道它的 MAC地址?」。
數據鏈路上的全部主機都會收到這條消息並檢查本身的 IP 地址,若是與 ARP 請求包中的 IP 地址一致,主機就會發送 ARP 響應包:「我就是 IP 地址爲 xxx 的主機,個人 MAC 地址是:xxxx」。
下圖表示了 ARP 協議的工做機制:
在實際的使用過程當中,每次往目標主機發送數據都要使用 ARP 是很低效的,一般的作法是把獲取到的 MAC 地址緩存一段時間。通常來講,一旦源主機向目標地址發送一個數據包,接下來繼續發送屢次的機率很是大,所以這種緩存很是容易命中。
當下一次發送 ARP 請求或超過必定時間後,緩存都會失效,這保證了即便 MAC 地址與 IP 地址的對應關係發生了變化,數據包依然可以被正確的發往目標地址。
MAC 和 IP 地址雖然看上去功能相似(都是用於惟一區分主機),可是二者缺一不可。若是隻有 IP 地址,雖然能夠跳過 ARP,直接在數據鏈路上發一個廣播,可是這僅適用於通訊雙方處於同一個數據鏈路下的狀況。若是雙方處於不一樣的數據鏈路,數據報沒法穿透中間的路由器。
僅憑MAC地址,人們沒法知道這臺機器所處的位置。若是全世界只用 MAC 地址,那麼網橋就得向全世界發包,那麼請參考交換機的自學過程,能夠想象這個過程會帶來龐大的,沒必要要的流量,並且網橋要維護一張巨大的表格來維護全部學到的MAC地址,當這些信超過網橋極限,就無法工做了,也就沒法通訊了。
正由於 MAC 和 IP 地址缺一不可,因此才產生了 ARP 這樣的協議將二者關聯起來。
RARP(Reverse Address Resolution Protocol)是將ARP反過來,從MAC地址定位IP地址的一種協議。
一般ARP包會被路由器隔離,可是採用代理ARP的路由器能夠將ARP請求轉發給鄰近的網段。由此兩個以上網段的節點之間能夠像在同一個網段中同樣進行通訊。
通常狀況下有路由器鏈接多個網絡時,會在每一個網段定義各自的子網,從而進行路由控制,可是對於那些不支持設定子網掩碼的老設備,不適用代理ARP,有時就沒法更好的使用網絡。
架構IP網絡時須要特別注意兩點:確認網絡是否正常工做,以及遇到異常時進行問題診斷。
ICMP正是提供這類功能的一種協議。
主要功能包括:確認IP包是否成功送達目標地址,通知在發送過程當中IP包被廢棄的具體緣由,改善網絡設置等。
ICMP的消息大體能夠分爲兩類:一類是通知出錯緣由的錯誤消息,另外一類是用於診斷的查詢消息。
逐一爲每一臺主機設置IP地址會很是繁瑣的事情。特別是移動設備,每到一個新地方,就要從新設置IP地址
因而爲了實現自動設置IP地址、統一管理IP地址分配,就產生了DHCP協議。
有了DHCP,計算機只要鏈接到網絡,就能夠進行TCP/IP通訊。
使用DHCP前,首先要假設一臺DHCP服務器。而後將DHCP所要分配的IP地址設置到服務器上。此外,還須要將相應的子網掩碼、路由控制信息以及DNS服務器的地址等設置到服務器上。
爲了檢查所要分配的IP地址以及已經分配了的IP地址是否可用,DHCP服務器或DHCP客戶端必須具有如下功能:
在大規模組織機構的網絡環境中,每每須要將DHCP統一管理
NAT (Network Address Translator) 是一種用於將局域網中的私有地址轉換成全局 IP 地址的技術。
在鏈接上無線路由器的時候,若是檢查一下設備的 IP 地址,也許你會發現是相似於 192.168.1.1 這樣的局域網 IP 地址。那不一樣網段中,IP 地址都是 192.168.1.1 的主機改如何通訊呢?
局域網中 IP 地址爲 10.0.0.10 的主機向全局 IP 地址 163.221.120.9 發送數據。NAT 路由器將數據包的源地址修改爲本身的全局 IP 地址:202.244.174.37。同理,接收數據時,路由器把目標地址 202.244.174.37 翻譯成內網地址:10.0.0.10
下圖描繪了 NAT 的工做原理:
路由器只有一個對外的全局 IP 地址,若是有多個內網主機都向外部通信怎麼辦呢?這時就要使用 NAPT 技術,它和 NAT 從原理上相似,但它能夠轉換 TCP 和 UDP 端口號。
使用 NAPT 技術時,不一樣的內網 IP 被轉換成同一個公共 IP 地址,也就是路由器對外顯示的全局 IP 地址,可是被附加不一樣的端口號以示區分:
不論是 NAT 仍是 NAPT,都須要路由器路由器內部維護一張自動生成的地址轉換表。以 TCP 爲例,創建 TCP 鏈接首次握手的 SYN 包發出時會生成這個表,關閉鏈接時會發出 FIN 包,收到這個包的應答時轉換表被刪除。
在下圖所示的網絡環境中,網絡A、B使用IPv6,若是處於中間位置的網絡C支持使用IPv4的話,A與B之間就沒法直接進行通訊。爲了讓他們之間正常通訊,這是必須得采用IP隧道的功能。
IP隧道中能夠將那些從網絡A發過來的IPv6的包統和爲一個數據,再爲之追加一個IPv4的首部之後轉發給網絡C。
通常狀況下,緊接着IP首部的是TCP或UDP的首部。然而,如今的應用中,"IP首部的後面仍是IP首部"或者"IP首部的後面是IPv6的首部"等狀況與日俱增。這種在網絡層的首部後面繼續追加網絡層首部 的通訊方法就叫作"IP隧道"。