大家好，我是風箏

輕解網絡(luo)系列又來了(le)。已有高清 PDF 版本可(ke)以離線閱(yue)讀了(le)，全冊 65 頁，如果有需要離線版的高清 PDF 可(ke)以。

今天(tian)咱們說說 ICMP 協(xie)議。ICMP 可謂(wei)是(shi)網絡世(shi)界中的(de)最強輔助(zhu)了，IP數據(ju)包如果在途中遭(zao)遇不(bu)測(ce)的(de)話，全(quan)靠 ICMP 來通(tong)知，要不(bu)然丟掉的(de)IP數據(ju)包就(jiu)有(you)(you)如石沉大海，從此(ci)杳(yao)無音信，發送方也不(bu)知道這(zhe)個包有(you)(you)沒有(you)(you)傳輸成(cheng)功，倘若(ruo)沒有(you)(you)成(cheng)功，那失(shi)敗原(yuan)因(yin)是(shi)什么？這(zhe)些，全(quan)靠 ICMP 協(xie)議來通(tong)知。

ICMP 全稱互聯網控制報文(wen)協議(yi)（Internet Cntrol Message Protocol），是網絡層的重(zhong)要協議(yi)。

ICMP 是干啥用的

它到底是(shi)用來干啥的(de)(de)呢？為啥叫(jiao)控制報文協(xie)議，控制的(de)(de)是(shi)什么？

ICMP 分為查詢報(bao)(bao)(bao)文和差(cha)錯(cuo)報(bao)(bao)(bao)文兩大類。查詢報(bao)(bao)(bao)文是我們主動(dong)發(fa)起的，比如ping命(ming)令(ling)；而(er)差(cha)錯(cuo)報(bao)(bao)(bao)文是在發(fa)生差(cha)錯(cuo)之后要發(fa)給源端的，這都是互聯網協議模型約定好的。

ICMP的(de)差錯報(bao)文反饋(kui)發生(sheng)在通信環境中的(de)遇(yu)到的(de)各種問(wen)題。通過這(zhe)些(xie)信息，使管理者可(ke)以(yi)對(dui)所發生(sheng)的(de)問(wen)題作(zuo)出診斷，然后采取適當的(de)措施解決。

ICMP的(de)差(cha)(cha)(cha)錯報(bao)文是(shi)(shi)整個(ge)(ge)數(shu)據(ju)傳(chuan)輸鏈(lian)路(lu)中(zhong)非常(chang)重要的(de)一個(ge)(ge)環節。打個(ge)(ge)比喻，差(cha)(cha)(cha)錯報(bao)文就(jiu)是(shi)(shi)一個(ge)(ge)只(zhi)報(bao)告壞消息的(de)信使(shi)，當數(shu)據(ju)包在(zai)網絡中(zhong)一路(lu)暢通的(de)時候，ICMP 差(cha)(cha)(cha)錯報(bao)文就(jiu)像(xiang)隱身(shen)了(le)一樣，你根本不會知道它的(de)存(cun)在(zai)，一旦數(shu)據(ju)包在(zai)網絡中(zhong)碰到(dao)了(le)各種(zhong)(zhong)各樣的(de)障礙，這個(ge)(ge)信使(shi)就(jiu)出來活動了(le)，它的(de)目的(de)只(zhi)有一個(ge)(ge)，就(jiu)是(shi)(shi)把(ba)這個(ge)(ge)數(shu)據(ju)包遭遇的(de)不測(ce)通知給發送端，但是(shi)(shi)話術(shu)就(jiu)那(nei)么(me)20多種(zhong)(zhong)（對應差(cha)(cha)(cha)錯代碼(ma)）。

比如(ru)下面兩個場景，想必你也有點(dian)熟悉吧(ba)。

• 當路由器收到(dao)一(yi)份IP數據報但又不能轉發(fa)時，就要發(fa)送一(yi)份 ICMP「主機不可達」差錯報文。

