|
|
|
13-5 ICMP 協定
13-5-1 ICMP 封包格式 根據我們的瞭解，IP 網路是一種不可靠的傳輸方式，傳送中的封包必須經過多層路由器的轉送才能到達目的地。因此，在發送封包之前，我們很難預測該封包是否可以安全到達目的地。我們也很迫切的想知道目前網路的狀況，尤其在傳送失敗時，更想瞭解問題出在什麼地方。TCP/IP 網路中提供一種稱之為『網際控制訊息協定』（Internet Control Message Protocol, ICMP）的通訊軟體，用來偵測網路的狀況。在 IP 網路上，任何一部主機或路由器皆設置有 ICMP 協定，它們就可以利用 ICMP 來互相交換網路目前的狀況訊息，例如，主機不存在、網路斷線等等狀況。 ICMP 封包無法直接傳送到網路上，必須如同 TCP 封包一樣被嵌入 IP 封包內，以 IP 方式傳送（如表 13-1），包裝在 IP 內的封包格式，如圖 13-14 所示。
圖 13-14 ICMP 封包嵌入 IP 封包內傳送 圖 13-15 為 ICMP 封包格式，其各欄位功能如下： (1) 訊息型態（Message Type）：表示該 ICMP 所欲控制之訊息型態，共有 13 種型態，訊息型態之型態代表值如表 13-2 所示。 (2) 編碼（Code）：對各種訊息型態進一步說明工作內容。 (3) 檢查集檢查碼（Checksum）：對該封包檢查集錯誤偵測。 (4) 訊息說明（Message description）：依照不同的控制訊息，而有不同的說明方式。 (5) 訊息資料（Message Data）：依照不同的控制訊息，而有不同的資料表示。
圖 15-15 ICMP 封包格式 表 13-2 ICMP 訊息型態
各種不同的控制訊息型態，以下分別說明之： 13-5-2 回聲要求/回聲回應 『回聲要求』（Echo Request）（Type 8）是用來要求對方回聲，如有『回聲回應』（Echo Replay）（Type 0）表示對方主機或路由器工作正常。也可以用來測試網路路徑是否確實可以到達，被測試端用 ICMP Echo Reply 封包答覆對方的回聲要求。TCP/IP 的主機電腦（或路由器等設備）上皆有提供 "ping" 指令，其用來實現 Echo Request 命令。例如，在主機電腦上執行 ping 163.15.2.1 指令，當 163.15.2.1 之網路設備接收到該訊號時，必須立即回應 Echo Reply，而在主機電腦上會顯示經歷時間，或主機電腦在溢時之候，未收到 Echo Reply 訊號，則會顯示 Request timed out 訊息。被測試端和測試端之間也許經過多個路由器（或網路閘門），但如果收到 Echo Reply 訊號，則表示該路徑是可到達的。 圖 13-16 為 Echo Request 及 Echo Reply 的封包格式，其中 Identifier（識別碼）和 Sequence Number（順序號碼）是用檢查回聲回應封包是針對哪一個回聲要求所產生的。 一般我們可以連續發送多個 Echo Request 給被測試端，每個回聲要求都給予一個順序編號放置在 Identifier 內，被測試端發送 Echo Reply 時將 Echo Request 內之 Identifier 的值放置於 Sequence Number 欄位內，告訴發送端是針對哪一個 Echo Request 的回聲回覆。另外，封包內之 Option Data 可有可無，如 Echo Request 有放置資料，回覆 Echo Replay 就依照該資料送回。
圖 13-16 Echo Request/Reply 封包格式 13-5-3目的地無法到達 當路由器（或網路閘門）發現，某一個 IP 封包無法往下一個路徑傳送時，便發送ICMP Destination Unreachable（目的地無法到達，Type 3）封包給原始發送該封包者，並將封包丟棄。因此，在回應封包之 Message Data 欄位內必須註明是哪一個 IP 封包被丟棄，如圖 13-17 所示。而另封包內之 Code 欄位是用來註明無法到達目的地的原因，原因分類如下：
圖 13-17 Destination Unreachable 封包格式 13-5-4 來源抑制 當網路上路由器（或網路閘門）因為進入的封包速度過快，而來不及處理的時候（本身的緩衝器已溢滿），會將再進入的封包丟棄，並發送一個 ICMP Source Quench（來源抑制，Type 4）封包給該 IP 封包的來源主機。原發送主機接收到 Source Quench 封包後會暫停或降低發出封包的速度，一直到沒有接收到路由器所發送的 Source Quench 後，再恢復原來的發送速度。Source Quench 的封包格式如圖 13-18 所示。
圖 13-18 Source Quench 封包格式 13-5-5 改變傳輸路徑 在某些情況下（如網路拓樸圖改變或網路斷線），路由器發現原來由它轉送的目的位址，經由別的路由器轉送會比較快速，則該路由器便利用ICMP Redirect （改變傳輸路徑，Type 5）訊息通知原發送端，請它改變傳輸路徑，傳送到另一個路由器上。圖 13-19 為 Redirect 的封包格式，其中 "Gateway IP Address " 表示新轉向傳輸路徑的路由器之位址，Code 欄位表示轉向的原因：
圖 13-19 Redirect 封包格式 13-5-6 溢時傳輸 當路由器（或網路閘門）發現某一個 IP 封包內之 TTL（Time to Live）為 0 時，會發送一個 ICMP Time Exceeded（溢時傳輸，Type 11）封包給原發送封包者，並將該封包丟棄。為了避免封包在網路上不停的環繞，封包發送之前會在 TTL 欄位設定一個值，表示該封包的存活時間。封包在傳送後，每經過一個路由器，就將 TTL 內的值減一。如果路由器發現某個封包內的 TTL 值為 0，便判斷該封包已在網路上環繞，找不到適當路徑到達目的地，而將其丟棄。另外一種情況，接收端也會發送 ICMP Time Exceeded 訊息給來源端，此情況是資料片重組（Fragment reassembly）發生問題。當 IP 封包被分為若干個資料片段傳送時，接收端收到一筆資料片段時會設定一個計時時間，如在溢時（timeout）後未收到下一筆資料片段，則將發送 ICMP Time Exceeded 給原傳送端。圖 13-20 為 Time Exceeded 之封包格式，其中 Code = 0 表示 TTL = 0 時發送該封包；而 Code = 1 表示資料片段重組失敗所以要重新發送封包。
圖 13-20 Time Exceeded 封包格式 13-5-7 參數問題 當路由器（或網路閘門）發現 IP 封包內的某些欄位的值（參數）不正確，而無法處理該封包時，便發送 ICMP Parameter Problem（參數問題，Type 12）封包給原發送者。封包格式如圖 13-21 所示，其中 Pointer 欄位表示錯誤參數之位址。
圖 13-21 Parameter Problem 封包格式 13-5-8 時間訊息要求及回覆 ICMP Timestamp Request（時間訊息要求，Type 13）封包是用來詢問某部主機的系統時間；而 ICMP Timestamp Reply（時間訊息回覆，Type 14）則用來回應系統時間，這兩個封包是用來使網路上各設備的時間達到同步。圖 13-22 為 Timestamp 的封包格式，其中 Originate Timestamp 表示詢問者自己的時間、Receive Timestamp 表示被詢問者接收到 ICMP timestamp request 封包的時間、Transmit Timestamp 為被詢問者發送回應的時間。前一項為詢問者的時間基準；後二項為被詢問者的時間基準。時間單位都是 millisecond，並以格林威治時間為基準。
圖 13-22 Timestamp Request/Reply 封包格式 13-5-9 遮罩位址要求及回覆 ICMP Address Mask Request/Reply （Type 17/18）是被用來要求獲得或回應某一個次網路（Subnet）的位址遮罩（mask）時所使用，圖 13-23 為其封包格式。
圖 15-23 Address Mask Request/Reply 封包格式 |
翻轉工作室：粘添壽
電腦網路與連結技術：
翻轉電子書系列：
|
