IP 基礎知識「全家桶」，45 張圖一套帶走

時間 2021-01-16

標籤面試設計模式數組瀏覽器緩存安全服務器網絡併發工具欄目應用數學简体版

原文原文鏈接

前言

前段時間，有讀者但願我寫一篇關於 IP 分類地址、子網劃分等的文章，他反饋經常混淆，摸不着頭腦。面試

那麼，說來就來！並且要盤就盤全一點，順便挑戰下小林的圖解功力，因此就來個 IP 基礎知識全家桶。設計模式

吃完這個 IP 基礎知識全家桶全家桶，包你撐着肚子喊出：「真香！」數組

很少說，直接上菜，共分爲三道菜：瀏覽器

首先是前菜「 IP 基本認識」
其次是主菜「IP 地址的基礎知識」
最後是點心「IP 協議相關技術」

正文

前菜 —— IP 基本認識

IP 在 TCP/IP 參考模型中處於第三層，也就是網絡層。緩存

網絡層的主要做用是：實現主機與主機之間的通訊，也叫點對點（end to end）通訊。安全

網絡層與數據鏈路層有什麼關係呢？

有的小夥伴分不清 IP（網絡層）和 MAC （數據鏈路層）之間的區別和關係。服務器

其實很容易區分，在上面咱們知道 IP 的做用是主機之間通訊中的，而 MAC 的做用則是實現「直連」的兩個設備之間通訊，而 IP 則負責在「沒有直連」的兩個網絡之間進行通訊傳輸。網絡

舉個生活的栗子，小林要去一個很遠的地方旅行，制定了一個行程表，其間需前後乘坐飛機、地鐵、公交車才能抵達目的地，爲此小林須要買飛機票，地鐵票等。併發

飛機票和地鐵票都是去往特定的地點的，每張票只可以在某一限定區間內移動，此處的「區間內」就如同通訊網絡中數據鏈路。工具

在區間內移動至關於數據鏈路層，充當區間內兩個節點傳輸的功能，區間內的出發點比如源 MAC 地址，目標地點比如目的 MAC 地址。

整個旅遊行程表就至關於網絡層，充當遠程定位的功能，行程的開始比如源 IP，行程的終點比如目的 IP 地址。

若是小林只有行程表而沒有車票，就沒法搭乘交通工具到達目的地。相反，若是除了車票而沒有行程表，恐怕也很難到達目的地。由於小林不知道該坐什麼車，也不知道該在哪裏換乘。

所以，只有二者兼備，既有某個區間的車票又有整個旅行的行程表，才能保證到達目的地。與此相似，計算機網絡中也須要「數據鏈路層」和「網絡層」這個分層才能實現向最終目標地址的通訊。

還有重要一點，旅行途中咱們雖然不斷變化了交通工具，可是旅行行程的起始地址和目的地址始終都沒變。其實，在網絡中數據包傳輸中也是如此，*源IP地址和目標IP地址在傳輸過程當中是不會變化的，只有源 MAC 地址和目標 MAC 一直在變化*。

主菜 —— IP 地址的基礎知識

在 TCP/IP 網絡通訊時，爲了保證能正常通訊，每一個設備都須要配置正確的 IP 地址，不然沒法實現正常的通訊。

IP 地址（IPv4 地址）由 32 位正整數來表示，IP 地址在計算機是以二進制的方式處理的。

而人類爲了方便記憶採用了點分十進制的標記方式，也就是將 32 位 IP 地址以每 8 位爲組，共分爲 4 組，每組以「.」隔開，再將每組轉換成十進制。

那麼，IP 地址最大值也就是

也就說，最大容許 43 億臺計算機鏈接到網絡。

實際上，IP 地址並非根據主機臺數來配置的，而是以網卡。像服務器、路由器等設備都是有 2 個以上的網卡，也就是它們會有 2 個以上的 IP 地址。

所以，讓 43 億臺計算機所有連網實際上是不可能的，更況且 IP 地址是由「網絡標識」和「主機標識」這兩個部分組成的，因此實際可以鏈接到網絡的計算機個數更是少了不少。

可能有的小夥伴提出了疑問，如今不只電腦配了 IP，手機、IPad 等電子設備都配了 IP 呀，照理來講確定會超過 43 億啦，那是怎麼可以支持這麼多 IP 的呢？

由於會根據一種能夠更換 IP 地址的技術 NAT，使得可鏈接計算機數超過 43 億臺。NAT 技術後續會進一步討論和說明。

IP 地址的分類

互聯網誕生之初，IP 地址顯得很充裕，因而計算機科學家們設計了分類地址。

