什么是ICMP協議

　　ICMP全稱Internet Control Message Protocol（網際控制信息協議）

　　提起ICMP，一些人可能會感到陌生，實際上，ICMP與我們息息相關。在網絡體系結構的各層次中，都需要控制，而不同的層次有不同的分工和控制內容，IP層的控制功能是最復雜的，主要負責差錯控制、擁塞控制等，任何控制都是建立在信息的基礎之上的，在基于IP數據報的網絡體系中，網關必須自己處理數據報的傳輸工作，而IP協議自身沒有內在機制來獲取差錯信息并處理。為了處理這些錯誤，TCP/IP設計了ICMP協議，當某個網關發現傳輸錯誤時，立即向信源主機發送ICMP報文，報告出錯信息，讓信源主機采取相應處理措施，它是一種差錯和控制報文協議，不僅用于傳輸差錯報文，還傳輸控制報文。

　　ICMP報文格式

　　ＩC M P所有報文的前4個字節都是一樣的，但是剩下的其他字節則互不相同。。

　　類型字段可以有1 5個不同的值，以描述特定類型的I C M P報文。某些I C M P報文還使用代碼字段的值來進一步描述不同的條件。

　　表示ICMP頭部的數據結構

　　typedefstruct icmp_hdr

　　{ unsigned char icmp_type; //消息類型

　　unsigned char icmp_code; //代碼

　　unsigned short icmp_checksum; //校驗和

　　unsigned short icmp_id; //ID號

　　unsigned short icmp_sequence; //序列號

　　unsigned long icmp_timestamp; //時間戳

　　} ICMP_HDR，*PICMP_HDR;

　 ? ?ICMP報文的類型

　　ICMP 經常被認為是 IP 層的一個組成部分，它傳遞差錯報文以及其他需要注意的信息。ICMP 報文通常被 IP 層或更高層協議（TCP 或 UDP）使用。ICMP 報文是在 IP 數據報內部傳輸的。IP 協議是不可靠協議，不能保證 IP 數據報能夠成功的到達目的主機，無法進行差錯控制，而 ICMP 協議能夠協助 IP 協議完成這些功能。下面是 ICMP 報文的數據結構：

　　類型：一個 8 位類型字段，表示 ICMP 數據包類型;

　　代碼：一個 8 位代碼域，表示指定類型中的一個功能，如果一個類型中只有一種功能，代碼域置為 0;

　　檢驗和：數據包中 ICMP 部分上的一個 16 位檢驗和;

　　ICMP 差錯報文

　　當發送一份差錯報文時，報文始終包含 IP 的首部和產生 ICMP 差錯報文的 IP 數據報的前 8 位字節。這樣，接收 ICMP 差錯報文的模塊就會把它與某個特定的協議（根據 IP 數據報首部中的協議字段來判斷）和用戶進程（根據包含在 IP 數據報前 8 個字節中的 TCP 或 UDP 報文首部中的 TCP 或 UDP 端口號來判斷）聯系起來。

　　下面各種情況不會導致產生 ICMP 差錯報文：

　　ICMP 報文差錯（ICMP查詢報文可能會產生ICMP差錯報文）;

　　目的地址是廣播地址或多播地址的 IP 數據報;

　　作為鏈路層廣播的數據報;

　　不是 IP 分片的第一片;

　　源地址不是單個主機的數據報，也就是說，源地址不可能是零地址、環回地址、廣播地址或多播地址;

　　以下針對 ICMP 差錯報文的類型進行分析：

　　1、ICMP 目標不可達消息：IP 路由器無法將 IP 數據報發送給目的地址時，會給發送端主機返回一個目標不可達 ICMP 消息，并在這個消息中顯示不可達的具體原因。

　　2、ICMP 重定向消息：如果路由器發現發送端主機使用次優的路徑發送數據時，那么它會返回一個 ICMP 重定向消息給這個主機，這個消息包含了最合適的路由信息和源數據。主要發生在路由器持有更好的路由信息的情況下，路由器會通過這個 ICMP 重定向消息給發送端主機一個更合適的發送路由。

　　3、ICMP 超時消息：IP 數據包中有一個字段 TTL（Time to live，生存周期），它的值隨著每經過一個路由器就會減 1，直到減到 0 時該 IP 數據包被丟棄。此時，IP 路由器將發送一個 ICMP 超時消息給發送端主機，并通知該包已被丟棄。

　　4、源抑制消息：當 TCP/IP 主機發送數據到另一主機時，如果速度達到路由器或者鏈路的飽和狀態，路由器發出一個 ICMP 源抑制消息。

