轉_結合Wireshark捕獲分組深入理解TCP/IP協議棧

標籤：

轉自：

http://blog.chinaunix.net/uid-9112803-id-3212207.html

 

摘要：

本文剖析了瀏覽器輸入URL到整個頁面顯示的整個過程，以百度首頁為例，結合Wireshark俘獲分組進行詳細分析整個過程，從而更好地瞭解TCP/IP協議棧。

一、俘獲分組

1.1 準備工作

(1) 清空瀏覽器緩衝

首先清空Web瀏覽器的快取，確保Web網頁是從網路中擷取，而不是從高速緩衝取得[1]。Google瀏覽器，Options --> Under the Hood --> Clear browsing data。

(2)清空DNS緩衝

在用戶端清空DNS快取，確保Web伺服器網域名稱到IP地址映射是從網路請求。在Windows XP，在命令列輸入ipconfig/flushdns完成操作。

圖1 清空DNS快取

(3)設定過濾規則

為了便於分析，在截取資料包之前，設定過濾規則。在Filter ToolBar，輸入過渡規則Regex，這裡過濾ARP協議(位址解析通訊協定)，如下：

圖2 設定過濾規則

(4)關閉網路應用程式

為使俘獲的報文僅跟訪問URL相關，關閉其他網路應用程式(如QQ)。

1.2 啟動Wireshrk分組俘獲器

Capture --> Interfaces，彈出如下視窗，設定介面，點擊Start啟動分組俘獲器。

圖3 啟動Wireshark分組俘獲器

1.3 瀏覽器輸入URL

這裡，以百度為例，在瀏覽器輸入：http://www.baidu.com，斷行符號。

1.4 停止分組俘獲

圖4 Wireshark俘獲分取執行個體

二、概述

Web的應用程式層協議是超文字傳輸通訊協定 (HTTP)HTTP，HTTP協議由兩部分程式實現：客戶機程式、伺服器程式，協議定義了這些報文的格式以及客戶機和伺服器如何進行報文交換的。Web伺服器用於儲存Web對象，每個對象由URL定址，Web客戶機通常指瀏覽器。瀏覽器向伺服器發出對Web頁中所包含對象的HTTP請求報文，伺服器接受請求並用包含這些對象的HTTP響應報文進行響應。Web頁是由對象組成，對象簡單來說就是檔案(形檔案、Java小程式、聲音剪輯檔案)，這些檔案通過一個URL地址定址。Web頁通常含有一個基本的HTML檔案和幾個引用對象。

從在瀏覽器輸入http://www.baidu.com/並斷行符號，到瀏覽器視窗顯示百度首頁，這中間經曆多個過程，也涉及到諸多協議(4)，接下來，結合俘獲的分組分析這期間都發生了些什麼。

2.1 網域名稱解析(17~18)

首先需要將URL(存放對象的伺服器主機名稱和對象的路徑名)解析成IP地址，具體步驟為：

(1)同一台使用者主機上運行著DNS應用的客戶機端(如瀏覽器)

(2)從上述URL抽取主機名稱www.baidu.com，傳給DNS應用的客戶機端(瀏覽器)

(3)該DNS客戶機向DNS伺服器發送一個包含主機名稱的請求(DNS查詢報文)

(4)該DNS客戶機收到一份回答報文(即DNS回答報文)，該報文包含該主機名稱對應的IP地址119.75.218.70

步驟(3)、(4)分別對應於的前兩條DNS報文17、18，進一步擷取這兩步的細節，就得理解DNS協議，詳情見：

博文《結合Wireshark捕獲分組深入理解TCP/IP協議棧之DNS協議》

2.2 建立TCP連結(19~24)

HTTP使用TCP作為底層傳輸協議，需要先建立串連，即瀏覽器由IP地址定位的HTTP伺服器發送一個TCP連結。TCP串連建立及TCP報文分析，見：

博文《結合Wireshark捕獲分組深入理解TCP/IP協議棧之TCP協議(TCP報文格式+三向交握執行個體)》

2.3 提取內容

2.3.1 概述

客戶機發送HTTP請求報文給伺服器，伺服器返回HTTP響應報文，關於HTTP報文格式及執行個體，詳情見：

博文《結合Wireshark捕獲分組深入理解TCP/IP協議棧之HTTP協議》