IP 地址分類成了 5 種類型，分別是 A 類、B 類、C 類、D 類、E 類。

上圖中黃色部是分類號，用以區分 IP 地址類別。

什麼是 A、B、C 類地址？

其中對於 A、B、C 類主要分爲兩個部分，分別是網絡號和主機號。這很好理解，比如小林是 A 小區 1 棟 101 號，你是 B 小區 1 棟 101 號。

咱們能夠用下面這個表格，就能很清楚的知道 A、B、C 分類對應的地址範圍、最大主機個數。

A、B、C 分類地址最大主機個數是如何計算的呢？

最大主機個數，就是要看主機號的位數，如 C 類地址的主機號佔 8 位，那麼 C 類地址的最大主機個數

爲何要減 2 呢？

由於在 IP 地址中，有兩個 IP 是特殊的，分別是主機號全爲 1 和全爲 0 地址。

主機號全爲 1 指定某個網絡下的全部主機，用於廣播
主機號全爲 0 指定某個網絡

所以，在分配過程當中，應該去掉這兩種狀況。

廣播地址用於什麼？

廣播地址用於在同一個鏈路中相互鏈接的主機之間發送數據包。

學校班級中就有廣播的例子，在準備上課的時候，一般班長會喊：「上課，全體起立！」，班裏的同窗聽到這句話是否是所有都站起來了？這個句話就有廣播的含義。

當主機號全爲 1 時，就表示該網絡的廣播地址。例如把 172.20.0.0/16 用二進制表示以下：

10101100.00010100.00000000.00000000

將這個地址的主機部分所有改成 1，則造成廣播地址：

10101100.00010100.11111111.11111111

再將這個地址用十進制表示，則爲 172.20.255.255。

廣播地址能夠分爲本地廣播和直接廣播兩種。

在本網絡內廣播的叫作本地廣播。例如網絡地址爲 192.168.0.0/24 的狀況下，廣播地址是 192.168.0.255 。由於這個廣播地址的 IP 包會被路由器屏蔽，因此不會到達 192.168.0.0/24 之外的其餘鏈路上。
在不一樣網絡之間的廣播叫作直接廣播。例如網絡地址爲 192.168.0.0/24 的主機向 192.168.1.255/24 的目標地址發送 IP 包。收到這個包的路由器，將數據轉發給192.168.1.0/24，從而使得全部 192.168.1.1~192.168.1.254 的主機都能收到這個包（因爲直接廣播有必定的安全問題，多數狀況下會在路由器上設置爲不轉發）。

什麼是 D、E 類地址？

而 D 類和 E 類地址是沒有主機號的，因此不可用於主機 IP，D 類常被用於多播，E 類是預留的分類，暫時未使用。

多播地址用於什麼？

多播用於*將包發送給特定組內的全部主機*。

仍是舉班級的栗子，老師說：「最後一排的同窗，上來作這道數學題。」，老師是指定的是最後一排的同窗，也就是多播的含義了。

因爲廣播沒法穿透路由，若想給其餘網段發送一樣的包，就可使用能夠穿透路由的多播（組播）。

多播使用的 D 類地址，其前四位是 1110 就表示是多播地址，而剩下的 28 位是多播的組編號。

從 224.0.0.0 ~ 239.255.255.255 都是多播的可用範圍，其劃分爲如下三類：

224.0.0.0 ~ 224.0.0.255 爲預留的組播地址，只能局域網中，路由器是不會進行轉發的
224.0.1.0 ~ 238.255.255.255 爲用戶可用的組播地址，能夠用於 Internet 上
239.0.0.0 ~ 239.255.255.255 爲本地管理組播地址，可供內部網在內部使用，僅在特定的本地範圍內有效

IP 分類的優勢

無論是路由器仍是主機解析到一個 IP 地址時候，咱們判斷其 IP 地址的首位是否爲 0，爲 0 則爲 A 類地址，那麼就能很快的找出網絡地址和主機地址。

其他分類判斷方式參考以下圖：

因此，這種分類地址的優勢就是簡單明瞭、選路（基於網絡地址）簡單。

IP 分類的缺點

缺點一

同一網絡下沒有地址層次，好比一個公司裏用了 B 類地址，可是可能須要根據生產環境、測試環境、開發環境來劃分地址層次，而這種 IP 分類是沒有地址層次劃分的功能，因此這就缺乏地址的靈活性。

缺點二

A、B、C類有個尷尬處境，就是不能很好的與現實網絡匹配。

C 類地址能包含的最大主機數量實在太少了，只有 254 個，估計一個網吧都不夠用。
而 B 類地址能包含的最大主機數量又太多了，6 萬多臺機器放在一個網絡下面，通常的企業基本達不到這個規模，閒着的地址就是浪費。

