前些天發(fā)現(xiàn)了一個巨牛的人工智能學習網(wǎng)站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉(zhuǎn)到教程。

互聯(lián)網(wǎng)控制消息協(xié)議（英語：Internet?Control?Message?Protocol，縮寫：ICMP）是互聯(lián)網(wǎng)協(xié)議族的核心協(xié)議之一。

它用于TCP/IP網(wǎng)絡中發(fā)送控制消息，提供可能發(fā)生在通信環(huán)境中的各種問題反饋，通過這些信息，使管理者可以對所發(fā)生的問題作出診斷，然后采取適當?shù)拇胧┙鉀Q。

ICMP?依靠IP來完成它的任務，它是IP的主要部分。它與傳輸協(xié)議（如TCP和UDP）顯著不同：它一般不用于在兩點間傳輸數(shù)據(jù)。它通常不由網(wǎng)絡程序直接使用，除了ping和traceroute這兩個特別的例子。?IPv4中的ICMP被稱作ICMPv4，IPv6中的ICMP則被稱作ICMPv6。

技術(shù)細節(jié)

ICMP是在RFC 792中定義的互聯(lián)網(wǎng)協(xié)議族之一。通常用于返回的錯誤信息或分析路由。ICMP錯誤消息總是包括了源數(shù)據(jù)并返回給發(fā)送者。 ICMP錯誤消息的例子之一是TTL值過期。每個路由器在轉(zhuǎn)發(fā)數(shù)據(jù)報的時候都會把IP包頭中的TTL值減1。如果TTL值為0，“TTL在傳輸中過期”的消息將會回報給源地址。 每個ICMP消息都是直接封裝在一個IP數(shù)據(jù)包中的，因此，和UDP一樣，ICMP是不可靠的。

雖然ICMP是包含在IP數(shù)據(jù)包中的，但是對ICMP消息通常會特殊處理，會和一般IP數(shù)據(jù)包的處理不同，而不是作為IP的一個子協(xié)議來處理。在很多時候，需要去查看ICMP消息的內(nèi)容，然后發(fā)送適當?shù)腻e誤消息到那個原來產(chǎn)生IP數(shù)據(jù)包的程序，即那個導致ICMP消息被發(fā)送的IP數(shù)據(jù)包。

很多常用的工具是基于ICMP消息的。traceroute是通過發(fā)送包含有特殊的TTL的包，然后接收ICMP超時消息和目標不可達消息來實現(xiàn)的。ping則是用ICMP的"Echo request"（類別代碼：8）和"Echo reply"（類別代碼：0）消息來實現(xiàn)的。

ICMP報文結(jié)構(gòu)

報頭

ICMP報頭從IP報頭的第160位開始（IP首部20字節(jié)）（除非使用了IP報頭的可選部分）。

Bits160-167168-175176-183184-191

160	Type	Code	校驗碼（checksum）
192	ID		序號（sequence）

• Type?- ICMP的類型,標識生成的錯誤報文；
• Code?- 進一步劃分ICMP的類型,該字段用來查找產(chǎn)生錯誤的原因.；例如，ICMP的目標不可達類型可以把這個位設為1至15等來表示不同的意思。
• Checksum?- 校驗碼部分,這個字段包含有從ICMP報頭和數(shù)據(jù)部分計算得來的，用于檢查錯誤的數(shù)據(jù)，其中此校驗碼字段的值視為0。
• ID?- 這個字段包含了ID值，在Echo Reply類型的消息中要返回這個字段。
• Sequence?- 這個字段包含一個序號，同樣要在Echo Reply類型的消息中要返回這個字段。

?

填充數(shù)據(jù)

填充的數(shù)據(jù)緊接在ICMP報頭的后面（以8位為一組）：

• Linux的"ping"工具填充的ICMP除了8個8位組的報頭以外，默認情況下還另外填充數(shù)據(jù)使得總大小為64字節(jié)。
• Windows的"ping.exe"填充的ICMP除了8個8位組的報頭以外，默認情況下還另外填充數(shù)據(jù)使得總大小為40字節(jié)。

?

報文類型

類型代碼狀態(tài)描述查詢差錯

0 -?Echo Reply	0	?	echo響應 (被程序ping使用）	●	?
1 and 2	?	未分配	保留	?	●
3 - 目的不可達	0	?	目標網(wǎng)絡不可達	?	●
	1	?	目標主機不可達	?	●
	2	?	目標協(xié)議不可達	?	●
	3	?	目標端口不可達	?	●
	4	?	要求分段并設置DF flag標志	?	●
	5	?	源路由失敗	?	●
	6	?	未知的目標網(wǎng)絡	?	●
	7	?	未知的目標主機	?	●
	8	?	源主機隔離（作廢不用）	?	●
	9	?	禁止訪問的網(wǎng)絡	?	●
	10	?	禁止訪問的主機	?	●
	11	?	對特定的TOS 網(wǎng)絡不可達	?	●
	12	?	對特定的TOS 主機不可達	?	●
	13	?	由于過濾 網(wǎng)絡流量被禁止	?	●
	14	?	主機越權(quán)	?	●
	15	?	優(yōu)先權(quán)終止生效	?	●
4 - 源端關(guān)閉	0	棄用	源端關(guān)閉（擁塞控制）	?	●
5 - 重定向	0	?	重定向網(wǎng)絡	?	●
	1	?	重定向主機	?	●
	2	?	基于TOS 的網(wǎng)絡重定向	?	●
	3	?	基于TOS 的主機重定向	?	●
6	?	棄用	備用主機地址	?	?
7	?	未分配	保留	?	?
8 -?請求回顯	0	?	Echo請求	●	?
9 - 路由器通告	0	?	路由通告	●	?
10 - 路由器請求	0	?	路由器的發(fā)現(xiàn)/選擇/請求	●	?
11 - ICMP 超時	0	?	TTL 超時	?	●
	1	?	分片重組超時	?	●
12 - 參數(shù)問題：錯誤IP頭部	0	?	IP 報首部參數(shù)錯誤	?	●
	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	?	棄用	數(shù)據(jù)報轉(zhuǎn)換出錯	?	?
32	?	棄用	手機網(wǎng)絡重定向	?	?
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	?	保留	保留

?

?

?

特別說明：以上內(nèi)容大部分收集、整理自**百科。

?

總結(jié)

以上是生活随笔為你收集整理的ICMP （互联网控制消息协议 ）是什么的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。