伺服器返回客戶機所請求的頁面內容，交給瀏覽器，瀏覽器解釋HTML檔案(瀏覽器本質上是一個HTML解譯器)，顯示文本。伺服器返回的實體主體部分內容如下(通過瀏覽器查看原始碼或者查看響應報文的實體主體)：

圖5 百度首頁HTML語言

2.3.2 俘獲分組分析(26~32)

從圖4可以看出，HTTP請求報文到HTTP響應報文，中間還有若干TCP報文段，如下：

圖6 請求至響應間相關報文段

看上去挺亂的，先給出我分析後的，而後再分析，如下：

圖7 請求至響應間相關報文段

首先，客戶機發送HTTP請求報文25，伺服器響應該報文26(因為HTTP傳輸層協議是TCP，可靠傳輸)。接著，伺服器返回HTTP響應報文，因HTTP報文太大(3835位元組)，網路層對其進行分區，共4片，如(截自Wireshark俘獲的HTTP響應報文)：

圖8 資料分區執行個體

那為什麼每兩個TCP報文段才有一個確認，這是由於為了提高效率，TCP實行累積確認，即收到多個報文段之後，再一次確認。

2.3 瀏覽器顯示常值內容

至此，瀏覽器收到百度首頁基本HTML頁面，瀏覽器解釋該HTML頁面(是不是也調用了JS解譯器解釋JavaScript指令碼了？)，結果如下：

圖9 瀏覽器解釋百度首頁基本HTML頁面

很明顯，這與平時看到的首頁不同，帶X的框框、百度一下按鈕，這是因為這些對象還未獲得。

2.4 瀏覽器取回並顯示檔案中的所有對象

瀏覽器(客戶機的代理)會繼續向相應的伺服器請求所需內容，從Wireshark俘獲分組可知，瀏覽器請求了圖片、JavaScript對象，如下：

圖10 瀏覽器請求檔案中其他對象

有一點我沒搞懂，為何請求/favicon.ico對象？在HTML檔案找不到相關的代碼，頁面也沒顯示該表徵圖。求指點，謝謝:-)

這下Web頁面所有對象都到齊了，瀏覽器解釋所有對象並顯示，最終如果如下：

圖11 百度首頁

瀏覽器解釋對象有3種方式：內建解譯器(如HTML解譯器)、外掛程式、輔助應用程式。通過伺服器上的各種指令碼產生完整Web頁面，伺服器返回一個頁面也返回一些有關頁面的附加資訊(包括MEME類型)，對於內建類型的對象直接由內建解譯器解釋，其他的，瀏覽器參照MIME類型表，調用相應的查看器處理該對象。

三、其他問題

3.1 其他DNS報文

Wireshark俘獲的分組中包含著很多DNS報文，事實上，只有前面兩組DNS報文是需要的，其他的則是預取。可以看出，瀏覽器將百度首頁HTML所涉及的URL(充分利用空閑時間，減少等待時間)

圖12 DNS報文執行個體

這麼多的分組，如何快速配對呢？通過標識數快速配對(如所示)，或者開啟報文在Domain Name System底下的一行Request In或Response In會告知與哪個報文編號匹配。

3.2 其他TCP報文段

其他TCP報文段，要麼是TCP串連建立，要麼是傳輸資料，根據博文《結合Wireshark捕獲分組深入理解TCP/IP協議棧之TCP協議(TCP報文格式+三向交握執行個體)》很容易分析的。

3.3 SSDP協議

從圖4可以看出，訪問頁面之前和之後有大量SSDP報文。SSDP(簡單服務發現協議，Simple Service Discovery Protocol)定義了如何在網路上發現網路服務的方法。不論是控制點，或是UPnP裝置，工作中都必然用到SSDP，裝置接入網路之後，要利用它向網路廣播自己的存在(廣播的資訊中還有裝置位置的描述)，以便儘快與對應的控制點建立聯絡；控制點則利用SSDP來搜尋自己將要控制的裝置在哪裡.並且可以排除已經存在的裝置和控制點――只為新近的或尚未"聯絡"上的雙方服務[1]。

3.4 NBNS

Wireshark還俘獲一個NBNS報文。網路基本輸入/輸出系統 (NetBIOS) 名稱伺服器 (NBNS) 協議是 NetBIOS over TCP/IP (NetBT) 協議族的一部分，它在基於 NetBIOS 名稱訪問的網路上提供主機名稱和地址映射方法。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

轉_結合Wireshark捕獲分組深入理解TCP/IP協議棧