這兩個缺點，均可以在 CIDR 無分類地址解決。

無分類地址 CIDR

正由於 IP 分類存在許多缺點，全部後面提出了無分類地址的方案，即 CIDR。

這種方式再也不有分類地址的概念，32 比特的 IP 地址被劃分爲兩部分，前面是網絡號，後面是主機號。

怎麼劃分網絡號和主機號的呢？

表示形式 a.b.c.d/x，其中 /x 表示前 x 位屬於網絡號， x 的範圍是 0 ~ 32，這就使得 IP 地址更加具備靈活性。

好比 10.100.122.2/24，這種地址表示形式就是 CIDR，/24 表示前 24 位是網絡號，剩餘的 8 位是主機號。

還有另外一種劃分網絡號與主機號形式，那就是子網掩碼，掩碼的意思就是掩蓋掉主機號，剩餘的就是網絡號。

將子網掩碼和 IP 地址按位計算 AND，就可獲得網絡號。

爲何要分離網絡號和主機號？

由於兩臺計算機要通信，首先要判斷是否處於同一個廣播域內，即網絡地址是否相同。若是網絡地址相同，代表接受方在本網絡上，那麼能夠把數據包直接發送到目標主機，

路由器尋址工做中，也就是經過這樣的方式來找到對應的網絡號的，進而把數據包轉發給對應的網絡內。

怎麼進行子網劃分？

在上面咱們知道能夠經過子網掩碼劃分出網絡號和主機號，那實際上子網掩碼還有一個做用，那就是劃分子網。

子網劃分其實是將主機地址分爲兩個部分：子網網絡地址和子網主機地址。形式以下：

未作子網劃分的 ip 地址：網絡地址＋主機地址
作子網劃分後的 ip 地址：網絡地址＋（子網網絡地址＋子網主機地址）

假設對 C 類地址進行子網劃分，網絡地址 192.168.1.0，使用子網掩碼 255.255.255.192 對其進行子網劃分。

C 類地址中前 24 位是網絡號，最後 8 位是主機號，根據子網掩碼可知從 8 位主機號中借用 2 位做爲子網號。

因爲子網網絡地址被劃分紅 2 位，那麼子網地址就有 4 個，分別是 00、0一、十、11，具體劃分以下圖：

劃分後的 4 個子網以下表格：

公有 IP 地址與私有 IP 地址

在 A、B、C 分類地址，實際上有分公有 IP 地址和私有 IP 地址。

平時咱們辦公室、家裏、學校用的 IP 地址，通常都是私有 IP 地址。由於這些地址容許組織內部的 IT 人員本身管理、本身分配，並且能夠重複。所以，你學校的某個私有 IP 地址和我學校的能夠是同樣的。

就像每一個小區都有本身的樓編號和門牌號，你小區家能夠叫 1 棟 101 號，我小區家也能夠叫 1 棟 101，沒有任何問題。但一旦出了小區，就須要帶上中山路 666 號（公網 IP 地址），是國家統一分配的，不能兩個小區都叫中山路 666。

因此，公有 IP 地址是有個組織統一分配的，假設你要開一個博客網站，那麼你就須要去申請購買一個公有 IP，這樣全世界的人才能訪問。而且公有 IP 地址基本上要在整個互聯網範圍內保持惟一。

公有 IP 地址由誰管理呢？

私有 IP 地址一般是內部的 IT 人員值管理，公有 IP 地址是由 ICANN 組織管理，中文叫「互聯網名稱與數字地址分配機構」。

IANA 是 ICANN 的其中一個機構，它負責分配互聯網 IP 地址，是按州的方式層層分配。

ARIN 北美地區
LACNIC 拉丁美洲和一些加勒比羣島
RIPE NCC 歐洲、中東和中亞
AfriNIC 非洲地區
APNIC 亞太地區

其中，在中國是由 CNNIC 的機構進行管理，它是中國國內惟一指定的全局 IP 地址管理的組織。

IP 地址與路由控制

IP地址的網絡地址這一部分是用於進行路由控制。

路由控制表中記錄着網絡地址與下一步應該發送至路由器的地址，在主機和路由器上都會有各自的路由器控制表。

在發送 IP 包時，首先要肯定 IP 包首部中的目標地址，再從路由控制表中找到與該地址具備相同網絡地址的記錄，根據該記錄將 IP 包轉發給相應的下一個路由器。若是路由控制表中存在多條相同網絡地址的記錄，就選擇相同位數最多的網絡地址，也就是最長匹配。

下面如下圖的網絡鏈路做爲例子說明：

