TcpIP協議,HTTP,DNS 實戰:基于wireshark與BurpSuite抓包分析

TcpIP協議,HTTP,DNS 實戰：基于wireshark與BurpSuite抓包分析

使用 wireshark 前的基本配置

磨刀不誤砍柴工。為了高效率的利用 wireshark 來幫助我們分析，學習網絡協議，以及故障排除，需要對其進行一些使用前配置，大致內容如下：

1。將數據包摘要列表（packet list）中的“time”列的精度調整為 1 毫秒。

默認情況下，wireshark 的時間顯示精度為 1 納秒，但是在現實環境中通常用不到如此高的精度，一般用于評估站點響應速度，用戶體驗的性能指標，精確到毫秒級別就足夠了，而且納秒會多顯示小數點后 6 位數字，造成數據包摘要列表中的顯示空間的浪費。具體設置方法如下圖：

2。根據應用場景選擇時間列的顯示格式。默認情況下，以抓取到的第一個數據包的時間為參考點，后續的數據包的抓取時間都是相對開始抓包（第一個）的時點計算的。但是在某些場景中，需要將顯示格式調整為：與上一個抓取到的數據包的時間差，也就是相鄰2個數據包的抓包時間間隔。

我們知道，某些網絡應用，如即時通信，會議軟件的視頻，音頻流量等，對于數據包的連續發送或接收時間間隔，非常敏感，如果相鄰2個或多個包的間隔時間太長，就會造成應用的畫面和聲音延遲，一個更明顯的例子是網絡游戲的“卡”現象，由于收發包的間隔過長導致聲音與畫面的不一致和連續性問題。（通常與兩端通信鏈路的負載和其中路由器的負載過高，導致丟包而引發的 TCP 分段重傳有關）

這個時候，顯示時間間隔就非常有用，可以對當前網絡的穩定性，流暢性進行快速的檢視，具體配置方法如下圖：

3。修改并導出 wireshark 的默認數據包著色識別規則。通過數據包著色功能，用戶可以迅速定位感興趣的數據包分析，但是默認的著色規則太復雜，導致啟用色彩識別時，一個包列表中顯示“五顏六色”的信息，分散了我們的注意力，通常情況，我們僅對一種或兩種類型的數據包感興趣，或者進一步講，我們每次只需要標識一種或兩種類型的數據包顏色，這就需要修改其默認著色規則，具體配置方法參考下圖：

依序選擇菜單欄的“View”，“Coloring Rules”，打開配色規則對話框：

4。自定義數據包列表的顯示列。默認的顯示列從左至右依序為：數據幀編號，抓取時間，源地址，目標地址，協議，數據包（幀）長度，摘要信息。

在實戰場景中，這些列提供的信息可能不夠，例如，我想要快速瀏覽每個包的 IP 分組頭部的生存期（TTL）字段值，而且不用在每個包的詳細結構窗口（packet details）中查找該字段，以便節省時間，可以按照下圖操作：

依序選擇菜單欄的“Edit”，“Preferences”，打開首選項對話框：

5。根據實際需求配置 wireshark 的名稱解析功能。

依序選擇菜單欄的“Edit”，“Preferences”，切換到首選項對話框中的“Name Resolution”標簽，參考下圖解說進行配置：

通常只需要保持默認的不解析鏈路層，網絡層地址以及傳輸層端口號即可，但是有些時候就需要開啟相應的解析功能，還是那句老話：具體情況具體分析。上圖中沒有解釋到的名稱解析剩余的配置選項部分，各位可以自行研究。

6。隱藏 wireshark 主用戶界面的數據包字節窗口（Packet Btyes）

默認的用戶界面布局中，窗口被分隔成為3部分：數據包列表，數據包結構（詳情），以及數據包字節，后者以16進制的字節顯示數據包內容，通常是我們不必關心的，除非你有某種特殊的需求要修改原始的數據包；否則可以隱藏字節窗口，釋放額外的顯示空間。依序選擇“View”，取消勾選“Packet Bytes”即可。

7。wireshark 中與 IPv4 協議相關的配置參數

配置各種協議的參數，實際上就是改變 wireshark 對該協議數據包的“捕獲”與“呈現”方式。要配置 IPv4 協議，依序選擇菜單欄的

“Edit”，“Preferences”，展開首選項對話框中的“Protocols”標簽，定位到“IPv4”子標簽。參考下圖解說進行配置：

下面來比較一下，對于同一個數據包的 IP 分組頭部的 ToS 字段，wireshark 用舊的服務質量標準（服務類型）與用新的服務質量標準（即差異化／區分 服務）解析之間的區別，可以看出，兩者僅是對這個占一字節的頭部字段中，每個比特位的解釋不同而已：

8。wireshark 中與 TCP 協議相關的配置參數

要配置 TCP 協議，依序選擇菜單欄的

“Edit”，“Preferences”，展開首選項對話框中的“Protocols”標簽，定位到“TCP”子標簽。參考下圖解說進行配置：

（由于 TCP 協議規范相當復雜，而且各種操作系統有其不同的實現，下面的每個選項不一定在所有系統上都會產生描述中預期的結果，并且這里僅對一些重要，常見的 TCP 協議特性相關的選項配置進行說明，剩余的各位可以自行研究，理想情況下，在閱讀完《TCP/IP詳解》叢書后，應該能了解下圖中絕大多數的配置參數的含義）

下面通過圖片解析上圖中的一些配置選項的含義，首先是硬件校驗和，它與網卡硬件驅動程序提供的配置接口有關，在 windows 中如下所示：

通過 wireshark 支持的顯示過濾表達式：

