前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。
互聯網控制消息協議（英語：Internet?Control?Message?Protocol，縮寫：ICMP）是互聯網協議族的核心協議之一。
它用于TCP/IP網絡中發送控制消息，提供可能發生在通信環境中的各種問題反饋，通過這些信息，使管理者可以對所發生的問題作出診斷，然后采取適當的措施解決。
ICMP?依靠IP來完成它的任務，它是IP的主要部分。它與傳輸協議（如TCP和UDP）顯著不同：它一般不用于在兩點間傳輸數據。它通常不由網絡程序直接使用，除了ping和traceroute這兩個特別的例子。?IPv4中的ICMP被稱作ICMPv4，IPv6中的ICMP則被稱作ICMPv6。
技術細節
ICMP是在RFC 792中定義的互聯網協議族之一。通常用于返回的錯誤信息或分析路由。ICMP錯誤消息總是包括了源數據并返回給發送者。 ICMP錯誤消息的例子之一是TTL值過期。每個路由器在轉發數據報的時候都會把IP包頭中的TTL值減1。如果TTL值為0，“TTL在傳輸中過期”的消息將會回報給源地址。 每個ICMP消息都是直接封裝在一個IP數據包中的，因此，和UDP一樣，ICMP是不可靠的。
雖然ICMP是包含在IP數據包中的，但是對ICMP消息通常會特殊處理，會和一般IP數據包的處理不同，而不是作為IP的一個子協議來處理。在很多時候，需要去查看ICMP消息的內容，然后發送適當的錯誤消息到那個原來產生IP數據包的程序，即那個導致ICMP消息被發送的IP數據包。
很多常用的工具是基于ICMP消息的。traceroute是通過發送包含有特殊的TTL的包，然后接收ICMP超時消息和目標不可達消息來實現的。ping則是用ICMP的"Echo request"（類別代碼：8）和"Echo reply"（類別代碼：0）消息來實現的。
ICMP報文結構
報頭
ICMP報頭從IP報頭的第160位開始（IP首部20字節）（除非使用了IP報頭的可選部分）。
| Bits | 160-167 | 168-175 | 176-183 | 184-191 |
|---|---|---|---|---|
| 160 | Type | Code | 校驗碼（checksum） | |
| 192 | ID | 序號（sequence） | ||
- Type?- ICMP的類型,標識生成的錯誤報文；
- Code?- 進一步劃分ICMP的類型,該字段用來查找產生錯誤的原因.；例如，ICMP的目標不可達類型可以把這個位設為1至15等來表示不同的意思。
- Checksum?- 校驗碼部分,這個字段包含有從ICMP報頭和數據部分計算得來的，用于檢查錯誤的數據，其中此校驗碼字段的值視為0。
- ID?- 這個字段包含了ID值，在Echo Reply類型的消息中要返回這個字段。
- Sequence?- 這個字段包含一個序號，同樣要在Echo Reply類型的消息中要返回這個字段。
?
填充數據
填充的數據緊接在ICMP報頭的后面（以8位為一組）：
- Linux的"ping"工具填充的ICMP除了8個8位組的報頭以外，默認情況下還另外填充數據使得總大小為64字節。
- Windows的"ping.exe"填充的ICMP除了8個8位組的報頭以外，默認情況下還另外填充數據使得總大小為40字節。
?
報文類型
| 類型 | 代碼 | 狀態 | 描述 | 查詢 | 差錯 |
|---|---|---|---|---|---|
| 0 -?Echo Reply | 0 | ? | echo響應 (被程序ping使用） | ● | ? |
| 1 and 2 | ? | 未分配 | 保留 | ? | ● |
| 3 - 目的不可達 | 0 | ? | 目標網絡不可達 | ? | ● |
| 1 | ? | 目標主機不可達 | ? | ● | |
| 2 | ? | 目標協議不可達 | ? | ● | |
| 3 | ? | 目標端口不可達 | ? | ● | |
| 4 | ? | 要求分段并設置DF flag標志 | ? | ● | |
| 5 | ? | 源路由失敗 | ? | ● | |
| 6 | ? | 未知的目標網絡 | ? | ● | |
| 7 | ? | 未知的目標主機 | ? | ● | |
| 8 | ? | 源主機隔離（作廢不用） | ? | ● | |
| 9 | ? | 禁止訪問的網絡 | ? | ● | |
| 10 | ? | 禁止訪問的主機 | ? | ● | |
| 11 | ? | 對特定的TOS 網絡不可達 | ? | ● | |
| 12 | ? | 對特定的TOS 主機不可達 | ? | ● | |
| 13 | ? | 由于過濾 網絡流量被禁止 | ? | ● | |
| 14 | ? | 主機越權 | ? | ● | |
| 15 | ? | 優先權終止生效 | ? | ● | |
| 4 - 源端關閉 | 0 | 棄用 | 源端關閉（擁塞控制） | ? | ● |
| 5 - 重定向 | 0 | ? | 重定向網絡 | ? | ● |
| 1 | ? | 重定向主機 | ? | ● | |
| 2 | ? | 基于TOS 的網絡重定向 | ? | ● | |
| 3 | ? | 基于TOS 的主機重定向 | ? | ● | |
| 6 | ? | 棄用 | 備用主機地址 | ? | ? |
| 7 | ? | 未分配 | 保留 | ? | ? |
| 8 -?請求回顯 | 0 | ? | Echo請求 | ● | ? |
| 9 - 路由器通告 | 0 | ? | 路由通告 | ● | ? |
| 10 - 路由器請求 | 0 | ? | 路由器的發現/選擇/請求 | ● | ? |
| 11 - ICMP 超時 | 0 | ? | TTL 超時 | ? | ● |
| 1 | ? | 分片重組超時 | ? | ● | |
| 12 - 參數問題：錯誤IP頭部 | 0 | ? | IP 報首部參數錯誤 | ? | ● |
| 1 | ? | 丟失必要選項 | ? | ● | |
| 2 | ? | 不支持的長度 | ? | ? | |
| 13 - 時間戳請求 | 0 | ? | 時間戳請求 | ● | ? |
| 14 - 時間戳應答 | 0 | ? | 時間戳應答 | ● | ? |
| 15 - 信息請求 | 0 | 棄用 | 信息請求 | ● | ? |
| 16 - 信息應答 | 0 | 棄用 | 信息應答 | ● | ? |
| 17 - 地址掩碼請求 | 0 | 棄用 | 地址掩碼請求 | ● | ? |
| 18 - 地址掩碼應答 | 0 | 棄用 | 地址掩碼應答 | ● | ? |
| 19 | ? | 保留 | 因安全原因保留 | ? | ? |
| 20 至 29 | ? | 保留 | Reserved?for robustness experiment | ? | ? |
| 30 - Traceroute | 0 | 棄用 | 信息請求 | ? | ? |
| 31 | ? | 棄用 | 數據報轉換出錯 | ? | ? |
| 32 | ? | 棄用 | 手機網絡重定向 | ? | ? |
| 33 | ? | 棄用 | Where-Are-You（originally meant for?IPv6） | ? | ? |
| 34 | ? | 棄用 | Here-I-Am（originally meant for IPv6） | ? | ? |
| 35 | ? | 棄用 | Mobile Registration Request | ? | ? |
| 36 | ? | 棄用 | Mobile Registration Reply | ? | ? |
| 37 | ? | 棄用 | Domain Name Request | ? | ? |
| 38 | ? | 棄用 | Domain Name Reply | ? | ? |
| 39 | ? | 棄用 | SKIP Algorithm Discovery Protocol,?Simple Key-Management for Internet Protocol | ? | ? |
| 40 | ? | ? | Photuris, Security failures | ? | ? |
| 41 | ? | 實驗性的 | ICMP for experimental mobility protocols such as?Seamoby?[RFC4065] | ? | ? |
| 42 到 255 | ? | 保留 | 保留 | ? | ? |
| 235 | ? | 實驗性的 | RFC3692（?RFC 4727） | ? | ? |
| 254 | ? | 實驗性的 | RFC3692（?RFC 4727） | ? | ? |
| 255 | ? | 保留 | 保留 |
?
?
?
特別說明：以上內容大部分收集、整理自**百科。
?
 是什么)
