TCP／IP詳解，卷1：協議--第6章 ICMP：Internet控制報文協議

引言

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差錯報文：
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) 源地址不是單個主機的數據報。這就是說，源地址不能爲零地址、環回地址、廣播地
址或多播地址。
這些規則是爲了防止過去容許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、五、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輸出，這種表示方式在本書後面的章節 中會常常用到。