tcp.checksum_bad == 1

可以僅顯示那些 TCP 校驗和錯誤（由 wireshark 或網卡驗證的）的數據包：

接著，讓我們分析“Analyze TCP sequence numbers”選項起到的作用：

再來，我們比較從 0 開始的 TCP 相對序號（由 wireshark “改寫”的）與隨機產生的絕對序號（由操作系統協議棧填充的真實序號）之間的區別：

也就是說，使用相對序號能夠讓我們更直觀地看出 TCP 序號（在整個 TCP 會話數據流中）起到的作用。

最后，解釋 TCP 協議中的一個很重要的概念：窗口縮放。

在 TCP 三次握手期間，雙方會通告自己的接收窗口大小（rwnd），以字節為單位，這通常是操作系統的協議棧的接收緩沖區的大小。rwnd 用于 TCP 的流量控制，簡言之，發送方每次（并行）發送的數據不能超過接收方向其通告的 rwnd 值，該值是動態變化的，隨著雙方每次發送的確認分段（ACK）而更新，這個過程將貫穿整個 TCP 會話的生命周期，這樣就可以實現動態調整雙方發送數據的速度：假設某一方的應用進程遲遲不讀取位于內核接收緩沖區的數據，那么在本次發送 ACK 的同時，會將 rwnd 的值調低一些并通告對方，后者就會按照更新后的 rwnd 為上限來發送數據；而等到應用取走緩沖區的數據后，就可以更新一個較大的 rwnd 值并在相應的 ACK 中通告對方。

在實際場景中，有時雙方在握手期間相互通告的初始 rwnd 值都過于“保守”，不能最大程度利用鏈路的峰值帶寬，常見的初始值為 8192 字節，這意味著在通信的早期階段，雙方同時并行發送的數據不能超過 8KBytes，假設往返時間為 100 毫秒，那么每秒發送的數據不超過 80KBytes，這相當于每秒發送不超過 53個 TCP 分段（一次“往”需要100毫秒，即每100毫秒一次，并行發送最多5個TCP 分段），再假設鏈路帶寬為 10MBits/s = 1.25MBytes/s ，也就是“理論上”該鏈路可以承載每秒 1.25MBytes 的數據吞吐量（或者說可以支持的 rwnd 上限為每 100毫秒 125KBytes，支持每100毫秒一次并行發送最多83個 TCP 分段），而實際的帶寬只有 80KBytes/s ，這就造成帶寬利用率偏低（6.4%）。

通過前面簡單的計算我們發現，如果不把 rwnd 增大到 125KBytes，很難充分利用

10M 帶寬的鏈路，因為即便通過 TCP 慢啟動效應逐漸增大初始擁塞窗口（每次能夠并行發送的 TCP 分段上限），可以從最初的每100毫秒一次并行5個到達每100毫秒一次并行83個的上限，但由于原始的 TCP 規范限制 rwnd 最大為 65KBytes（rwnd 字段在 TCP 頭部中占2字節，即16位，2的16冪為65536），實際最多也只能每100毫秒一次并行43個 TCP 分段（這還需要雙方“懂得”將 rwnd 增大到 65KBytes），浪費了50%的帶寬資源！

為了解決上述“理論帶寬”與“實際帶寬”不匹配的窘境，在 RFC 1323 標準中，引入了窗口縮放這個概念，窗口縮放是在 TCP 頭部的選項中，占３字節的字段，其中一個16進制字節用于表示“縮放因子”，取值從 00（當前 rwnd ＊2的0冪 = 當前 rwnd ＊1 = 不縮放）～0e（當前 rwnd * 2的14冪 = 當前 rwnd * 16384）

由于 rwnd 最大取值為 65536 字節，而縮放因子最大為 16384 倍，因此該標準支持的最大 rwnd 值為：65536 * 16384 = 1073741824 字節，即 1GBytes，這足夠有效地利用千兆（吉比特）帶寬的光纖鏈路了！

另外，該標準規定了窗口縮放因子必須在 TCP 三次握手過程中協商完成，此后都不許再更改協議好的值。通過窗口縮放，要充分利用前面 10M 鏈路的帶寬，以初始的 rwnd = 8KBytes 為例，僅僅需要將縮放因子設置為16進制的字節“04”即可

（2的4冪 = 16，８ * 16 = 128KBytes，已經超過了 125KBytes）

有了上面的基礎知識后，再來回顧 wireshark 中，與 TCP 窗口縮放相關的配置參數，就能夠輕松理解了：

最后還有一個 TCP 配置選項“calculate conversation timestamps”

它的作用是計算每個 TCP 會話中的每一幀（或 TCP 分段）相對于第一幀以及前一幀的時間戳（差），這對于檢測時間敏感型 TCP 應用，也就是用戶體驗度要求高的應用的性能會有幫助，效果如下所示：

剩余的4個 TCP 相關的配置選項各位可以自行研究，推薦先讀完tcpip詳解后再來理解效果會更好。

《關于TCP超時與重傳》

TCP 超時與重傳中，最重要的部分就是對一個給定連接的往返時間（RTT）的測量。由于路由器和網絡流量均會變化，因此我們認為這個 RTT 可能經常會發生變化，TCP 應該跟蹤這些變化并相應地改變其重傳超時時間（RTO，Retransmission TimeOut）。

發送報文段時會啟動RTT計時器，當接收到該報文段對應的ACK時，停止計時器，從而計算出RTT，然后根據這個RTT計算出TCP RTO，發送下一個報文段時，重傳計時器將根據最新的 TCP RTO 值，在超過該值表示的時間后還沒有接收到ACK，則重傳報文段。

實例解析：