引子: 提到網絡協(xié)議, 大家最先想到的肯定是TCP, IP, HTTP等這些"家喻戶曉"的協(xié)議, 但是還有很多"默默無聞"的協(xié)議, 在背后做了很多的工作, 沒有這些協(xié)議整個計算機網絡是不能正常工作的. 這篇文章要介紹的ICMP協(xié)議就屬于這樣一種協(xié)議.
1. 什么是ICMP協(xié)議
ICMP協(xié)議的全稱是網際控制報文協(xié)議(Internet Control Message Protocol). 它的作用是什么呢? 眾所周知IP協(xié)議是一個不安全的協(xié)議, 也就是說IP協(xié)議只管傳遞上層協(xié)議的數(shù)據(jù)包而不管這個數(shù)據(jù)包是否有沒有被目的主機正確接收, 對數(shù)據(jù)包傳遞進行差錯控制是由上層協(xié)議自己實現(xiàn)的(比如TCP協(xié)議). 這樣看下來貌似沒有ICMP協(xié)議什么事了, 數(shù)據(jù)包的傳遞由IP協(xié)議做了, 數(shù)據(jù)包的差錯控制由上層的比如TCP協(xié)議做了, 那ICMP協(xié)議豈不成了雞肋? 但是要注意到, 從數(shù)據(jù)包傳遞到數(shù)據(jù)包差錯控制之間還有一個過程, 那就是上層協(xié)議如何知道數(shù)據(jù)包出錯了? 介紹到這里, 大家應該知道ICMP協(xié)議的作用是什么了, 簡單的說ICMP協(xié)議的核心作用就是對上層協(xié)議報告數(shù)據(jù)包傳遞時的差錯.
下面是ICMP協(xié)議在處于的網絡層級:
可以看到ICMP也是一個網絡層的協(xié)議. 如果從ICMP的功能上看, 將其歸到網絡層也是合理的. 因為ICMP的功能就是向高層協(xié)議傳遞數(shù)據(jù)包的出錯信息, 所以肯定不能放到傳輸?層. 但是我個人認為ICMP的功能其實是可以放到IP協(xié)議中進行實現(xiàn)的, 但是可能由于歷史原因當時設計IP協(xié)議的時候并沒有考慮到這一點所以后面為了實現(xiàn)差錯控制新增了這一個協(xié)議. 不過換句話說將ICMP和IP進行分離也有一定的好處, 就是每個協(xié)議的功能更加專一, IP協(xié)議就負責傳遞數(shù)據(jù), ICMP就負責差錯控制.
雖然ICMP是網絡層協(xié)議, 但是它不像IP協(xié)議和ARP協(xié)議一樣直接傳遞給數(shù)據(jù)鏈路層, 而是先封裝成IP數(shù)據(jù)包然后再傳遞給數(shù)據(jù)鏈路層. 所以在IP數(shù)據(jù)包中如果協(xié)議類型字段的值是1的話, 就表示IP數(shù)據(jù)是ICMP報文. IP數(shù)據(jù)包就是靠這個協(xié)議類型字段來區(qū)分不同的數(shù)據(jù)包的.
這里再提一點, 從上圖還可以看到在ICMP旁邊還有IGMP協(xié)議, 這個協(xié)議的全名叫做互聯(lián)網組管理協(xié)議(Internet Group Management Protocol). 這個協(xié)議的作用簡單來說就是幫助路由器來管理其所在網絡中可用的主機. 這個協(xié)議的詳細介紹不會在本篇涉及, 后面會新開一篇文章介紹
2. ICMP協(xié)議的格式
ICMP協(xié)議的類型分為兩大類, 查詢報文和差錯報文. 查詢報文總是成對出現(xiàn).
ICMP協(xié)議的種類:
| 種類 | 類型 | 報文 |
|---|---|---|
| 差錯報告報文 | 3 | 終點不可達 |
| 4 | 源點抑制 | |
| 11 | 超時 | |
| 12 | 參數(shù)問題 | |
| 5 | 改變路由 | |
| 查詢報文 | 8或0 | 回送請求或回答 |
| 13或14 | 時間戳請求或回答 |
從上面的表格可以看到, icmp報文的種類是有多種的, 雖然每一種類型的報文的首部都是不同的, 但是前4個字節(jié)的結構對于所有的報文來說都是一樣的, 所以可以得出如下的icmp的通用結構
下面簡單看一下ICMP頭部的每一個字段的含義:
- 類型字段顧名思義是定義了ICMP報文的類型
- 代碼字段表示的是發(fā)送這個ICMP報文的原因
- 校驗和字段
- 首部的其余部分對于不同的ICMP是不同的
- 數(shù)據(jù)部分對于差錯報告報文是用于找出引起差錯的原始分組的信息, 對于查詢報文是基于查詢類型的額外的信息
3. 差錯報告報文
雖然ICMP支持差錯報告報文, 但是這個報文不是用來糾正錯誤的, 而是用來簡單的報告錯誤的, 至于對于錯誤怎么處理是高層協(xié)議的職責. 同時, 差錯報文總是發(fā)送給最初的數(shù)據(jù)源(這是因為在ICMP數(shù)據(jù)報中唯一可以使用的就是源IP和目的IP).
如下是差錯報告報文的分類:
這里不會介紹所有的差錯報告報文, 只會選取其中的一個進行講解, 其他的報文類型也全部類似, 相信掌握了一個之后其他的也很容易理解. (這個是ICMP的RFC文檔, 可以供大家參考).
3.1 超時報文
因為超時報文比較容易在本機上模擬和被wireshark抓到, 所以這里選擇超時報文進行講解
3.1.1 什么是超時報文
超時報文會在兩種情況下產生, 一個是由路由器產生, 一個是由主機產生.
由路由器產生: 我們知道在網絡上傳輸?shù)臄?shù)據(jù)包種都有一個叫做生存時間的字段(這個字段存在于IP頭中), 從名字就可以看出來這個字段是用于控制數(shù)據(jù)包的在網絡上的生存時間的, 當數(shù)據(jù)包通過路由器的時候這個字段的值就會減一, 當這個字段的值變成0時就會丟棄這個數(shù)據(jù)包, 同時路由器還會向源點發(fā)送一個超時報文. 如果是這種情況下產生的超時數(shù)據(jù)包, 那頭部的代碼字段的值就是0.
由主機產生: 我們還知道如果數(shù)據(jù)包太大在IP層會將數(shù)據(jù)包進行分片并為每一個分片打上標記然后發(fā)送, 等到了目的地會根據(jù)標記將所有的分片組合成一個完成的數(shù)據(jù)包. 當主機接收到第一個分片的時候就會啟動一個定時器, 如果在指定的時間沒有收集到所有的分片, 主機就會將所有的分片都拋棄, 同時向源點發(fā)送一個超時報文. 如果是這種情況下產生的超時數(shù)據(jù)包, 那頭部的代碼字段的值就是1
3.1.2 超時報文的格式
其他類型的差錯報文的格式基本都是這個結構
從這里看出來超時報文的格式和之前已經說過的ICMP的通用結構是一致的, 只不過對類型, 代碼等進行了具體化.
報文的數(shù)據(jù)部分的內容是源數(shù)據(jù)包的IP頭和源數(shù)據(jù)包的數(shù)據(jù)部分的頭8個字節(jié), 這個是為什么呢? 之前說過ICMP是用于向上層的協(xié)議來報告錯誤的, 所以ICMP得先知道將錯誤信息提交給上層的哪一個協(xié)議, 這個信息就保存在那8個字節(jié)中. 我們知道上層的協(xié)議都是把整體作為下一層的數(shù)據(jù)部分, 然后加上下一層的頭部, 具體來說就是IP協(xié)議會把TCP或者UDP協(xié)議整體放到IP協(xié)議的數(shù)據(jù)字段中, 所以那8個字節(jié)就是TCP或者UDP的header中的一部分, 大家看一下TCP或者UDP的結構就可以知道, TCP或者UDP中的端口信息就在那8個字段范圍之內. 所以根據(jù)這個端口信息就可以知道將錯誤傳遞給上層的哪個協(xié)議了.
3.1.3 超時報文協(xié)議的"真面目"
接下來我們就來看看超時報文協(xié)議到底長什么樣.
在揭開超時報文的"廬山真面目"之前要做一些準備工作. 要看超時報文長什么樣首先總得捕獲到它, 所以先要想辦法產生超時報文. 從之前的介紹中可以找到如果生存時間到了路由器就會給源主機發(fā)送一個超時報文, 所以我們用下面的命令來產生超時報文:
ping -m 1 8.8.8.8
-m參數(shù)用于設置TTL(生存時間)
在執(zhí)行該命令前記得先啟動wireshark
效果如下圖:
然后打開wireshark看看抓到包
可以看到這是一個ping request(ping的底層其實也是一個ICMP協(xié)議, 下一篇文章會介紹), 重點關注這個數(shù)據(jù)包的IP頭. 可以看到IP數(shù)據(jù)包中的類型就是ICMP類型, 且TTL已經被設置成1了, 所以只要經過一個路由器這個數(shù)據(jù)包就會超時了, 而剛才ping的8.8.8.8是一個DNS域名解析服務器, 所以經過的路由器肯定不止一個, 所以肯定可以收到超時數(shù)據(jù)包.
看一下超時數(shù)據(jù)包:
可以看到由于我們設置的請求數(shù)據(jù)包的TTL是1, 所以在經過網關路由器的時候TTL就被減成0了, 所以網關路由器發(fā)送了一個超時數(shù)據(jù)包給我的計算機. 可以看到接收到的超時報文中的數(shù)據(jù)字段就如同之前說的是源IP頭和源IP數(shù)據(jù)字段的前8個字節(jié).
4. 未完待續(xù)
ICMP協(xié)議的大類只有兩種, 但是每一類下面的種類太多所以不能全部介紹, 這篇文章先介紹了ICMP中差錯報文中超時報文(這個理解了其他類看看文檔也很好理解), 下一篇會介紹ICMP的另外一大類查詢報文, 我們平時使用的ping, traceroute這些命令的底層就是依賴于ICMP的查詢報文來實現(xiàn)的.
