引言
I C M P經常被認為是 I P層的一個組成部分，它傳遞差錯報文以及其他需要注意的資訊，
I C M P報文通常被I P層或更高層協議（ T C P或U D P）使用，一些I C M P報文把差錯報文回傳給
用戶行程，
在本章中，我們將一般地討論 I C M P報文，并對其中一部分作詳細介紹：地址掩碼請求和
應答、時間戳請求和應答以及不可達埠
ICMP報文的型別
各種型別的I C M P報文如圖6 - 3所示，不同型別由報文中的型別欄位和代碼欄位來共同決定，
圖中的最后兩串列明 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差錯報文：
- ICMP差錯報文（但是，I C M P查詢報文可能會產生I C M P差錯報文），
- 目的地址是廣播地址（見圖3 - 9）或多播地址（D類地址，見圖1 - 5）的I P資料報，
- 作為鏈路層廣播的資料報，
- 不是I P分片的第一片（將在11 . 5節介紹分片），
- 源地址不是單個主機的資料報，這就是說，源地址不能為零地址、環回地址、廣播地
址或多播地址，
這些規則是為了防止過去允許I C M P差錯報文對廣播分組回應所帶來的廣播風暴
ICMP地址掩碼請求與應答
I C M P地址掩碼請求用于無盤系統在引導程序中獲取自己的子網掩碼（ 3 . 5節），系統廣播
它的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報文中的識別符號和序列號欄位由發送端任意選擇設定，這些值在應答中將被回傳，
這樣，發送端就可以把應答與請求進行匹配，
廣播的一般特性：發送主機也能通過某種內部環回機制收到一
份廣播報文拷貝，由于術語“廣播”的定義是指局域網上的所有主機，因此它必須包括發送
主機在內
R F C規定，除非系統是地址掩碼的授權代理，否則它不能發送地址掩碼應答（為
了成為授權代理，它必須進行特殊配置，以發送這些應答，參見附錄 E）但是
大多數主機在收到請求時都發送一個應答，甚至有一些主機還發送差錯的應答
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所示
請求端填寫發起時間戳，然后發送報文，應答系統收到請求報文時填寫接收時間戳，在
發送應答時填寫發送時間戳，但是，實際上，大多數的實作把后面兩個欄位都設成相同的值
（提供三個欄位的原因是可以讓發送方分別計算發送請求的時間和發送應答的時間），
由于某種原因， S V R 4在I C M P時間戳中不提供毫秒級的解析度，這樣，對秒以下的時間
差調整將不起任何作用
ICMP埠不可達差錯
最后兩小節我們來討論 I C M P查詢報文 — 地址掩碼和時間戳查詢及應答，現在來分析一
種I C M P差錯報文，即埠不可達報文，它是 I C M P目的不可到達報文中的一種，以此來看一
看I C M P差錯報文中所附加的資訊，使用U D P（見第11章）來查看它
U D P的規則之一是，如果收到一份 U D P資料報而目的埠與某個正在使用的行程不相符，
那么U D P回傳一個I C M P不可達報文，可以用T F T P來強制生成一個埠不可達報文（ T F T P將
在第1 5章描述），
在U D P資料報送到s v r 4之前，要先發送一份A R P請求來確定它的硬體地址（第1行），接著
回傳A R P應答（第2行），然后才發送U D P資料報（第3行）（在t c p d u m p的輸出中保留A R P請
求和應答是為了提醒我們，這些報文交換可能在第一個 I P資料報從一個主機發送到另一個主
機之前是必需的）
盡管I C M P規則允許系統回傳多于8個位元組的產生差錯的I P資料報中的資料，但是大多
數從伯克利派生出來的系統只回傳 8個位元組， Solaris 2.2的i p _ i c m p _ r e t u r n _
d a t a _ b y t e s選項默認條件下回傳前6 4個位元組
在本書的后面章節中，我們還要以時間系列的格式給出t c p d u m p命令的輸出，如圖6 - 11所示，
時間隨著向下而遞增，在圖左邊的時間標記與 t c p d u m p命令的輸出是相同的（見圖 6 - 8），
位于圖頂部的標記是通信雙方的主機名和埠號，需要指出的是，隨著頁面向下的y坐標軸與真
正的時間值不是成比例的，當出現一個有意義的時間段時，在本例中是每５秒之間的重發，我
們就在時間系列的兩側作上標記，當U D P或T C P資料正在被傳送時，我們用粗線的行來表示，
當I C M P報文回傳時，為什么 T F T P客戶程式還要繼續重發請求呢？這是由于網路編程中
的一個因素，即B S D系統不把從插口( s o c k e t )接收到的I C M P報文中的U D P資料通知用戶行程，
除非該行程已經發送了一個 c o n n e c t命令給該插口，標準的 BSD TFTP客戶程式并不發送
c o n n e c t命令，因此它永遠也不會收到I C M P差錯報文的通知，
這里需要注意的另一點是 T F T P客戶程式所采用的不太好的超時重傳演算法，它只是假定 5
秒是足夠的，因此每隔 5秒就重傳一次，總共需要 2 5秒鐘的時間，在后面我們將看到 T C P有一
個較好的超時重發演算法
T F T P客戶程式所采用的超時重傳演算法已被R F C所禁用，不過，在作者所在子網上
的三個系統以及Solaris 2.2仍然在使用它，AIX 3.2.2采用一種指數退避方法來設定超時
值，分別在0、5、1 5和3 5秒時重發報文，這正是所推薦的方法，我們將在第 2 1章更詳
細地討論超時問題，
最后需要指出的是，I C M P報文是在發送U D P資料報3.5 ms后回傳的，這與第7章我們所看
到的P i n g應答的往返時間差不多
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對發送端關閉的處理等，我們將在以后
的章節中對它們進行討論，
小結
本章對每個系統都必須包括的 I n t e r n e t控制報文協議進行了討論，圖 6 - 3列出了所有的
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資料報的首部及后續 8個位元組，這個資訊對于 I C M P差錯的接收方來
說是必要的，可以更多地了解導致差錯的原因，這是因為 T C P和U D P都在它們的首部前8個字
節中存入源埠號和目的埠號，
最后，我們第一次給出了按時間先后的 t c p d u m p輸出，這種表示方式在本書后面的章節
中會經常用到，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/91874.html
標籤：其他