　　各種類型的I C M P報文如圖所示，不同類型由報文中的類型字段和代碼字段來共同決定。圖中的最后兩列表明I C M P報文是一份查詢報文還是一份差錯報文。因為對I C M P差錯報文有時需要作特殊處理，因此我們需要對它們進行區分。例如，在對I C M P差錯報文進行響應時，永遠不會生成另一份I C M P差錯報文（如果沒有這個限制規則，可能會遇到一個差錯產生另一個差錯的情況，而差錯再產生差錯，這樣會無休止地循環下去）。

　　當發送一份I C M P差錯報文時，報文始終包含I P的首部和產生I C M P差錯報文的I P數據報的前8個字節。這樣，接收I C M P差錯報文的模塊就會把它與某個特定的協議（根據I P數據報首部中的協議字段來判斷）和用戶進程（根據包含在I P數據報前8個字節中的T C P或U D P報文首部中的T C P或U D P端口號來判斷）聯系起來。6 。 5節將舉例來說明一點。

　　下面各種情況都不會導致產生I C M P差錯報文：

　　1） ICMP差錯報文（但是，I C M P查詢報文可能會產生I C M P差錯報文）。

　　2） 目的地址是廣播地址或多播地址的I P數據報。

　　3） 作為鏈路層廣播的數據報。

　　4） 不是I P分片的第一片。

　　5） 源地址不是單個主機的數據報。這就是說，源地址不能為零地址、環回地址、廣播地

　　址或多播地址。

　　這些規則是為了防止過去允許I C M P差錯報文對廣播分組響應所帶來的廣播風暴。

　　下面是幾種常見的ICMP報文：

　　1.響應請求

　　我們日常使用最多的ping，就是響應請求（Type=8）和應答（Type=0），一臺主機向一個節點發送一個Type=8的ICMP報文，如果途中沒有異常（例如被路由器丟棄、目標不回應ICMP或傳輸失敗），則目標返回Type=0的ICMP報文，說明這臺主機存在，更詳細的tracert通過計算ICMP報文通過的節點來確定主機與目標之間的網絡距離。

　　2.目標不可到達、源抑制和超時報文

　　這三種報文的格式是一樣的，目標不可到達報文（Type=3）在路由器或主機不能傳遞數據報時使用，例如我們要連接對方一個不存在的系統端口（端口號小于1024）時，將返回Type=3、Code=3的ICMP報文，它要告訴我們：“嘿，別連接了，我不在家的！”，常見的不可到達類型還有網絡不可到達（Code=0）、主機不可到達（Code=1）、協議不可到達（Code=2）等。源抑制則充當一個控制流量的角色，它通知主機減少數據報流量，由于ICMP沒有恢復傳輸的報文，所以只要停止該報文，主機就會逐漸恢復傳輸速率。最后，無連接方式網絡的問題就是數據報會丟失，或者長時間在網絡游蕩而找不到目標，或者擁塞導致主機在規定時間內無法重組數據報分段，這時就要觸發ICMP超時報文的產生。超時報文的代碼域有兩種取值：Code=0表示傳輸超時，Code=1表示重組分段超時。

　　3.時間戳

　　時間戳請求報文（Type=13）和時間戳應答報文（Type=14）用于測試兩臺主機之間數據報來回一次的傳輸時間。傳輸時，主機填充原始時間戳，接收方收到請求后填充接收時間戳后以Type=14的報文格式返回，發送方計算這個時間差。一些系統不響應這種報文。

　　ICMP 查詢報文

　　----ICMP 回送消息：用于進行通信的主機或路由之間，判斷發送數據包是否成功到達對端的消息。可以向對端主機發送回送請求消息，也可以接收對端主機回來的回送應答消息。

　　----ICMP 地址掩碼消息：主要用于主機或路由想要了解子網掩碼的情況。可以向那些主機或路由器發送 ICMP 地址掩碼請求消息，然后通過接收 ICMP 地址掩碼應答消息獲取子網掩碼信息。

　　----ICMP 時間戳消息：可以向那些主機或路由器發送 ICMP 時間戳請求消息，然后通過接收 ICMP 時間戳應答消息獲取時間信息。

　　Ping 程序

　　Ping 程序利用 ICMP 回顯請求報文和回顯應答報文（而不用經過傳輸層）來測試目標主機是否可達。它是一個檢查系統連接性的基本診斷工具。

　　ICMP 回顯請求和 ICMP 回顯應答報文是配合工作的。當源主機向目標主機發送了 ICMP 回顯請求數據包后，它期待著目標主機的回答。目標主機在收到一個 ICMP 回顯請求數據包后，它會交換源、目的主機的地址，然后將收到的 ICMP 回顯請求數據包中的數據部分原封不動地封裝在自己的 ICMP 回顯應答數據包中，然后發回給發送 ICMP 回顯請求的一方。如果校驗正確，發送者便認為目標主機的回顯服務正常，也即物理連接暢通。