主機 A 要發送一個 IP 包，其源地址是 10.1.1.30 和目標地址是 10.1.2.10，因爲沒有在主機 A 的路由表找到與目標地址 10.1.2.10 的網絡地址，因而把包被轉發到默認路由（路由器 1 ）
路由器 1 收到 IP 包後，也在路由器 1 的路由表匹配與目標地址相同的網絡地址記錄，發現匹配到了，因而就把 IP 數據包轉發到了 10.1.0.2 這臺路由器 2
路由器 2 收到後，一樣對比自身的路由表，發現匹配到了，因而把 IP 包從路由器 2 的 10.1.2.1 這個接口出去，最終通過交換機把 IP 數據包轉發到了目標主機

環回地址是不會流向網絡

環回地址是在同一臺計算機上的程序之間進行網絡通訊時所使用的一個默認地址。

計算機使用一個特殊的 IP 地址 *127.0.0.1 做爲環回地址*，與該地址具備相贊成義的是一個叫作 localhost 的主機名。

使用這個 IP 或主機名時，數據包不會流向網絡。

IP 分片與重組

每種數據鏈路的最大傳輸單元 MTU 都是不相同的，如 FDDI 數據鏈路 MTU 435二、以太網的 MTU 是 1500 字節等。

每種數據鏈路的 MTU 之因此不一樣，是由於每一個不一樣類型的數據鏈路的使用目的不一樣。使用目的不一樣，可承載的 MTU 也就不一樣。

其中，咱們最多見數據鏈路是以太網，它的 MTU 是 1500 字節。

那麼當 IP 數據包大小大於 MTU 時， IP 數據包就會被分片。

通過分片以後的 IP 數據報在被重組的時候，只能由目標主機進行，路由器是不會進行重組的。

假設發送方發送一個 4000 字節的大數據報，若要傳輸在以太網鏈路，則須要把數據報分片成 3 個小數據報進行傳輸，再交由接收方重組成大數據報。

在分片傳輸中，一旦某個分片丟失，則會形成整個 IP 數據報做廢，因此 TCP 引入了 MSS 也就是在 TCP 層進行分片不禁 IP 層分片，那麼對於 UDP 咱們儘可能不要發送一個大於 MTU 的數據報文。

IPv6 基本認識

IPv4 的地址是 32 位的，大約能夠提供 42 億個地址，可是早在 2011 年 IPv4 地址就已經被分配完了。

可是 IPv6 的地址是 128 位的，這可分配的地址數量是大的驚人，說個段子 *IPv6 能夠保證地球上的每粒沙子都能被分配到一個 IP 地址*。

但 IPv6 除了有更多的地址以外，還有更好的安全性和擴展性，說簡單點就是 IPv6 相比於 IPv4 能帶來更好的網絡體驗。

可是由於 IPv4 和 IPv6 不能相互兼容，因此不但要咱們電腦、手機之類的設備支持，還須要網絡運營商對現有的設備進行升級，因此這多是 IPv6 普及率比較慢的一個緣由。

IPv6 的亮點

IPv6 不只僅只是可分配的地址變多了，他還有很是多的亮點。

IPv6 可自動配置，即便沒有 DHCP 服務器也能夠實現自動分配IP地址，真是便捷到即插即用啊。
IPv6 包頭包首部長度採用固定的值 40 字節，去掉了包頭校驗和，簡化了首部結構，減輕了路由器負荷，大大提升了傳輸的性能。
IPv6 有應對僞造 IP 地址的網絡安全功能以及防止線路竊聽的功能，大大提高了安全性。
… （由你發現更多的亮點）

IPv6 地址的標識方法

IPv4 地址長度共 32 位，是以每 8 位做爲一組，並用點分十進制的表示方式。

IPv6 地址長度是 128 位，是以每 16 位做爲一組，每組用冒號「:」隔開。

若是出現連續的 0 時還能夠將這些 0 省略，並用兩個冒號「::」隔開。可是，一個 IP 地址中只容許出現一次兩個連續的冒號。

IPv6 地址的結構

IPv6 相似 IPv4，也是經過 IP 地址的前幾位標識 IP 地址的種類。

IPv6 的地址主要有一下類型地址：

單播地址，用於一對一的通訊
組播地址，用於一對多的通訊
任播地址，用於通訊最近的節點，最近的節點是由路由協議決定
沒有廣播地址

IPv6 單播地址類型

對於一對一通訊的 IPv6 地址，主要劃分了三類單播地址，每類地址的有效範圍都不一樣。

在同一鏈路單播通訊，不通過路由器，可使用鏈路本地單播地址，IPv4 沒有此類型
在內網裏單播通訊，可使用惟一本地地址，至關於 IPv4 的私有 IP
在互聯網通訊，可使用全局單播地址，至關於 IPv4 的公有 IP

