摘要：
本文剖析了瀏覽器輸入URL到整個頁面顯示的整個過程，以百度首頁為例，結合Wireshark俘獲分組進行詳細分析整個過程，從而更好地了解TCP/IP協議棧。
一、俘獲分組
1.1 准備工作
(1) 清空瀏覽器緩存
首先清空Web瀏覽器的高速緩存，確保Web網頁是從網絡中獲取，而不是從高速緩沖取得[1]。谷歌瀏覽器，Options --> Under the Hood --> Clear browsing data。
(2)清空DNS緩存
在客戶端清空DNS高速緩存，確保Web服務器域名到IP地址映射是從網絡請求。在Windows XP，在命令行輸入ipconfig/flushdns完成操作。
圖1 清空DNS高速緩存
(3)設置過濾規則
為了便於分析，在截取數據包之前，設置過濾規則。在Filter ToolBar，輸入過渡規則正則表達式，這里過濾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協議由兩部分程序實現：客戶機程序、服務器程序，協議定義了這些報文的格式以及客戶機和服務器如何進行報文交換的。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) 協議是 TCP/IP 上的 NetBIOS (NetBT) 協議族的一部分，它在基於 NetBIOS 名稱訪問的網絡上提供主機名和地址映射方法。
參考資料：
[1] 百度百科詞條：SSDP
[2] Andrew S.Tanenbaum.計算機網絡[M].
[3] 《計算機網絡--自頂向下方法與Internet特色》[M].
[4] 百度百科詞條：NBNS
本實例的Wireshark俘獲分組pcapng原文件
Wireshark俘獲分組實例.rar
請求至響應間相關報文報visio原文件 請求至響應間相關報文段.rar
from:http://blog.chinaunix.net/uid-9112803-id-3212207.html