　　例如：在終端上 Ping 下谷歌的地址，神奇的發現谷歌地址既然不用翻墻都能上了，而且丟包率 0%。

　　$ ping www.google.com

　　PING www.google.com （173.194.127.148） 56（84） bytes of data.

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=1 ttl=48 time=11.0 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=2 ttl=48 time=10.8 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=3 ttl=48 time=11.1 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=4 ttl=48 time=10.8 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=5 ttl=48 time=11.1 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=6 ttl=48 time=11.0 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=7 ttl=48 time=10.5 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=8 ttl=48 time=9.96 ms

　　64 bytes from hkg03s13-in-f20.1e100.net （173.194.127.148）： icmp_req=9 ttl=48 time=10.9 ms

　　^C

　　--- www.google.com ping statistics ---

　　9 packets transmitted， 9 received， 0% packet loss， time 8009ms

　　rtt min/avg/max/mdev = 9.963/10.830/11.123/0.368 ms

　　Traceroute 程序

　　Traceroute 程序主要用來偵測源主機到目的主機之間所經過的路由的情況。

　　Traceroute 使用 ICMP 報文和 IP 首部中的 TTL 字段，它充分利用了 ICMP 超時消息。其原理很簡單，開始時發送一個 TTL 字段為 1 的 UDP 數據報，而后每次收到 ICMP 超時蕭后，按順序再發送一個 TTL 字段加 1 的 UDP 數據報，以確定路徑中的每個路由器，而每個路由器在丟棄 UDP 數據報時都會返回一個 ICMP 超時報文，而最終到達目的主機后，由于 ICM P選擇了一個不可能的值作為 UDP 端口（大于30000）。這樣目的主機就會發送一個端口不可達的 ICMP 差錯報文。

　 ??ICMP協議的運用

　　１ ICMP地址掩碼請求與應答

　　I C M P地址掩碼請求用于無盤系統在引導過程中獲取自己的子網掩碼。系統廣播

　　它的I C M P請求報文（這一過程與無盤系統在引導過程中用R A R P獲取I P地址是類似的）。無盤

　　系統獲取子網掩碼的另一個方法是B O O T P協議。如圖

　　I C M P報文中的標識符和序列號字段由發送端任意選擇設定，這些值在應答中將被返回。

　　這樣，發送端就可以把應答與請求進行匹配。

　　我們可以寫一個簡單的程序（取名為i c m p a d d r m a s k），它發送一份I C M P地址掩碼請求報

　　文，然后打印出所有的應答。由于一般是把請求報文發往廣播地址，因此這里我們也這樣做。

　　目的地址（1 4 0 。 2 5 2 。 1 3 。 6 3）是子網1 4 0 。 2 5 2 。 1 3 。 32的廣播地址。

　　sun% icmpaddrmask 140.252.13.63

　　receivedmask = ffffffe0， from 140.252.13.來3自3 本 機

　　receivedmask = ffffffe0， from 140.252.13.來3自5 b s d i

　　receivedmask = ffff0000， from 140.252.13.來3自4 s v r 4

　　在輸出中我們首先注意到的是，從s v r 4返回的子網掩碼是錯的。顯然，盡管s v r 4接口

　　已經設置了正確的子網掩碼，但是S V R 4還是返回了一個普通的B類地址掩碼，就好像子網并

　　不存在一樣。

　　svr4% ifconfig emd0

　　emd0:flags=23《UP，BROADCAST，NOTRAILERS》

　　inet140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63

　　S V R 4處理I C M P地址掩碼請求過程存在差錯。

　　我們用t c p d u m p命令來查看主機b s d i上的情況，輸出如圖6 - 5所示。我們用- e選項來查看

　　硬件地址。

　　發到廣播地址的ICMP地址掩碼請求

　　注意，盡管在線路上什么也看不見，但是發送主機s u n也能接收到I C M P應答（帶有上面

　　“來自本機”的輸出行）。這是廣播的一般特性：發送主機也能通過某種內部環回機制收到一份廣播報文拷貝。由于術語“廣播”的定義是指局域網上的所有主機，因此它必須包括發送主機在內。

　　接下來，b s d i廣播應答，而s v r 4卻只把應答傳給請求主機。通常，應答地址必須是單播地址，除非請求端的源I P地址是0 。 0 。 0 。 0。本例不屬于這種情況，因此，把應答發送到廣播地址是B S D / 3 8 6的一個內部差錯。

　　R F C規定，除非系統是地址掩碼的授權代理，否則它不能發送地址掩碼應答（為

　　了成為授權代理，它必須進行特殊配置，以發送這些應答。參見附錄E）。但是，正如

　　我們從本例中看到的那樣，大多數主機在收到請求時都發送一個應答，甚至有一些主

　　機還發送差錯的應答。