IPv4 首部與 IPv6 首部

IPv4 首部與 IPv6 首部的差別以下圖：

IPv6 相比 IPv4 的首部改進：

取消了首部校驗和字段。 由於在數據鏈路層和傳輸層都會校驗，所以 IPv6 直接取消了 IP 的校驗。
取消了分片/從新組裝相關字段。 分片與重組是耗時的過程，IPv6 不容許在中間路由器進行分片與重組，這種操做只能在源與目標主機，這將大大提升了路由器轉發的速度。
取消選項字段。 選項字段再也不是標準 IP 首部的一部分了，但它並無消失，而是可能出如今 IPv6 首部中的「下一個首部」指出的位置上。刪除該選項字段是的 IPv6 的首部成爲固定長度的 40 字節。

點心 —— IP 協議相關技術

跟 IP 協議相關的技術也很多，接下來講說與 IP 協議相關的重要且常見的技術。

DNS 域名解析
ARP 與 RARP 協議
DHCP 動態獲取 IP 地址
NAT 網絡地址轉換
ICMP 互聯網控制報文協議
IGMP 因特網組管理協

DNS

咱們在上網的時候，一般使用的方式域名，而不是 IP 地址，由於域名方便人類記憶。

那麼實現這一技術的就是 DNS 域名解析，DNS 能夠將域名網址自動轉換爲具體的 IP 地址。

域名的層級關係

DNS 中的域名都是用句點來分隔的，好比 www.server.com，這裏的句點表明了不一樣層次之間的界限。

在域名中，越靠右的位置表示其層級越高。

畢竟域名是外國人發明，因此思惟和中國人相反，好比說一個城市地點的時候，外國喜歡從小到大的方式順序提及（如 XX 街道 XX 區 XX 市 XX 省），而中國則喜歡從大到小的順序（如 XX 省 XX 市 XX 區 XX 街道）。

根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com。

因此域名的層級關係相似一個樹狀結構：

根 DNS 服務器
頂級域 DNS 服務器（com）
權威 DNS 服務器（server.com）

根域的 DNS 服務器信息保存在互聯網中全部的 DNS 服務器中。這樣一來，任何 DNS 服務器就均可以找到並訪問根域 DNS 服務器了。

所以，客戶端只要可以找到任意一臺 DNS 服務器，就能夠經過它找到根域 DNS 服務器，而後再一路順藤摸瓜找到位於下層的某臺目標 DNS 服務器。

域名解析的工做流程

瀏覽器首先看一下本身的緩存裏有沒有，若是沒有就向操做系統的緩存要，尚未就檢查本機域名解析文件 hosts，若是仍是沒有，就會 DNS 服務器進行查詢，查詢的過程以下：

客戶端首先會發出一個 DNS 請求，問 www.server.com 的 IP 是啥，併發給本地 DNS 服務器（也就是客戶端的 TCP/IP 設置中填寫的 DNS 服務器地址）。
本地域名服務器收到客戶端的請求後，若是緩存裏的表格能找到 www.server.com，則它直接返回 IP 地址。若是沒有，本地 DNS 會去問它的根域名服務器：「老大，能告訴我 www.server.com 的 IP 地址嗎？」根域名服務器是最高層次的，它不直接用於域名解析，但能指明一條道路。
根 DNS 收到來自本地 DNS 的請求後，發現後置是 .com，說：「www.server.com 這個域名歸 .com 區域管理」，我給你 .com 頂級域名服務器地址給你，你去問問它吧。」
本地 DNS 收到頂級域名服務器的地址後，發起請求問「老二，你能告訴我 www.server.com 的 IP 地址嗎？」
頂級域名服務器說：「我給你負責 www.server.com 區域的權威 DNS 服務器的地址，你去問它應該能問到」。
本地 DNS 因而轉向問權威 DNS 服務器：「老三，www.server.com對應的IP是啥呀？」 server.com 的權威 DNS 服務器，它是域名解析結果的原出處。爲啥叫權威呢？就是個人域名我作主。
權威 DNS 服務器查詢後將對應的 IP 地址 X.X.X.X 告訴本地 DNS。
本地 DNS 再將 IP 地址返回客戶端，客戶端和目標創建鏈接。

至此，咱們完成了 DNS 的解析過程。如今總結一下，整個過程我畫成了一個圖。

DNS 域名解析的過程蠻有意思的，整個過程就和咱們平常生活中找人問路的過程相似，只指路不帶路。

ARP

