創作人QQ：851301776，郵箱：[email protected]，歡迎大家一起技術交流，本部落客要是自己學習的心得體會,隻為每天進步一點點！
個人座右銘：
1.沒有橫空出世，隻要厚積一定發。
2.你可以學曆不高，你可以不上學，但你不能不學習
此部落格總結，主要是友善日後檢視學習
一、簡述
ICMP經常被認為是IP層的一個組成部分。它傳遞差錯封包以及其他需要注意的資訊。ICMP封包通常被IP層或更高層協定（TCP或UDP）使用。一些ICMP封包把差錯封包傳回給使用者程序。
ICMP封包的格式如圖6 - 2所示。所有封包的前4個位元組都是一樣的，但是剩下的其他位元組則互不相同。
類型字段可以有15個不同的值，以描述特定類型的ICMP封包。某些ICMP封包還使用代碼字段的值來進一步描述不同的條件。
檢驗和字段覆寫整個ICMP封包。使用的算法與我們在首部檢驗和算法相同。ICMP的檢驗和是必需的。
1.ICMP封包的類型
ICMP主要分為兩大類：
- 查詢封包：是用一對請求和回答定義的
- 差錯封包：I C M P差錯封包通常包含了引起錯誤的 I P資料報的第一個分片的 I P首部(和選項)，加上該分片資料部分的前 8個位元組。标準假定這 8個位元組包含了該分組運輸層首部的所有分用資訊，這樣運輸層協定可以向正确的程序送出 I C M P差錯封包。T C P和U D P端口号在它們首部的前8個位元組内出現。
因為對ICMP差錯封包有時需要作特殊處理，是以我們需要對它們進行區分。當發送一份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端口号來判斷）聯系起來。
下面各種情況都不會導緻産生 I C M P差錯封包：
1) ICMP差錯封包（但是，I C M P查詢封包可能會産生I C M P差錯封包）。
2) 目的位址是廣播位址（見圖 3 - 9）或多點傳播位址（D類位址，見圖1 - 5）的I P資料報。
3) 作為鍊路層廣播的資料報。
4) 不是I P分片的第一片（将在11 . 5節介紹分片）。
5) 源位址不是單個主機的資料報。這就是說，源位址不能為零位址、環回位址、廣播位址或多點傳播位址。
二、ICMP詳細封包說明
1.ICMP位址掩碼請求與應答
I C M P位址掩碼請求用于無盤系統在引導過程中擷取自己的子網路遮罩。系統廣播它的I C M P請求封包（這一過程與無盤系統在引導過程中用 R A R P擷取I P位址是類似的）。無盤系統擷取子網路遮罩的另一個方法是 B O O T P協定，我們将在第 1 6章中介紹。 I C M P位址掩碼請求和應答封包的格式如圖6 - 4所示。
I C M P封包中的辨別符和序列号字段由發送端任意選擇設定，這些值在應答中将被傳回。這樣，發送端就可以把應答與請求進行比對。
2.ICMP時間戳請求與應答
I C M P時間戳請求允許系統向另一個系統查詢目前的時間。傳回的建議值是自午夜開始計算的毫秒數，協調的統一時間（ Coordinated Universal Time, UTC）（早期的參考手冊認為U T C是格林尼治時間）。這種I C M P封包的好處是它提供了毫秒級的分辨率，而利用其他方法從别的主機擷取的時間（如某些 U n i x系統提供的r d a t e指令）隻能提供秒級的分辨率。由于傳回的時間是從午夜開始計算的，是以調用者必須通過其他方法獲知當時的日期，這是它的一個缺陷。
I C M P時間戳請求和應答封包格式如圖 6 - 6所示。
請求端填寫發起時間戳，然後發送封包。應答系統收到請求封包時填寫接收時間戳，在發送應答時填寫發送時間戳。但是，實際上，大多數的實作把後面兩個字段都設成相同的值（提供三個字段的原因是可以讓發送方分别計算發送請求的時間和發送應答的時間）。
3.ICMP端口不可達錯誤
端口不可達是一種是差錯封包，即端口不可達封包。
U D P的規則之一是，如果收到一份 U D P資料報而目的端口與某個正在使用的程序不相符，那麼U D P傳回一個I C M P不可達封包。
I C M P的一個規則是， I C M P差錯封包（參見圖 6 - 3的最後一列）必須包括生成該差錯封包的資料報I P首部（包含任何選項），還必須至少包括跟在該 I P首部後面的前 8個位元組。
一個重要的事實是包含在 U D P首部中的内容是源端口号和目的端口号。就是由于目的端口号（8 8 8 8）才導緻産生了 I C M P端口不可達的差錯封包。接收 I C M P的系統可以根據源端口号（2 9 2 4）來把差錯封包與某個特定的使用者程序相關聯（在本例中是 T F T P客戶程式）。
導緻差錯的資料報中的 I P首部要被送回的原因是因為 I P首部中包含了協定字段，使得I C M P可以知道如何解釋後面的 8個位元組。如果我們來檢視 T C P首部（圖1 7 - 2）,可以發現源端口和目的端口被包含在 T C P首部的前8個位元組中。
I C M P不可達封包的一般格式如圖 6 - 1 0所示。
I C M P封包是在發送U D P資料報3.5 ms後傳回的，這與P i n g應答的往返時間差不多。
4.ICMP封包的4.4BSD處理
由于I C M P覆寫的範圍很廣，從緻命差錯到資訊差錯，是以即使在一個給定的系統實作中，對每個I C M P封包的處理都是不相同的。圖 6 - 1 2的内容與圖6 - 3相同，它顯示的是 4 . 4 B S D系統對每個可能的I C M P封包的處理方法。
如果最後一列标明是“核心”，那麼I C M P就由核心來處理。如果最後一列指明是“使用者程序”，那麼封包就被傳送到所有在核心中登記的使用者程序，以讀取收到的 I C M P封包。如果不存在任何這樣的使用者程序，那麼封包就悄悄地被丢棄（這些使用者程序還會收到所有其他類型的I C M P封包的拷貝，雖然它們應該由核心來處理，當然使用者程序隻有在核心處理以後才能收到這些封包）。有一些封包完全被忽略。最後，如果最後一列标明的是引号内的一串字元，那麼它就是對應的 U n i x差錯。其中一些差錯，如 T C P對發送端關閉的處理等，我們将在以後的章節中對它們進行讨論。
三、ping程式
P i n g程式由Mike Muuss編寫，目的是為了測試另一台主機是否可達。該程式發送一份 I C M P回應要求封包給主機，并等待傳回 I C M P回應答覆。
1.ping程式請求和響應
我們稱發送回應要求的 p i n g程式為客戶，而稱被 p i n g的主機為伺服器。大多數的 T C P / I P實作都在核心中直接支援 P i n g伺服器—這種伺服器不是一個使用者程序。I C M P回應要求和回應答覆封包如圖 7 - 1所示。
U n i x系統在實作p i n g程式時是把I C M P封包中的辨別符字段置成發送程序的 I D号。這樣即使在同一台主機上同時運作了多個 p i n g程式執行個體，p i n g程式也可以識别出傳回的資訊。
序列号從0開始，每發送一次新的回應要求就加 1。p i n g程式列印出傳回的每個分組的序列号，允許我們檢視是否有分組丢失、失序或重複。 I P是一種最好的資料報傳遞服務，是以這三個條件都有可能發生。
ping使用方法：
四、ICMP協定核心實作
圖11 - 1顯示了所有目前定義的I C M P封包。雙線上面的是I C M P請求和回答封包；雙線下面的是I C M P差錯封包。
圖11 - 1和圖11 - 2中含有大量資訊：
- P R C _欄顯示了N e t / 3處理的與協定無關的差錯碼( 11 . 6節)和I C M P封包之間的映射。對請求和回答，這一列是空的。因為在這種情況下不會産生差錯。如果對一個 I C M P差錯，這一行為空，說明N e t / 3不識别該碼，并自動丢棄該差錯封包。
- 圖11 - 3顯示了我們讨論圖11 - 2所列函數的位置。
- i c m p _ i n p u t欄是i c m p _ i n p u t為每個I C M P封包調用的函數。
- UDP欄是為U D P插口處理I C M P封包的函數。
- T C P欄是為T C P插口處理I C M P封包的函數。注意，是 t c p _ q u e n c h處理I C M P源站抑制差錯，而不是t c p _ n o t i f y。
- 如果e r r n o欄為空，核心不向程序報告 I C M P封包。
- 表的最後一行顯示，在用于接收 I C M P封包的程序的接收點上，不識别的 I C M P封包被送出給原來的I P協定。
在N e t / 3中，I C M P是作為I P之上的一個運輸層協定實作的，它不産生差錯或請求；它代表其他協定格式化并發送封包。 I C M P傳遞到達的差錯，并向适當的傳輸協定或等待 I C M P封包的程序發出回答。另一方面， I C M P用一個合适的I C M P回答響應大多數I C M P請求。圖11 - 4此作了總結。
1.代碼介紹
圖 11 - 5 的兩個檔案中有本章讨論的 I C M P 資料結構、統計量和處理的程式