• 當IP數據(ju)報(bao)應(ying)該(gai)被發送(song)到(dao)另(ling)一個路由(you)器時(shi)，收(shou)到(dao)數據(ju)報(bao)的(de)路由(you)器就要(yao)發送(song) ICMP「重定向」差錯(cuo)報(bao)文(wen)給IP數據(ju)報(bao)的(de)發送(song)端。

ICMP 協議說明

雖然工作在網絡層，看上去和 IP 協議是并列的，但是 ICMP 報文要附加 IP 頭，一般被 IP 層或者更高層的協議（例如TCP或UDP）使用。很少有應用程序直接使用 ICMP 協議，除了 ping、traceroute。

ICMP 協議格式

ICMP 協(xie)(xie)議(yi)格式和 IP 協(xie)(xie)議(yi)、TCP 協(xie)(xie)議(yi)這些(xie)比起來，那還是非常簡單的。

類型

類型字段占用 8 位，主要定義報文的大類，比如類型為 3 統一表示的是不可達，而(er)具體原因是什么則要(yao)由代(dai)碼字段決定。

代碼

代碼(ma)字(zi)段(duan)同樣占用 8 位，代碼(ma)字(zi)段(duan)其(qi)實就是類(lei)(lei)型下(xia)的子類(lei)(lei)型，比如(ru)上(shang)面說(shuo)了類(lei)(lei)型為(wei) 3 是不(bu)可(ke)達，代碼(ma)為(wei) 0 表示(shi)網絡不(bu)可(ke)達，代碼(ma)為(wei) 1 表示(shi)主(zhu)機不(bu)可(ke)達。

檢驗和

用(yong)于錯誤檢(jian)查，和 IP 協(xie)議的(de)檢(jian)驗和的(de)作用(yong)一(yi)致。

內容

因(yin)為(wei)類(lei)型和代碼不(bu)同(tong)，表(biao)示產生差錯的(de)原因(yin)不(bu)同(tong)，不(bu)同(tong)的(de)原因(yin)都要有(you)對應的(de)描述，內容這部分就是用來(lai)描述產生差錯的(de)原因(yin)的(de)。

接(jie)下來(lai)會舉幾個例子說明。

下面這張圖是 ICMP 的分類，包括查詢報文和差錯報文，需要原始 Excel 的同學可以回復 ICMP獲取源文件。

目的不可達差錯報文

目的不(bu)可達是網絡傳(chuan)輸(shu)中(zhong)經常遇到的問(wen)題，各(ge)位(wei)在開發(fa)的過程中(zhong)可能也碰到過，尤其是做網絡編程的時(shi)候，經常會碰到，比(bi)如連錯IP了(le)，比(bi)如端口設置錯了(le)。

通過上表可知，當(dang)類型為 3 的時(shi)候(hou)，都是不可達(da)的錯誤(wu)，而代碼可以從 0 -15，也就(jiu)是說(shuo)有16種(zhong)不可達(da)的具體原因。這(zhe)種(zhong)情況下的協議(yi)格式是下面(mian)這(zhe)樣(yang)的。

類型為(wei) 3 ，代碼 0 - 15。檢驗和后面有 4 個字節的空間是不使(shi)用(yong)的，但是必須(xu)為(wei)0 ，沒理由，就(jiu)這樣。

前面說到了內容部分(fen)是根據類(lei)型和代碼不同(tong)而不同(tong)的(de)。如果是目(mu)的(de)不可達，也就是類(lei)型是 3 的(de)情(qing)況(kuang)下，內容分(fen)為兩(liang)部分(fen)，IP首部和原始IP數(shu)據報中數(shu)據部分(fen)的(de)前 8 個字節。