在傳輸一個 IP 數據報的時候，肯定了源 IP 地址和目標 IP 地址後，就會經過主機「路由表」肯定 IP 數據包下一跳。然而，網絡層的下一層是數據鏈路層，因此咱們還要知道「下一跳」的 MAC 地址。

因爲主機的路由表中能夠找到下一條的 IP 地址，因此能夠經過 ARP 協議，求得下一跳的 MAC 地址。

那麼 ARP 又是如何知道對方 MAC 地址的呢？

簡單地說，ARP 是藉助 ARP 請求與 ARP 響應兩種類型的包肯定 MAC 地址的。

主機會經過廣播發送 ARP 請求，這個包中包含了想要知道的 MAC 地址的主機 IP 地址。
當同個鏈路中的全部設備收到 ARP 請求時，會去拆開 ARP 請求包裏的內容，若是 ARP 請求包中的目標 IP 地址與本身的 IP 地址一致，那麼這個設備就將本身的 MAC 地址塞入 ARP 響應包返回給主機。

操做系統一般會把第一次經過 ARP 獲取的 MAC 地址緩存起來，以便下次直接從緩存中找到對應 IP 地址的 MAC 地址。

不過，MAC 地址的緩存是有必定期限的，超過這個期限，緩存的內容將被清除。

RARP 協議你知道是什麼嗎？

ARP 協議是已知 IP 地址求 MAC 地址，那 RARP 協議正好相反。

它是已知 MAC 地址求 IP 地址。例如將打印機服務器等小型嵌入式設備接入到網絡時就常常會用獲得。

一般這須要架設一臺 RARP 服務器，在這個服務器上註冊設備的 MAC 地址及其 IP 地址。而後再將這個設備接入到網絡，接着：

該設備會發送一條「個人 MAC 地址是XXXX，請告訴我，個人IP地址應該是什麼」的請求信息。
RARP 服務器接到這個消息後返回「MAC地址爲 XXXX 的設備，IP地址爲 XXXX」的信息給這個設備。

最後，設備就根據從 RARP 服務器所收到的應答信息設置本身的 IP 地址。

DHCP

DHCP 在生活中咱們是很常見的了，咱們的電腦一般都是經過 DHCP 動態獲取 IP 地址，大大省去了配 IP 信息繁瑣的過程。

接下來，咱們來看看咱們的電腦是如何經過 4 個步驟的過程，獲取到 IP 的。

先說明一點，DHCP 客戶端進程監聽的是 68 端口號，DHCP 服務端進程監聽的是 67 端口號。

DHCP 交互的 4 個步驟：

客戶端首先發起 DHCP 發現報文（DHCP DISCOVER） 的 IP 數據報，因爲客戶端沒有 IP 地址，也不知道 DHCP 服務器的地址，因此使用的是 UDP 廣播通訊，其使用的廣播目的地址是 255.255.255.255（端口 67）而且使用 0.0.0.0（端口 68）做爲源 IP 地址。DHCP 客戶端將該 IP 數據報傳遞給鏈路層，鏈路層而後將幀廣播到全部的網絡中設備。
DHCP 服務器收到 DHCP 發現報文時，用 DHCP 提供報文（DHCP OFFER） 向客戶端作出響應。該報文仍然使用 IP 廣播地址 255.255.255.255，該報文信息攜帶服務器提供可租約的 IP 地址、子網掩碼、默認網關、DNS 服務器以及 IP 地址租用期。
客戶端收到一個或多個服務器的 DHCP 提供報文後，從中選擇一個服務器，並向選中的服務器發送 DHCP 請求報文（DHCP REQUEST進行響應，回顯配置的參數。
最後，服務端用 DHCP ACK 報文對 DHCP 請求報文進行響應，應答所要求的參數。

一旦客戶端收到 DHCP ACK 後，交互便完成了，而且客戶端可以在租用期內使用 DHCP 服務器分配的 IP 地址。

若是租約的 DHCP IP 地址快期後，客戶端會向服務器發送 DHCP 請求報文：

服務器若是贊成繼續租用，則用 DHCP ACK 報文進行應答，客戶端就會延長租期。
服務器若是不一樣意繼續租用，則用 DHCP NACK 報文，客戶端就要中止使用租約的 IP 地址。

能夠發現，DHCP 交互中，全程都是使用 UDP 廣播通訊。

咦，用的是廣播，那若是 DHCP 服務器和客戶端不是在同一個局域網內，路由器又不會轉發廣播包，那不是每一個網絡都要配一個 DHCP 服務器？

因此，爲了解決這一問題，就出現了 DHCP 中繼代理。

有了 DHCP 中繼代理之後，對不一樣網段的 IP 地址分配也能夠由一個 DHCP 服務器統一進行管理。

