Internet控制報文協議(Intemet Control Message Protocol, ICMP）是IP協議的一種補充，它與IP協議結合使用，以便提供與IP協議層配置和IP數據包處理相關的診斷和控制信息（IP協議本身並沒有爲終端系統提供直接的方法來發現那些發往目的地址失敗的IP數據包，也沒有提供直接的方式來獲取診斷信息。）
ICMP通常被認爲是IP層的一部分,它需要在所有IP實現中存在。它使用IP協議進行傳輸。因此,確切地說,它既不是一個網絡層協議,也不是一個傳輸層協議,而是位於兩者之間。（這一點和大多數CSDN博主的不太一樣，但我看TCP/IP協議上是這樣寫的，我決定按照書上的來）
文章目錄
1. ICMP報文是在IP數據報內被封裝傳輸的。
ICMP報文是在IP數據報內被封裝傳輸的。
1.1 先回顧一下IPv4頭部結構和IPv6頭部結構，方便演示如何封裝ICMP報文
IPv4頭部結構和IPv6頭部結構的具體分析，可以看我的文章：《IPv4和IPv6的數據報結構頭部詳解》，網址：https://blog.csdn.net/qq_45877524/article/details/105003498
這裏只標註與該文章相關的內容。（我直接拿了舊的圖片）
在IPv4中,協議(Protocol)字段值爲1表示該報文攜帶了ICMPv4。 在IPv6中,ICMPv6報文可能開始於0個或者多個擴展頭部之後。位於ICMPv6頭部之前的最後一個擴展頭部包含了一個值爲58的下一個頭部(Next Header)字段。
1.2 如何封裝
- 類型：佔8位，標識ICMP報文的類型，從類型值來看ICMP報文可以分爲兩大類。第一類是取值爲1~127的差錯報文，第2類是取值128以上的信息報文。
- 代碼：佔8位，標識對應ICMP報文的代碼。作爲類型的補充說明，它與類型字段一起描述了ICMP報文的詳細類型
- 校驗和：佔16位，對包括ICMP報文數據部分在內的整個ICMP數據報的校驗和，檢驗報文在傳輸過程中是否出現了差錯，與IP數據報檢驗和的方式一樣。
2. ICMP報文
ICMP報文可分爲兩大類:有關IP數據報傳遞的ICMP報文(稱爲差錯報文(error message)),以及有關信息採集和配置的ICMP報文(稱爲查詢(query)或者信息類報文(informational message) )。
2.1 ICMPv4報文
ICMPv4雖然此報文定義了16個不同的代碼,但其中只有4個是最常用的。這包括主機不可達(代碼1)、端口不可達(代碼3)、需要分片/指定不用分片(代碼4)、管理禁止通信(代碼13)。
2.2 ICMPv6報文
注意ICMPv6負責的不僅是差錯和信息類報文,也負責大量的IPv6路由器和主機的配置。
有ICMPv6的差錯報文的類型(Type)字段的高位比特爲0。因此, ICMPv6類型從0到127的都是差錯報文,類型從128到255的都是信息類報文。設計ICMPv6時的一些努力是爲了從原始的規範中去除未使用的報文,同時保留有用的報文。遵循這個方法, ICMPv6也使用代碼(Code)字段,主要是爲了完善某些差錯報文的含義。
3. ICMP差錯報文的響應規則
ICMP差錯報文不會對以下報文進行響應:另一個ICMP差錯報文,頭部損壞的數據報, IP層的廣播/組播數據報,封裝在鏈路層廣播或者組播幀中的數據報,無效或者網絡爲零的源地址的數據報,或除第一個之外的其他分片。限制生成ICMP差錯報文的原因是限制生成所謂的廣播風暴,在這種情況下生成少數的報文就會造成不想要的流量噴流。
控制產生ICMP報文條件的規則：
- 以下情況不會響應產生ICMPv4差錯報文：
- ICMPv4差錯報文文(但是,響應ICMPv4查詢報文可能會產生ICMPv4差錯報文)。
- 作爲鏈路層廣播的數據報。
- 目的地址是IPv4廣播地址或IPv4組播地址(以前稱爲D類地址)的數據報。
- 不是第一個分片的其他分片。
- 源地址不是單個主機的數據報。這就是說,源地址不能爲零地址、環回地址、廣播地址或組播地址。
- 以下情況不會響應ICMPv6差錯報文（其實兩個都差不多）：
- ICMPv6差錯報文。
- ICMPv6重定向報文。
- 目的地址是IPv6組播地址的數據包,以下情況除外:數據包太大(PTB)的報文;參數問題報文(代碼2)。
- 作爲鏈路層組播(以及前面提到的例外情況)的數據包。
- 作爲鏈路層廣播(以及前面提到的例外情況)的數據包。
- 源地址不是唯一識別的單個節點的數據包。這意味着,源地址不能是未指定的地址、IPv6組播地址,或者任意爲發送者所知的選播地址。
這裏面反覆提及的組播與廣播，可以看這篇文章：CSDN博主z502521809的《廣播、組播、點播的區別》，網址：https://blog.csdn.net/z502521809/article/details/53007932?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-4&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-4
限制ICMP報文速率的方法是使用令牌桶（token bucket），bucket)。採用令牌桶後,每個“桶”保存了最大數量(B)的“令牌”,每個“令牌”允許一定數量的報文被髮送。桶定期被新的令牌(速率爲Ⅳ)填充,並且每發送一個報文便減1。
4. ICMP差錯報文的應用——traceroute
打印出可執行程序主機，一直到目標主機之前經歷多少路由器。
具體詳情可以看：CSDN博主LLQ_200的《traceroute命令講解》，網址：https://blog.csdn.net/llq_200/article/details/81034345
5. ICMP查詢/信息類報文的應用——ping請求
儘管ICMP定義了一定數量的查詢報文,例如地址掩碼請求/應答(類型17/18)、時間戳請求/應答(類型13/14)、信息請求/應答(類型15/16),但是這些功能已經被其他特殊目的的協議替代。唯一保存下來的廣泛使用的ICMP查詢/信息類報文是回顯請求/應答報文,通常稱爲ping,以及路由器發現報文。
ping命令的功能
（1）能驗證網絡的連通性
（2）會統計響應時間和TTL(IP包中的Time To Live，生存週期)
那麼如何驗證的呢？
（1）ping命令會先發送一個 ICMP Echo Request給對端
（2）對端接收到之後, 會返回一個ICMP Echo Reply
（3）若沒有返回，就是超時了，會認爲指定的網絡地址不存在。
6. 參考資料：
- CSDN博主china_jeffery的《網絡協議 – ICMP協議（1） 報文格式》，網址：https://blog.csdn.net/china_jeffery/article/details/79045630?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2
- CSDN博主冀博的《ICMP報文分析》，網址”https://blog.csdn.net/baidu_37964071/article/details/80514340?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-14&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-14
- CSDN博主z502521809的《廣播、組播、點播的區別》，網址：https://blog.csdn.net/z502521809/article/details/53007932?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-4&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-4
- CSDN博主LLQ_200的《traceroute命令講解》，網址：https://blog.csdn.net/llq_200/article/details/81034345
- 我自己的博客《IPv4和IPv6的數據報結構頭部詳解》，網址：https://blog.csdn.net/qq_45877524/article/details/105003498
- TCP/IP協議詳解：卷一 P248-P306