原始IP數據報中數據部分指(zhi)的(de)(de)就是TCP或者UDP這些網絡層(ceng)之上(shang)的(de)(de)協議，拿 TCP 來說，TCP 是傳輸層(ceng)的(de)(de)，當 TCP 數據(ju)報到達網絡層(ceng)，會加上(shang) IP 首部(bu)，變成一個(ge) IP 數據(ju)包。所(suo)以(yi)這里說的(de)(de)數據(ju)部(bu)分就是 TCP 數據(ju)報，但是這個(ge)數據(ju)報可能(neng)很大，所(suo)以(yi)只用前(qian) 8 個(ge)字(zi)(zi)節就夠了，因為(wei)前(qian)8個(ge)字(zi)(zi)節包含的(de)(de)信(xin)息已經足夠用了。

回想一下 TCP 協議的(de)格式(shi)，前 8 個(ge)字節就是下圖(tu)紅框(kuang)部分，包(bao)含源端口(kou)和目的(de)端口(kou)以及(ji)序號。

例如代(dai)碼(ma)為 3 的(de)時(shi)候，差(cha)錯信(xin)息是端(duan)口(kou)(kou)不可達，那有了 TCP 協議的(de)前8個(ge)(ge)(ge)(ge)字(zi)節就能知(zhi)道(dao)導致這(zhe)個(ge)(ge)(ge)(ge)錯誤的(de)原始數據(ju)(ju)報文中的(de)目(mu)的(de)端(duan)口(kou)(kou)是多(duo)少，不可達的(de)端(duan)口(kou)(kou)也(ye)就是這(zhe)個(ge)(ge)(ge)(ge)端(duan)口(kou)(kou)。也(ye)可以(yi)知(zhi)道(dao)原始報文的(de)源端(duan)口(kou)(kou)是多(duo)少，有了源端(duan)口(kou)(kou)號就知(zhi)道(dao)這(zhe)個(ge)(ge)(ge)(ge)數據(ju)(ju)包是哪個(ge)(ge)(ge)(ge)用戶進(jin)程(cheng)發出來的(de)，就可以(yi)交給這(zhe)個(ge)(ge)(ge)(ge)進(jin)程(cheng)對這(zhe)個(ge)(ge)(ge)(ge)差(cha)錯及(ji)時(shi)進(jin)行處理了。

源(yuan)端(duan)口號是(shi)關聯(lian)用戶進程的(de)重要標示，比如我們開發了(le)(le)一個應(ying)用，這(zhe)個應(ying)用占用了(le)(le) 8888和8898兩個端(duan)口，如果安裝了(le)(le)這(zhe)個應(ying)用的(de)機器收到了(le)(le)一個差錯報文，而(er)差錯報文中的(de)內容部分的(de)原始(shi)數(shu)據包前8個字節拆解后，發現源(yuan)端(duan)口是(shi)8898，那就知(zhi)道這(zhe)個要交給我們開發的(de)這(zhe)個應(ying)用去處(chu)理了(le)(le)。

下面是一個端口(kou)不可達的差(cha)錯報文，用 WireSharek 監測到的格(ge)式。

telnet 一個沒有開(kai)放的(de)端口即可獲得 ICMP 端口不(bu)可達的(de)差(cha)錯報文。

查詢報文

將 ICMP 用(yong)(yong)作(zuo)查詢(xun)報文的場(chang)景比較少，用(yong)(yong)作(zuo)查詢(xun)報文的意思就像是(shi)使(shi)用(yong)(yong) ARP 協(xie)(xie)議或者 TCP 協(xie)(xie)議這種，是(shi)我們主動發起的，只不(bu)過選了 ICMP 協(xie)(xie)議。

比如 ping 和 traceroute這(zhe)兩個，之后我們再講，這(zhe)兩個比較有意思，對 ICMP 應用很巧妙(miao)。

另(ling)外，可(ke)以(yi)用(yong)作(zuo)無(wu)盤系統(tong)啟(qi)動過程中來獲取自(zi)身的(de)子網掩碼。還可(ke)以(yi)用(yong)作(zuo)向第三方(fang)系統(tong)查詢當前的(de)時(shi)間戳。

了解一下就可以了。

有一些場景不發送差錯報文