DHCP 客戶端會向 DHCP 中繼代理髮送 DHCP 請求包，而 DHCP 中繼代理在收到這個廣播包之後，再以單播的形式發給 DHCP 服務器。
服務器端收到該包之後再向 DHCP 中繼代理返回應答，並由 DHCP 中繼代理將此包轉發給 DHCP 客戶端。

所以，DHCP 服務器即便不在同一個鏈路上也能夠實現統一分配和管理IP地址。

NAT

IPv4 的地址是很是緊缺的，在前面咱們也提到能夠經過無分類地址來減緩 IPv4 地址耗盡的速度，可是互聯網的用戶增速是很是驚人的，因此 IPv4 地址依然有被耗盡的危險。

因而，提出了一個種網絡地址轉換 NAT 的方法，再次緩解了 IPv4 地址耗盡的問題。

簡單的來講 NAT 就是在同個公司、家庭、教室內的主機對外部通訊時，把私有 IP 地址轉換成公有 IP 地址。

那不是 N 個私有 IP 地址，你就要 N 個公有 IP 地址？這怎麼就緩解了 IPv4 地址耗盡的問題？這不瞎扯嗎？

確實是，普通的 NAT 轉換沒什麼意義。

因爲絕大多數的網絡應用都是使用傳輸層協議 TCP 或 UDP 來傳輸數據的。

所以，能夠把 IP 地址 + 端口號一塊兒進行轉換。

這樣，就用一個全球 IP 地址就能夠了，這種轉換技術就叫網絡地址與端口轉換 NAPT。

很抽象？來，看下面的圖解就能瞬間明白了。

圖中有兩個客戶端 192.168.1.10 和 192.168.1.11 同時與服務器 183.232.231.172 進行通訊，而且這兩個客戶端的本地端口都是 1025。

此時，*兩個私有 IP 地址都轉換 IP 地址爲公有地址 120.229.175.121，可是以不一樣的端口號做爲區分*。

因而，生成一個 NAPT 路由器的轉換表，就能夠正確地轉換地址跟端口的組合，令客戶端 A、B 能同時與服務器之間進行通訊。

這種轉換表在 NAT 路由器上自動生成。例如，在 TCP 的狀況下，創建 TCP 鏈接首次握手時的 SYN 包一經發出，就會生成這個表。然後又隨着收到關閉鏈接時發出 FIN 包的確認應答從表中被刪除。

NAT 那麼牛逼，難道就沒缺點了嗎？

固然有缺陷，確定沒有十全十美的方案。

因爲 NAT/NAPT 都依賴於本身的轉換表，所以會有如下的問題：

外部沒法主動與 NAT 內部服務器創建鏈接，由於 NAPT 轉換表沒有轉換記錄。
轉換表的生產與轉換操做都會產生性能開銷。
通訊過程當中，若是 NAT 路由器重啓了，全部的 TCP 鏈接都將被重置。

如何解決 NAT 潛在的問題呢？

解決的方法主要兩種方法。

第一種就是改用 IPv6

IPv6 可用範圍很是大，以致於每臺設備均可以配置一個公有 IP 地址，就不搞那麼多花裏胡哨的地址轉換了，可是 IPv6 普及速度還須要一些時間。

第二種 NAT 穿透技術

NAT 穿越技術擁有這樣的功能，它可以讓網絡應用程序主動發現本身位於 NAT 設備以後，而且會主動得到 NAT 設備的公有 IP，併爲本身創建端口映射條目，注意這些都是 NAT設備後的應用程序自動完成的。

也就是說，在 NAT 穿越技術中，NAT 設備後的應用程序處於主動地位，它已經明確地知道 NAT 設備要修改它外發的數據包，因而它主動配合 NAT 設備的操做，主動地創建好映射，這樣就不像之前由 NAT 設備來創建映射了。

說人話，就是客戶端主動從 NAT 設備獲取公有 IP 地址，而後本身創建端口映射條目，而後用這個條目對外通訊，就不須要 NAT 設備來進行轉換了。

ICMP

ICMP 全稱是 Internet Control Message Protocol，也就是互聯網控制報文協議。

裏面有個關鍵詞 —— 控制，如何控制的呢？

網絡包在複雜的網絡傳輸環境裏，經常會遇到各類問題。

當遇到問題的時候，總不能死個不明不白，沒頭沒腦的做風不是計算機網絡的風格。因此須要傳出消息，報告遇到了什麼問題，這樣才能夠調整傳輸策略，以此來控制整個局面。

ICMP 功能都有啥？

