ICMP 協議用於在IP 主機、路由器之間傳遞控制消息，這里的控制消息可以包括很多種，例如數據報錯誤信息、網絡狀況信息、主機狀況信息等，這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據報的有效遞交起着重要作用。從 TCP/IP 的分層結構上看，ICMP 屬於網絡，它配合 IP 協議完成數據報的遞交，提高數據報遞交的有效性，但是 ICMP 協議報文有着自己的組織結構，且 ICMP 報文是被封裝在 IP 數據報中發送的。本章將包括以下基本內容：
ICMP 概念與 ICMP 報文的交付；
ICMP 報文的分類及其報文格式；
源代碼中實現 ICMP 協議的數據結構和函數；
ping 命令與 ICMP 洪水。
一、基礎知識
1、ICMP協議
IP 協議本身不提供差錯報告和差錯控制機制來保證數據報遞交的有效性，在路由器無法遞交一個數據報，或者數據報生存時間為 0 時，路由器都會直接丟棄掉這個數據報。盡管路由器 IP 層認為這樣的處理是合理的（可以提高數據報處理效率），但是在很多情況下，源主機還是期望在數據報遞交出現異常的情況下得到相關的失敗信息，以便進行重傳或者其他處理。
另一方面，IP 協議缺少一個輔助機制，即主機的管理和查詢機制。在某些情況下，源主機需要確定另一個主機或者路由器是否是活躍的，對於不活躍的主機，就沒有必要再向它發送數據報了，因為這是徒勞的。在另外一些情況下，一個主機的管理員期望能獲得另一個主機或者路由器上的信息，以根據這些信息進行主機自身的配置、數據報發送控制等。
為了解決上述兩個問題，設計人員給 TCP/IP 協議引進了一種具有特殊用途的報文機制，稱為網際報文控制協議（Internet Control Message Protocol，簡稱 ICMP），ICMP 協議是支持 IP 協議的重要機制，從 TCP/IP 的分層結構上來看，它同 IP 協議一樣，處於網絡層，但 ICMP 協議有自己的一套報文格式，且它需要使用 IP 協議來遞交報文，即 ICMP 報文是放在 IP 數據報中的數據區域發送的 。總之，ICMP 協議是支持 IP 協議實現的不可或缺的機制，每一種 TCP/IP 協議的實現都應該支持它。
2、報文交付
ICMP 使用 IP 進行交互，是因為一個報文可能要經過幾個物理網絡才能到達其最終目的地，因此它不可能單獨通過某個物理傳輸進行交付，必須使用 IP 提供的交付服務，屏蔽掉各種底層物理結構的差異。由於 IP 數據報本身被放在物理數據幀中進行發送，因此，ICMP 報文本身也可能丟失或者出現傳輸錯誤。
3、報文類型
從功能上划分，ICMP 報文可以分為兩大類：ICMP 差錯報告報文和 ICMP 查詢報文，分別用於解決上面說到的兩個問題。差錯報告報文主要用來向 IP 數據報源主機返回一個差錯報告信息， 這個錯誤報告信息產生的原因是路由器或主機不能對當前數據報進行正常的處理，例如無法將數據報遞交給有效的協議上層，又例如數據報因為生存時間 TTL 為 0 而被刪除等。
查詢報文用於一台主機向另一台主機查詢特定的信息，通常查詢報文都是成對出現的，即源主機發起一個查詢報文，在目的主機收到該報文后，會按照查詢報文約定的格式為源主機返回一個應答報文。兩大種類的 ICMP 報文及其常見類型如表 11-1 所示。
4、報文格式
5、差錯校驗
在表 111 中所示的 5 種差錯報文類型中，LwIP 協議棧能夠根據數據報的處理異常情況發送目的站不可達報文和數據報超時報文；另一方面，當協議棧收到任何類型的差錯報告報文時，會直接將報文丟棄，不做任何處理。因此，本小節重點講解目的站不可達報文和數據報超時報文。 目的站不可達
當路由器不能給數據報找到合適的路由路徑，或者主機不能將數據報遞交給上層協議時，相應的 IP 數據報就會被丟棄，然后一個目的站不可達差錯控制報文將會被返回給源主機。目的站不可達差錯可以由很多因素引起，例如網絡不可達、主機不可達、協議不可達、端口不可達等，可以在報文首部中的代碼字段指出具體原因。
在第 10 章的講解中，已經看到了 ICMP 目的站不可達差錯報文的身影：IP 層數據報處理函數 ip_input 通過首部中的協議字段值來判斷數據報應該遞交給哪個上層協議處理，例如，若是 UDP 協議，則調用 udp_input 函數處理；若是 ICMP 協議，則調用 icmp_input 函數處理；如果沒有任何協議能接受這個數據報，則調用 icmp_dest_unreach 函數發送一個目的（協議）不可達 ICMP 差錯報文給源主機。目的站不可達報文具體格式如圖 113所示。
為什么還需要裝載引起差錯的數據報數據區的前 8 個字節呢？因為這 8 個字節恰好覆蓋了 TCP 報文或UDP 報文中的端口號字段，IP 層能夠根據這個端口號把 ICMP 報文傳遞給具體的上層處理。
數據報超時
數據報超時可以用來防止數據報在網絡中被循環的路由，在 IP 首部中都有一個生存時間計數器（TTL），數據報每被轉發一次，TTL 的值便會減 1，當 TTL 的值被減為 0 時，數據報會被網絡丟棄，同時一個 ICMP 超時報文會被返回給源主機。 事實上，在講解 IP 層的數據報處理時，也已經見到過了 ICMP 超時報文的身影。在數據報轉發函數 ip_forward 中，需要將數據報首部中的 TTL值減 1，若此時 TTL 值變為 0，則該數據報被丟棄，同時調用函數 icmp_time_exceeded 向源主機返回一份 ICMP 超時報文；此外，在分片重裝的周期性處理函數中，也用到了 ICMP 超時報文，若某個數據報在重裝過程中，由於其重裝時間超時，而數據分片還沒有全部到達，此時與該數據報所有相關的分片將被刪除，同時，一個 ICMP 超時報文將被返回給源主機。數據報超時報文結構如圖114 所示，從圖中可以看出，它與目的站不可達報文的結構完全相同。
6、查詢報文
這里將重點講解的，也是 LwIP 中唯一實現的一種查詢報文：回送請求或回答報文。LwIP 協議棧能接收外部主機的回送請求報文，並根據報文返回一個 ICMP 回答報文。主機或路由器指明某個目的主機發送 ICMP 回送請求報文，任何收到回送請求的目的主機都會生成一個回送回答報文，並返回給源主機。回收請求和回送回答報文可以直接確定兩台主機的 IP 協議是否能夠正常通信。
事實上，在前面的章節中已經見到過回送請求和回答的身影，在協議棧移植時，我們在 Windows控制台上使用 ping 命令來測試開發板上的協議棧是否移植成功，其本質上就是向開發板發送一個ICMP 回送請求報文；開發板上的協議棧收到這樣的報文后，會產生一個回答報文並返還給主機；當 Windows 主機正確地接收到這個回答報文時，說明我們的移植成功了，開發板協議棧成功運行了起來。回送請求和回答的報文格式如圖 115 所示。
類型字段指出了是請求報文（8）還是回答報文（0）；
代碼段無特殊取值，始終為 0；
首部中的標識符和序號兩個字段在 ICMP 協議中沒有正式定義其取值規范，因此發送方可以自由使用這兩個字段，例如可以用序號來記錄源主機發送出去的回送請求報文編號。
可選數據區域表示回送請求報文中可包含的數據，其長度是可選的，發送方應該選擇合適的長度並填充相應的數據。在接收方，它將根據這個回送請求產生一個回送回答，回送回答中的數據與回送請求中的數據應該完全相同。
二、ICMP的實現
1、數據結構
源文件中的 icmp.h 和 icmp.c 實現了與 ICMP 協議相關的數據結構和函數。先看看相關的數據結構的定義：
————icmp.h———————————————— //首先是宏定義，定義常見的 ICMP 報文類型，如表 11-1 所示 #define ICMP_ER 0 //回送回答 #define ICMP_DUR 3 //目的站不可達 #define ICMP_SQ 4 //源站抑制 #define ICMP_RD 5 //重定向（改變路由） #define ICMP_ECHO 8 //回送請求 #define ICMP_TE 11 //數據報超時 #define ICMP_PP 12 //數據報參數錯誤 #define ICMP_TS 13 //時間戳請求 #define ICMP_TSR 14 //時間戳回答 #define ICMP_IRQ 15 //信息請求 #define ICMP_IR 16 //信息回答 //枚舉類型，定義目的站不可達報文中的代碼字段常用取值，如表 11-2 所示 enum icmp_dur_type { ICMP_DUR_NET = 0, //網絡不可達 ICMP_DUR_HOST = 1, //主機不可達 ICMP_DUR_PROTO = 2, //協議不可達 ICMP_DUR_PORT = 3, //端口不可達 ICMP_DUR_FRAG = 4, //需要分片但不分片位置位 ICMP_DUR_SR = 5 //源路由失敗 }; //枚舉類型，定義數據報超時報文中的代碼字段取值，如表 113 所示 enum icmp_te_type { ICMP_TE_TTL = 0, //生存時間計數器超時 ICMP_TE_FRAG = 1 //分片重裝超時 }; //定義 ICMP 回送請求報文首部結構，由於所有類型 ICMP 報文首部都有很大的相似性， //所以這個結構也可以用於其他類型的 ICMP 報文 PACK_STRUCT_BEGIN struct icmp_echo_hdr { //參見圖 115 PACK_STRUCT_FIELD(u8_t type); //類型 PACK_STRUCT_FIELD(u8_t code); //代碼 PACK_STRUCT_FIELD(u16_t chksum); //校驗和 PACK_STRUCT_FIELD(u16_t id); //標識符 PACK_STRUCT_FIELD(u16_t seqno); //序號 } PACK_STRUCT_STRUCT; PACK_STRUCT_END //定義兩個宏，用於讀取 ICMP 首部中的字段 #define ICMPH_TYPE(hdr) ((hdr)>type) #define ICMPH_CODE(hdr) ((hdr)>code) //定義兩個宏，用於向 ICMP 首部字段中寫入相應值 #define ICMPH_TYPE_SET(hdr, t) ((hdr)>type = (t)) #define ICMPH_CODE_SET(hdr, c) ((hdr)>code = (c)) ——————————————————————————————
上面這些宏以及數據結構的定義很簡單，只有一個需要特別指出的地方。對於不同類型的報文，雖然它們各自的結構存在一定的差異性，但是首部的差異還是很小的，特別是首部的前 4 個字節在所有類型的報文中都一樣。源代碼中只定義了 ICMP 回送請求報文首部結構，但是這個結構也可以拿來描述其他類型的首部。
2、發送差錯報文
在數據報不能遞交給任何一個上層協議時，函數 icmp_dest_unreach 會被調用，以發送一個目的不可達 ICMP 差錯報文給源主機，引起目的不可達的具體原因是協議不可達；
另一種差錯報文是超時報文，發送超時報文的函數叫做 icmp_time_exceeded，在數據報轉發和分片重裝的過程中，都可能調用該函數，引發超時的具有原因可能有兩種：一是數據報 TTL 為 0；二是分片重裝時間超時。
這里，來看看上述兩種差錯報文是怎么樣被發送的。
————icmp.c———————————————————— //定義宏，引起差錯的 IP 數據報數據區將被差錯報文裝載的長度 #define ICMP_DEST_UNREACH_DATASIZE 8 //函數功能：發送一個目的地址不可達差錯報文 //參數 p：引起差錯的 IP 數據報 pbuf 指針 //參數 t：目的不可達的原因（報文的代碼字段） void icmp_dest_unreach(struct pbuf *p, enum icmp_dur_type t) { icmp_send_response(p, ICMP_DUR, t); //調用函數發送一個 ICMP_DUR 類型的差錯報文 } //函數功能：發送一個數據報超時差錯報文 //參數 p：引起超時的 IP 數據報 pbuf 指針 //參數 t：超時的原因（報文的代碼字段） void icmp_time_exceeded(struct pbuf *p, enum icmp_te_type t) { icmp_send_response(p, ICMP_TE, t); //調用函數發送一個 ICMP_TE 類型的差錯報文 } //函數功能：發送一個 ICMP 差錯報文 //參數 p：引起差錯的 IP 數據報 pbuf 指針 //參數 type：差錯報文的具體類型 //參數 code：差錯報文的代碼字段 static void icmp_send_response(struct pbuf *p, u8_t type, u8_t code) { struct pbuf *q; struct ip_hdr *iphdr; //這里，用一個回送請求報文首部來描述差錯報文的首部 struct icmp_echo_hdr *icmphdr; //為差錯報文申請 pbuf 空間，pbuf 中預留 IP 首部和以太網首部空間，pbuf 的數據區 //長度為差錯報文首部長度+差錯報文數據長度（IP 首部長度+8） q = pbuf_alloc(PBUF_IP,sizeof(struct icmp_echo_hdr) + IP_HLEN + ICMP_DEST_UNREACH_DATASIZE,PBUF_RAM); if (q == NULL) { //申請失敗，則直接返回 return; } iphdr = p>payload; //指向引起差錯的 IP 數據報首部 icmphdr = q>payload; //指向差錯報文首部 icmphdr>type = type; //填寫類型字段 icmphdr>code = code; //填寫代碼字段 icmphdr>id = 0; //對於目的不可達和數據報超時 icmphdr>seqno = 0; //報文，首部剩余的 4 個字節都為 0 //將引起差錯的 IP 數據報的 IP 首部+8 字節數據拷貝到差錯報文的數據區域 SMEMCPY((u8_t *)q>payload + sizeof(struct icmp_echo_hdr), (u8_t *)p>payload,IP_HLEN + ICMP_DEST_UNREACH_DATASIZE); icmphdr>chksum = 0; //將報文中的校驗和字段清 0 icmphdr>chksum = inet_chksum(icmphdr, q>len); //計算並填寫校驗和 //調用 IP 層函數輸出 ICMP 報文 ip_output(q, NULL, &(iphdr>src), ICMP_TTL, 0, IP_PROTO_ICMP); pbuf_free(q); //釋放報文占用的 pbuf } ————————————————————————————————————
這里的重點在於函數 icmp_send_response，它為報文申請空間，然后根據報文類型和代碼字段值填寫數據，然后計算校驗和，最后發送，一切都是如此的簡單自然，一氣呵成，不多說了！
3、ICMP報文的處理
IP 層收到 ICMP 報文，會調用 icmp_input 函數處理，該函數根據報文的不同類型做出不同處理。目前 LwIP 只支持 ICMP 回送請求報文的處理，而對其他類型的 ICMP 報文直接丟棄，不做任何響應，這在嵌入式產品中足夠用了。對於 ICMP 回送請求，icmp_input 需要生成一個回送回答報文並返回給源主機。
//函數功能：處理協議棧收到的 ICMP 報文，在 ip_input 中被調用 //參數 p：收到的 ICMP 報文 pbuf，pbuf 的 payload 指向裝載該報文的 IP 數據報首部 //參數 inp：接收到 ICMP 報文的網絡接口結構 void icmp_input(struct pbuf *p, struct netif *inp) { u8_t type; struct icmp_echo_hdr *iecho; struct ip_hdr *iphdr; struct ip_addr tmpaddr; //IP 地址結構 s16_t hlen; iphdr = p->payload; //指向 IP 數據報首部 hlen = IPH_HL(iphdr) * 4; //計算 IP 首部長度 //調整 pbuf 的 payload 指針，使其指向 ICMP 報文首部，若調整失敗，或者 ICMP 報文 //首部太小（小於 4 字節），直接跳到 lenerr 處執行返回操作 if (pbuf_header(p, -hlen) || (p->tot_len < sizeof(u16_t)*2)) { goto lenerr; } type = *((u8_t *)p->payload); //獲得 ICMP 首部中的類型字段值 switch (type) { //根據不同類型做出不同處理 case ICMP_ECHO: //若是回送請求，則做如下處理 {//首先檢查報文的目的地址是否合法 int accepted = 1; //局部標志量，標志是否對 ICMP 回送請求進行回應 if (ip_addr_ismulticast(&iphdr->dest)) { //如果目的地址為多播地址，不回應 accepted = 0; } if (ip_addr_isbroadcast(&iphdr->dest, inp)) {//目的地址為廣播地址，不回應 accepted = 0; } if (!accepted) { //如果不回應標志有效 pbuf_free(p); //則釋放接收到的報文 return; //直接返回 } } //再檢查報文長度是否合法 if (p->tot_len < sizeof(struct icmp_echo_hdr)) {//如果報文長度比 ICMP 首部還小 goto lenerr; //不合法，跳到 lenerr 處執行返回操作 } //再判斷校驗和是否正確 if (inet_chksum_pbuf(p) != 0) { //校驗和不正確 pbuf_free(p); //則釋放接收到的報文 return; //直接返回 } //到這里，所有的校驗工作都通過了，我們直接調整回送請求報文中的相關字段， //生成回送回答報文：交換數據報中的源 IP 地址與目的 IP 地址，填寫報文類型 //字段，重新計算 ICMP 報文校驗和。 iecho = p->payload; //指向請求報文首部 tmpaddr.addr = iphdr->src.addr; //將數據報中的源 IP 地址進行暫存 iphdr->src.addr = iphdr->dest.addr; //填寫數據報中的源 IP 地址 iphdr->dest.addr = tmpaddr.addr; //填寫數據報中的目的 IP 地址 ICMPH_TYPE_SET(iecho, ICMP_ER); //填寫報文類型為回送回答（0） //重新填寫報文的校驗和字段，這里的計算方法比較特殊，因為回送回答相對於 //回送請求來說，只有報文首部類型值改變了，只適當調整原來的校驗和即可 if (iecho->chksum >= htons(0xffff - (ICMP_ECHO << 8))) {//分兩種情況調整校 iecho->chksum += htons(ICMP_ECHO << 8) + 1;//驗和，見后續講解 } else { iecho->chksum += htons(ICMP_ECHO << 8); } IPH_TTL_SET(iphdr, ICMP_TTL); //設置 IP 數據報中的 TTL 字段 IPH_CHKSUM_SET(iphdr, 0); //IP 首部校驗和清 0 IPH_CHKSUM_SET(iphdr, inet_chksum(iphdr, IP_HLEN)); //計算並填寫首部檢驗和 //在將報文遞交給 IP 層發送前，需要先將 pbuf 的 payload 指針指向 IP 首部 if(pbuf_header(p, hlen)) { //調整 payload 指針，失敗該函數返回 1 LWIP_ASSERT("Can't move over header in packet", 0); //打印相關信息 } else { //調整指針成功，則執行發送工作 err_t ret; //調用 ip_output_if 直接發送，並設置 IP_HDRINCL，表示 ret = ip_output_if(p, &(iphdr->src), IP_HDRINCL, //IP 首部已被組裝好 ICMP_TTL, 0, IP_PROTO_ICMP, inp); } break; // case ICMP_ECHO default: //對於其他類型的 ICMP 報文，不做任何處理，刪除后直接返回 pbuf_free(p); return; }//switch lenerr: //報文校驗錯誤，跳到這里執行並返回 pbuf_free(p); return; }
來看看 icmp_input 函數做了哪些工作。
首先是一系列的校驗工作，將傳進來的數據報 pbuf 的 payload 指針調整為指向 ICMP 首部，並判斷 ICMP 頭部長度是否小於 4 個字節，若是，則說明是個錯誤的 ICMP 數據包，該包被丟棄。對於正確的 ICMP 包，函數根據其頭部類型字段的值判斷該做什么樣的處理。對於 ICMP 回送請求報文，需判斷該報文的目的地址是否合法，對目的地址為多播地址和廣播地址的請求報文，不做處理；接下來判斷該報文大小是否小於 ICMP 回送請求首部長度，是則丟棄報文。
當所有校驗工作成功后，就可以根據這個請求報文產生一個回答報文了，回答報文不用重新去開辟一個新的內存空間，直接重復利用請求報文的空間即可，它們二者之間只有報文的類型字段有差異。過程很簡單，利用請求報文的 pbuf 空間，將該 ICMP 報文類型字段變為 0，重新計算校驗和，最后將 IP 首部中的源 IP 地址和目的 IP 地址交換位置，這樣就生成了回送回答報文。
最后使用 ip_output_if 函數將整個報文發送出去。ICMP 回送回答將回送請求報文中的數據原樣返回給源主機，ip_output_if 函數調用時，設置了 HDRINCL 標志，表示這個 pbuf 中已經包含了組裝好的 IP 首部，這樣函數就不用再填充 IP 首部了。源主機在收到這份回送回答報文后，通過處理回送回答報文，可以計算出往返時間、路由跳數等參數。
最后，整個代碼中還有一個值得重點講解的，就是 ICMP 回答報文中的校驗和計算。這里 ICMP回答報文校驗和的計算有一個很大的技巧，它並不是直接調用函數將所有的數據進行重新求和，而
是用了一個簡單的算式來調整首部中的校驗和字段 。
4、ping命令
“ping”這個名字源於聲納定位操作，目的是為了測試另一台主機是否可達。ping 程序的本質就是發送一份 ICMP 回送請求報文給目的主機，並等待返回 ICMP 回送回答，因此，整個過程讀者一定應該清楚了。
一般來說，如果不能 ping 到某台主機，那么就不能 Telnet 或者 FTP 到那台主機，反過來，如果不能 Telnet 到某台主機，那么通常可以用 ping 程序來確定問題出在哪里。ping 程序還能測出數據報到目的主機的往返時間，以表明目的主機離我們有“多遠”，此外 ping 程序還可以在數據報的路由過程中記錄下路由路徑（利用 IP 首部中的選項字段）。
如圖 116 所示，它顯示了 Windows 下 ping 命令的格式。在前面移植協議棧的過程中，我們曾用過它來測試開發板是否通信良好
ping 命令的各個選項在上圖中有了清晰的說明，來說說幾個比較重要的選項。首先是t，若在ping 命令中使用該選項，則 ping 程序會周期性、不間斷地向目的主機發送 ping 包；n 則可以指出我們需要發送的 ping 包的數目，若未指定這個值，則默認的數目為 4；l 表示每個 ping 包中攜帶的數據長度，在最前面的實驗中可以看到，這個默認長度為 32；剩下的幾個選項是針對 IP 數據報首部的，例如i，指出該數據報的最大轉發次數等。
這里，可以用下面這條語句來 ping 我們的開發板：
ping n 8 l 4000 192.168.1.37
它表示向開發板發送 8 個 ping 數據包，每個數據包攜帶的數據長度為 4000 字節。相應的 ping測試結果如圖 117 所示。對於如此大的一個數據報，在 IP 層必然產生分片和重裝操作。圖中測試出的往返時間很長，一方面是因為分片的重裝，而另一方面是因為筆者測試時打印輸出各種調試信息的緣故。
5、ICMP洪水
如果在 ping 開發板時，再加大 ping 數據包的大小，如圖 118 所示，則測試結果也在圖中有了顯示，我們的板子 ping 不通了，這是什么原因呢？因為在協議棧內部，為數據報接收而預留的空 間並不能放下如此大的一個 ICMP 數據報文，或者如此大的一個報文在分片重裝過程中，超出了重裝條件的限制（如 LwIP 中的 pbuf 使用個數限制），因此，協議棧會直接將報文丟棄，不做任何回應，這導致了主機一直接收不到 ICMP 回送回答。
上面這個測試描述出了目前普遍存在的一種網絡攻擊——ICMP 洪水攻擊的雛形。其原理可以看成是網絡黑客利用他能控制的多台中間人計算機（傀儡主機，或者更專業點，稱之為肉機）一起向目標機器發送大量看似合法的 ICMP 回送請求數據包，造成目標機器網絡阻塞或服務器資源耗盡而導致拒絕服務產生，而另一方面，合法的網絡數據報被虛假的數據報淹沒而無法在網絡中被轉發，合法的用戶不能正常使用網絡。當很多機器長時間、連續、大量地發送 ICMP 請求數據包給某個受攻擊主機時，會最終導致目標主機耗費大量的 CPU 資源處理和內存資源，從而出現死機等情況，無法對正常用戶提供網絡服務。
對於 ICMP 洪水攻擊，可以采取兩種方法進行防范：第一種方法是在路由器上對 ICMP 數據包進行帶寬限制，將 ICMP 占用的帶寬控制在一定的范圍內，這樣即使有 ICMP 攻擊，它所占用的帶寬也是非常有限的，對整個網絡的影響將會非常少；第二種方法就是在主機上設置 ICMP 數據包的處理規則，如果允許，可以拒絕向所有的 ICMP 數據包服務 。