有(you)些場景下是不發(fa)送(song)差(cha)錯報文的，這樣做(zuo)的目的是為了防止(zhi)ICMP差(cha)錯報文帶來廣(guang)播風暴。

1. ICMP差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)本身(shen)發生差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)，是(shi)不會對差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)再發送差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)的。是(shi)不是(shi)讀起(qi)來有點繞，TCP 、UDP 出(chu)(chu)錯(cuo)(cuo)(cuo)(cuo)會發送差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)，但是(shi) ICMP差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)在(zai)通知源(yuan)端(duan)的過程出(chu)(chu)錯(cuo)(cuo)(cuo)(cuo)了(le)(le)，那(nei)就不管了(le)(le)，要不然可能(neng)就沒(mei)玩沒(mei)了(le)(le)的發了(le)(le)，比如源(yuan)端(duan)的網線斷了(le)(le)。但是(shi)， ICMP查詢報(bao)文(wen)(wen)可能(neng)會產生ICMP差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)，比如ping命令在(zai)傳輸(shu)過程中出(chu)(chu)錯(cuo)(cuo)(cuo)(cuo)了(le)(le)，源(yuan)端(duan)會收到差(cha)(cha)(cha)錯(cuo)(cuo)(cuo)(cuo)報(bao)文(wen)(wen)。

2. 目(mu)的(de)(de)地址(zhi)是廣播地址(zhi)或多播地址(zhi)（D類地址(zhi)）的(de)(de)IP數(shu)據報，不發送差錯(cuo)報文。

3. 作為(wei)鏈路(lu)層(ceng)廣播(bo)的數據(ju)報(bao)，不發送差錯報(bao)文，ARP 就(jiu)是(shi)典(dian)型的鏈路(lu)層(ceng)廣播(bo)數據(ju)報(bao)。

4. 不是IP分片(pian)的(de)第一片(pian)，不發送差錯報文。數據如果(guo)過長(chang)，網(wang)絡層是會進行分片(pian)的(de)，這些分片(pian)實際上還是同一個數據包的(de)，這種(zhong)情(qing)況下只(zhi)對第一片(pian)發送差錯報文，其他分片(pian)不管。

5. 源(yuan)地(di)(di)址(zhi)不是單個主機的(de)數據報(bao)，不發送(song)差錯(cuo)報(bao)文(wen)。 源(yuan)地(di)(di)址(zhi)不能(neng)為零地(di)(di)址(zhi)、環回地(di)(di)址(zhi)、廣播地(di)(di)址(zhi)或多播地(di)(di)址(zhi)。

總結

1、 ICMP 在網絡層，但要加上(shang) IP 首部；

2、ICMP 分為查(cha)詢報(bao)文和差(cha)錯(cuo)報(bao)文，主要用到的還是差(cha)錯(cuo)報(bao)文；

3、ICMP 的(de)差錯(cuo)報文就好像一個只(zhi)通知(zhi)(zhi)壞消息的(de)信息，當數(shu)據(ju)報在網絡中出現(xian)問題的(de)時候，及時告(gao)知(zhi)(zhi)源端(duan)，告(gao)知(zhi)(zhi)的(de)內(nei)容(rong)包括原因以及產生錯(cuo)誤的(de)原始數(shu)據(ju)報的(de)必要部分；

4、有一(yi)些情況是不會發(fa)送 ICMP 差錯報文的(de)，這樣做是為了防止網絡(luo)風暴；

如果覺得還不錯的話，給個推薦吧！

公眾號(hao)「古時的風(feng)箏」，Java 開發者，專(zhuan)注(zhu) Java 及周(zhou)邊生態。堅持原創干(gan)貨輸出，你可選擇現(xian)在(zai)就關(guan)注(zhu)我，或者看看歷(li)史文章再關(guan)注(zhu)也(ye)不遲(chi)。長按二(er)維碼關(guan)注(zhu)，跟我一起(qi)變優秀(xiu)！