ICMP 主要的功能包括：*確認 IP 包是否成功送達目標地址、報告發送過程當中 IP 包被廢棄的緣由和改善網絡設置等*。

在 IP 通訊中若是某個 IP 包由於某種緣由未能達到目標地址，那麼這個具體的緣由將由 ICMP 負責通知。

如上圖例子，主機 A 向主機 B 發送了數據包，因爲某種緣由，途中的路由器 2 未能發現主機 B 的存在，這時，路由器 2 就會向主機 A 發送一個 ICMP 目標不可達數據包，說明發往主機 B 的包未能成功。

ICMP 的這種通知消息會使用 IP 進行發送。

所以，從路由器 2 返回的 ICMP 包會按照往常的路由控制先通過路由器 1 再轉發給主機 A 。收到該 ICMP 包的主機 A 則分解 ICMP 的首部和數據域之後得知具體發生問題的緣由。

ICMP 類型

ICMP 大體能夠分爲兩大類：

一類是用於診斷的查詢消息，也就是「查詢報文類型」
另外一類是通知出錯緣由的錯誤消息，也就是「差錯報文類型」

IGMP

ICMP 跟 IGMP 是一點關係都沒有的，就好像周杰與周杰倫的區別，你們不要混淆了。

在前面咱們知道了組播地址，也就是 D 類地址，既然是組播，那就說明是隻有一組的主機能收到數據包，不在一組的主機不能收到數組包，怎麼管理是不是在一組呢？那麼，就須要 IGMP 協議了。

IGMP 是因特網組管理協議，工做在主機（組播成員）和最後一跳路由之間，如上圖中的藍色部分。

IGMP 報文向路由器申請加入和退出組播組，默認狀況下路由器是不會轉發組播包到鏈接中的主機，除非主機經過 IGMP 加入到組播組，主機申請加入到組播組時，路由器就會記錄 IGMP 路由器表，路由器後續就會轉發該組播地址的數據包了。
IGMP 報文采用 IP 封裝，IP 頭部的協議號爲 2，並且 TTL 字段值一般爲 1，由於 IGMP 是工做在主機與鏈接的路由器之間。

IGMP 工做機制

IGMP 分爲了三個版本分別是，IGMPv一、IGMPv二、IGMPv3。

接下來，以 IGMPv2 做爲例子，說說常規查詢與響應和離開組播組這兩個工做機制。

常規查詢與響應工做機制

路由器會週期性發送目的地址爲 224.0.0.1（表示同一網段內全部主機和路由器） *IGMP 常規查詢報文*；
主機1 和主機 3 收到這個查詢，隨後會啓動「報告延遲計時器」，計時器的時間是隨機的，一般是 0~10 秒，計時器超時後主機就會發送 IGMP 成員關係報告報文（源 IP 地址爲本身主機的 IP 地址，目的 IP 地址爲組播地址）。若是在定時器超時以前，收到同一個組內的其餘主機發送的成員關係報告報文，則本身再也不發送，這樣能夠減小網絡中多餘的 IGMP 報文數量；
路由器收到主機的成員關係報告報文後，就會在 IGMP 路由表中加入該組播組，後續網絡中一旦該組播地址的數據到達路由器，它會把數據包轉發出去；

離開組播組工做機制

離開組播組的狀況一，網段中仍有該組播組：

主機 1 要離開組 224.1.1.1，發送 IGMPv2 離組報文，報文的目的地址是 224.0.0.2（表示發向網段內的全部路由器）；
路由器收到該報文後，以 1 秒爲間隔連續發送 IGMP 特定組查詢報文（共計發送 2 個），以便確認該網絡是否還有 224.1.1.1 組的其餘成員；
主機 3 仍然是組 224.1.1.1 的成員，所以它當即響應這個特定組查詢。路由器知道該網絡中仍然存在該組播組的成員，因而繼續向該網絡轉發 224.1.1.1 的組播數據包；

離開組播組的狀況二，網段中沒有該組播組：

主機 1 要離開組播組 224.1.1.1，發送 IGMP 離組報文；
路由器收到該報文後，以 1 秒爲間隔連續發送 IGMP 特定組查詢報文（共計發送 2 個）。此時在該網段內，組 224.1.1.1 已經沒有其餘成員了，所以沒有主機響應這個查詢；
必定時間後，路由器認爲該網段中已經沒有 224.1.1.1 組播組成員了，將不會再向這個網段轉發該組播地址的數據包；

參考文獻

[1] 計算機網絡-自頂向下方法.陳鳴譯.機械工業出版社

[2] TCP/IP詳解卷1：協議.範建華譯.機械工業出版社

[3] 圖解TCP/IP.竹下隆史.人民郵電出版社