《吐血整理》保姆級系列教程-玩轉Fiddler抓包教程(5)-Fiddler監控面板詳解

• 2022 年 7 月 14 日
• 筆記
• Fiddler

1.簡介

 按照從上往下，從左往右的計劃，今天就輪到介紹和分享Fiddler的監控面板了。監控面板主要是一些輔助標籤工具欄。有了這些就會讓你的會話請求和響應時刻處監控中毫無隱私可言。監控面板是fiddler最核心的功能之一。記錄了來自於伺服器端（webServer）的請求會話。包括頁面的請求和靜態文件的請求。狀態面板主要顯示的是會話及會話的狀態。

2.監控面板概覽

位於軟體介面右邊的這一大塊面板，即為輔助標籤 + 工具，宏哥稱之為監控面板，它擁有 10 個小標籤，如下圖所示：

3.輔助標籤 + 工具詳解

3.1Get Started 歡迎頁簽

左側START快速開始檢查數據包、構建請求；右側LEARN有Fiddler官方文檔、推薦部落格、學習Video；右側TOP ARTICLES顯示當前熱門文章。如下圖所示：

3.2Statistics

（Statistics）數據統計：顯示一些性能指標，這些性能指標有助於分析和優化web性能。用於查看請求的性能數據,統計與分析, 也就是說它就是對當前請求的性能分析數據。Http或Https請求的性能和其他數據分析，如DNS解析時間，TCP/TP建立連接的時間（TCP三次握手的時間）、SSL連接的時間（針對https請求）等資訊。當你點擊一個HTTP請求會話的時候，就可以看到Statistics裡面有關於當前HTTP請求的性能以及數據分析。

（1）請求總數、請求包大小、響應包大小。

（2）請求起始時間、響應結束時間、握手時間、等待時間、路由時間、TCP/IP、傳輸時間。

（3）HTTP狀態碼統計。

（4）返回的各種類型數據的大小統計以及餅圖展現。

1.例如: 一些TCP/IP的連接時間，DNS的解析時間、資源消耗、各個國家的請求網路頻寬對比等資訊。如下圖所示：

2.Show chart：把請求的數據以餅圖的形式顯示，如下圖所示：

2.Copy this chart：可以將該餅圖複製到剪貼板，粘貼到圖形處理軟體或者 WORD 中。

3.Collapse Chart：收起餅圖展示。

通過陳列出所有的HTTP通訊量，Fiddler可以很容易的向您展示哪些文件生成了您當前請求的頁面。使用Statistics頁簽，用戶可以通過選擇多個會話來得來這幾個會話的總的資訊統計，比如多個請求和傳輸的位元組數。

選擇第一個請求和最後一個請求，可獲得整個頁面載入所消耗的總體時間。從條形圖表中還可以分別出哪些請求耗時最多，從而對頁面的訪問進行訪問速度優化。

RTT（往返時間）：一個請求從發送時間到返回來的時間。是衡量一個請求的性能的一個重要的數據指標。

3.3Inspectors

（Inspectors）對請求解包：可以對抓到的請求包查看一些詳細的內容，例如：請求頭（Header）：包括用戶的使用的瀏覽器、請求攜帶的cookies、以及發送請求的域名。以不同的形式展示請求或部分請求報文、響應或部分響應報文。

你有沒有想過在Fiddler中如何快速查看http請求與響應報文呢?

其實當我們在會話列表中雙擊某一個會話請求就會自動跳轉到Inspectors選項卡。

也就是當抓包成功之後, 就可以在左側窗口中選擇你要查看的地址來進行查看抓取的http資訊數據，當選擇了相應的地址之後，在右側選項卡中 選擇Inspectors(檢查器), 然後再點擊一下Raw就可以按照原生形式來進行查看到相應的http請求報文與http響應報文, 分為上下兩個部分，上半部分是請求頭部分，下半部分是響應頭部分。如下圖所示：

3.4AutoResponder

（AutoResponder）文件代理：也叫自動攔截請求或者自動響應器，可以把想要的伺服器上返回的文件使用本地的文件做代理。可以定位線上bug。可用於攔截某一請求，進行如下操作：1、重定向到本地的資源，2、使用Fiddler的內置響應，3、自定義響應

它允許你攔截指定規則的請求，並把響應結果重定向到一個本地資源 或 直接使用Fiddler內置的資源，從而代替伺服器來自定義一個你想要的響應。 說白一點就是篡改響應。這個功能在我們做測試的時候也是非常有用的 ，使用它我們可以不影響用戶體驗的前提下進行測試。此功能啟用後，可以將某一請求的響應結果替換成指定的資源，可以是本地文件，也可以是 Fiddler 內置的各種 HTTP 響應。主要用於臨時攔截某一請求的響應，而無需修改伺服器上的環境和程式碼，保證在最真實的環境中進行調試，也無需在 BUG 查找的時候就尋求相關部門的配合。如下圖所示：

啟用該功能，請將 Enable rules打勾。Unmatched requests passthrough表示允許未匹配到的請求正常響應。應該打勾才能讓其他的請求繼續；否則其他未匹配到的請求都會以 404 狀態返回。

頁簽上部是一個規則編輯器，可以進行編輯當前用戶選擇的匹配規則、保存編輯、刪除此匹配規則等操作。如下圖所示：

 上邊Combox 要劫持的地址，是匹配的條件，可以自行輸入字元串，也可以選擇 Fiddler 內置的三個正則（都是匹配圖片的，沒什麼用）。

3.4.1Fiddler支援幾種匹配模式

Fiddler支援幾種匹配模式：

（1）String Literals —— 字元匹配：這種模式將匹配指定的字元串，不存在大小寫敏感。範例：

*
通配符，匹配任何地址，如： //www.example.com/Path1/query=example
EXAMPLE
匹配 //www.example.com/Path1/query=example
path1/
匹配 //www.example.com/Path1/query=example
query
匹配 //www.example.com/Path1/q=Query

（2）Exact Match —— 精確匹配：這種模式一 EXACT: 開頭，將嚴格匹配字元串，包括大小寫。範例：

EXACT://www.example.com/path
匹配 //www.example.com/path
不匹配 //www.example.com/Path（大小寫不符）
不匹配 //www.example.com/path/q=Query（有多餘字元串）

（3）Regular Expressions —— 正則表達式：這種模式一 regex: 開頭，使用正則表達式來匹配 session 的 URL。範例：

regex:.*
通配符，匹配任何地址，如 //www.example.com/Path1/query=example

regex:.*\.jpg —— 匹配包含 .JPG 的 URL
匹配 //www.example.com/Path1/query=foo.jpg&bar
匹配 //www.example.com/Path1/query=example.jpg

regex:.*\.jpg$ —— 匹配 .jpg 結束的 URL
不匹配 //www.example.com/Path1/query=foo.jpg&bar（不是 .jpg 結尾）
匹配 //www.example.com/Path1/query=example.jpg

regex:.*\.(jpg|gif|bmp)$ —— 匹配 .jpg 或 .gif 或 .bmp 結束的 URL
不匹配 //www.example.com/Path1/query=foo.bmp&bar（不是 .bmp 結尾）
匹配 //www.example.com/Path1/query=example.gif
不匹配 //www.example.com/Path1/query=example.Gif （是 .gif 結尾，但大小寫不匹配）
匹配 //www.example.com/Path1/query=example.bmp

regex:(?insx).*\.(jpg|gif|bmp)$ —— 匹配 .jpg 或 .gif 或 .bmp 結束的 URL，忽略大小寫
不匹配 //www.example.com/Path1/query=foo.bmp&bar（不是 .bmp 結尾）
匹配 //www.example.com/Path1/query=example.gif
匹配 //www.example.com/Path1/query=example.Gif
匹配 //www.example.com/Path1/query=example.bmp

下邊Combox是響應的結果，是真正要訪問的地址。可以選擇：Fiddler 內置的 HTTP 200/204/302/303/304/307/401/403/404/407/502 等各種響應範例、*bpu 和 *bpafter（ 表示在此中斷，關於 bpu 和 bpfater 見 QuickExec 命令參考）、本地文件 (Find a file…)。

Save 按鈕是保存對此匹配規則的修改，Remove 按鈕是刪除此匹配規則。

頁簽中間是一個列表，顯示當前創建的匹配規則，左側是匹配的條件，右側是響應的結果。即：如果請求的地址包含左側的字元串，那麼就用右邊設定的資源來替換來自伺服器的響應。如下圖所示：

對匹配規則操作，可以選中匹配規則，右鍵點擊對應的操作即可，如下圖所示：

3.4.2增加匹配規則

具體操作步驟如下：

1.在AutoResponder面板下，點擊，單擊選擇需要攔截的請求，複製請求的URL（請求右鍵 >> Copy >> Just Url），粘貼至右側面板Rule Editor（或者左鍵按住，並拖動需要請求的url到右側面板，此時url自動填充在Rule Editor處）

2.設置響應的內容，可以選擇Fiddler的內置響應或者是用戶本地文件（或者點擊規則，滑鼠右鍵，選擇Edit Response，進行自定義響應）

3.同時選中（使用規則）和（放行未匹配的請求）。

或者這樣操作也可以：

點擊 Add rule,打勾Unmatche按鈕，新增一條規則。

此時會激活頁簽底部的 Rule Editor。如果你在 Web Sessions 面板里選擇了一個 Session，則匹配規則是該 Session 的 URL，否則是 StringtoMatch[數字]。然後可以使用 Rule Editor 編輯它。

點擊 Import… 按鈕，導入在 Web Sessions 中保存下來的壓縮包 (*.saz)。

在 Web Sessions 面板中選擇你要捕獲的請求，直接拖拽到 AutoResponder 的列表中。

3.5Composer

（Composer）前後端介面聯調：可以偽造數據進行請求。可以不介入寫任何JavaScript程式碼的情況下就可以實現與伺服器之間的介面調試。　設計請求，修改請求參數，進行簡單的介面測試。具體操作：滑鼠左鍵拖動請求的url至右側Composer面板處，請求資訊會自動填充，修改請求參數，點擊Execute。做前後端的介面聯調實際上就是用的Composer功能。

我們可以把請求拖進去，我們就可以看到請求參數就調了進去，我們可以通過修改請求參數重新向伺服器發送請求，比如刪掉referer刪掉，點擊excute，實際上就算偽造了一個請求。

它可以允許我們自定義請求報文來發送到服務端，當然也可以手動創建一個新的請求，也可以從會話列表中拖拽一個現有的請求去發送!

在Parsed(解析模式)下我們只需要提供簡單的URL地址就可以了, 並且還可以在RequestBody中去訂製一些屬性，例如模擬瀏覽器消息頭User-Agent

但是Composer通常在我們開發項目當中用於介面測試 也是經常用於測試一些api介面的最好方法!

當然有時候也可以通過Composer來校驗後端介面的嚴謹,從而跳過一些前端的限制,去直接訪問後端程式碼的邏輯，如下圖所示：

Composer下還有幾個子集選項卡:Parsed、Raw、Scratchpad、Options。具體解釋如下表所示:

我們用得最多的就是Parsed，詳細展示請求結構如下圖所示：

3.6Fiddler Orchestra Beta

Fiddler Orchestra Beta頁簽是新版fiddler新增功能，用於抓包遠程電腦的數據，其中Fiddler Orchestra涉及到兩個角色，控制器（Controller）和客戶端（Client），控制器就是我們正在使用的Fiddler軟體，其功能是用來收集數據和控制任何一個客戶端，而客戶端則是向任何其運行所在的Windows，Linux，Mac主機上收集接收過來的流量將其通過加密的方式報告發送給控制器，控制器會在Fiddler軟體上的會話端顯示。如下圖所示：

3.7Fiddler Script

打開Fiddler腳本編輯。如下圖所示：

3.8log

記錄Fiddler的log日誌。用來收集日誌消息字元串，這些字元串是由擴展、FiddlerScript或者Fiddler本身生成的。Fiddler會記錄應用事件（如當保存或載入SAZ文件）以及系統事件（如系統的網路連接丟失或者恢復）的響應通知。如下圖所示：

Log支援簡單的宏命令，可以從QuitExec文本框中調用這些命令。輸入[email protected]可以清空日誌。輸入[email protected]可以在會話列表中生成新的會話，該會話的響應體包含Log選項卡的文本。輸入log”@Log.Erport\”filename\””可以把Log選項卡的文本保存到指定的文件。文件名以.rtf結尾，可將文件保存為富文本格式，保存大小和權重，或者以文件名以.txt結尾保存的純文本。

3.9Filters

Filters多維度的過濾規則，可根據主機、進程、請求頭、響應頭、狀態碼、響應類型和大小、斷點進行請求的過濾。作用：忽略不想顯示的請求，過濾出想要的請求，是一個多維度的過濾器。過濾器要起作用，必須選中。

Filters中文意思就是過濾的意思, 它的主要作用就是用來過濾請求用的， 要知道有的時候 會話列表中或存在大量的請求會話, 那麼有些時候會根據用戶的條件進行一個會話篩選, 也就是說通過過濾規則來過濾掉那些不想看到的請求。

Filters選項卡也是在我們抓包過程中使用頻率非常高的，其中功能也比較多，這裡我把它內部的功能逐一拆解分成7個部分來進行講解。具體功能如下圖所示：

3.9.1Hosts

Hosts這是Filters對主機的過濾規則配置。如下圖所示：

1.使用Filters的時候就必須要勾選左上角的Use Filters(選擇過濾器)開啟過濾器, 勾選了之後Filters選項卡會出現綠色對鉤, 記住這個勾選之後，過濾器才會生效，否則後邊的7大部分都是灰色的不允許配置和操作。

2.「Action」按鈕功能如下圖所示：

「Run Filterset now」：根據設置過濾已存在的Session列表；

「Load Filterset」：打開本地Filters配置文件；

「Save Filterset」：保存當前配置到本地；

「Help」：打開官方文檔；

註：Filters配置後，是即時生效的。

並且Hosts這裡還有兩個請求過濾條件:Zone和Host。

（1）Zone(區域): 下拉列表中可以選擇如下:

　　①、No Zone Filter：無區域限制，不用區域過濾（默認設置，一般無特殊要求就用默認的）

　　②、Show only Intranet Hosts：僅顯示區域網的請求（一般不用）

　　③、Show only Internet Hosts：僅顯示廣域網的請求（一般不用）

如下圖所示：

接下來和宏哥通過一個請求百度這個例子來直觀的看一下這幾個選項到底什麼意思了，如下圖所示：

從上圖中我們可以清楚地看出：如果設置為了No Zone Filter那麼內網和外網的請求都可以獲取到，如果設置為了show only Intranet Hosts 那麼外網的請求會話是無法獲取到的,僅僅能獲取內網請求，如果設置為了show only Internet Hosts那麼相反也僅僅能獲取外網的請求，而內網的請求是無法獲取到的。

平常如果我們沒有其他特殊需求的情況下Zone都被默認設置為了No Zone Filter(不用區域過濾)

注意:各位要留意 Intranet(內網) 和 Internet(網際網路) 這兩個單詞很多人容易搞混!

（2）Host(主機):下拉列表中可以選擇如下:

　　①、No Host Filter：無主機限制

　　②、Hide the following Hosts：隱藏輸入到下面文本框的主機（域名或者IP）的請求（選擇請求，單擊右鍵，Copy >> This Column）

　　③、Show only the following Hosts：僅顯示輸入到下面文本框的主機（域名或者IP）的請求

　　④、Flag the following Hosts：含有下面文本框的主機（域名或者IP）的請求做標記（即加粗顯示）

 如下圖所示：

同理為了直觀宏哥這裡再舉例說明比如說: 我設置其中一個show only the following Hosts (僅展示以下指定主機的請求) 那麼會話列表中只會出現我所指定的主機請求會話，其他一概不顯示。

注意: 這裡設置之後 要點擊一下Actions中的Run Filterset now(運行過濾)

如下圖所示：

另外兩個根據自己需求設置就行了, 平常沒特殊需求我們也是設置的No Host Filter。

3.9.2Client Process（應用比較少）

 Client Process 這是對客戶端進程的一些過濾配置。如下圖所示：

從上圖可以清楚地看到有三個複選框：

①、Show only traffic from：僅顯示某一進程的請求

②、Show only Internet Explorer traffic：僅顯示IE瀏覽器發出的請求

③、Hide traffic from Service Host：隱藏來自service host（即由svchost.exe進程）發出的請求

宏哥這裡勾選：Show only Internet Explorer traffic的選項，看一下是否是：僅顯示ie瀏覽器的請求會話,其他瀏覽器的請求會話一概不顯示。如下圖所示：

3.9.3Request Headers

Request Headers這是對請求頭的一些過濾規則進行配置。如下圖所示：

從上圖可以清楚地看到有五個複選框：

①、Show only if URL contains：僅顯示url中包含輸入的字元串的請求（可以是url的一部分、正則、或完整的URL）

②、Hide if URL contains：與①相反，隱藏url中包含輸入的字元串的請求

③、Flag requests with headers：標記請求頭中有指定內容的請求，用頭標記請求, 標記帶有特定header的請求，如果在web session列表中存在該請求,會加粗顯示。 例如，我想突出顯示header資訊中帶有cookie欄位的URL請求,即可以勾選上這項,並在後面輸入：cookie。

④、Delete request headers：刪除請求頭中的指定內容，也就是說在請求的過程當中會刪除指定的Header欄位。我們在進行測試時非常有用，比如說去掉URL中的Content-Type資訊。

⑤、Set request header：設置請求頭中添加指定的內容，也就是說可以在請求頭中自定義請求頭資訊，前面輸入欄位，後面輸入值, 這就是我們可以進行自定義請求頭內容。

宏哥這裡勾選：show only if URL contains只會顯示指定包含這個內容的響應會話，如下圖所示：

3.9.4Breakpionts

 Breakpionts 斷點配置，這個功能有的時候也非常重要。後邊宏哥會詳細介紹這一部分的內容的。如下圖所示：

從上圖可以清楚地看到有四個複選框：

①、Break request on POST：在POST請求中設置斷點（請求前設置斷點）

②、Break request on GET with query string：在帶有請求參數的GET請求中設置斷點（請求前設置斷點）

③、Break on XMLHTTpRequest：在Ajax請求中設置斷點（請求前設置斷點）

④、Break response on Content-type：在響應中含有指定Content-type的請求中設置斷點（響應後設置斷點）

3.9.5Response Status Code

 Response Status Code(響應狀態碼過濾)，這一部分的功能，很簡單就是看狀態碼進行會話的過濾配置。如下圖所示：

 從上圖可以清楚地看到有五個複選框：

①、Hide success(2xx)：隱藏響應狀態碼為2XX的請求

②、Hide non-2xx：隱藏響應狀態碼非2xx的請求

③、Hide redirects(300, 301, 302, 303, 307)：隱藏狀態碼為300、301、302、303、307的重定向請求

④、Hide Authentication demands(401,407)：隱藏狀態碼為401，407的響應。需要用戶進一步確認證書的請求

⑤、Hide Not Modified(304)：隱藏狀態碼為304的響應，隱藏不是快取的狀態碼（304）的URL請求, 因為304是請求的資源從上次起沒有發生變更返回的狀態碼。

3.9.6Response Type and Size

 Response Type and Size：根據響應類型和大小進行過濾配置。如下圖所示：

  從上圖可以清楚地看到有很多選項：

Show all Content-Type 這一項比較常用, 意思為顯示所有指定Content-Type類型的請求，其中的選項描述如下表:

其他功能項如下表：

1.宏哥禁止掉頁面上的css js 圖片等資源看看請求的結果，如下圖所示：

2.那麼此時請求的頁面將會失去css 、js、圖片等資源, 讓他們都響應為404狀態，看看響應結果，如下圖所示：

3.9.7Response Headers

Response Header ：根據響應頭資訊進行過濾配置。如下圖所示：

  從上圖可以清楚地看到有四個複選框：

①、Flag responses that setcookies：將響應中設置了cookies的請求標記顯示（斜體顯示）

②、Flag responses with headers：將響應頭中包含指定內容的請求標記顯示（加粗顯示）

③、Delete responseheaders：刪除響應中指定的響應頭

④、Set response header：將響應頭中添加指定的內容

3.10Timeline

（Timeline）網站性能分析：需要選中網站的多條請求才有意義，是性能優化的重要依據之一。Timeline 頁簽：顯示 session 請求到響應的時間表，橫向為時間軸，縱向為 session 列表，滑鼠移到 timeline 頁簽上，在底部會顯示四個數據：session 編號和 URL、session 的響應類型、發送位元組數和接收位元組數。每個網路請求都會經歷域名解析、建立連接、發送請求、接受數據等階段。把多個請求以時間作為 X 軸，用圖表的形式展現出來，就形成了瀑布圖。在Fiddler中，只要在左側選中一些請求，右側選擇Timeline標籤，就可以看到這些請求的瀑布圖。如下圖所示：

時間軸

綠色的請求表示這是一個「有條件的請求」。HTTP 協議定義了 5 個條件請求頭部，最常見的兩個是「If-Modified-Since」和「If-None-Match」。伺服器根據這兩個頭部來驗證本地快取是否過期，如果過期則正常返回資源的最新版本；否則僅返回 304 Not Modified，瀏覽器繼續使用本地快取。包含條件請求頭部的請求用綠色顯示，否則用黑色。

有陰影線的請求是緩衝模式下的請求，實心的是流模式下的請求。Fiddler 提供了緩衝（Buffering）和流（Streaming）兩種抓包模式：緩衝模式下，Fiddler 會在響應完成時才將數據返回給應用程式（通常是瀏覽器），這種模式下可以控制響應，方便地修改響應內容；流模式下，Fiddler 會實時返迴響應數據給瀏覽器，但沒辦法控制響應。一般使用流模式，瀑布圖會更真實一些。這兩種模式可以通過 Fiddler 的工具欄選擇。特別的，通過 Fiddler 的「AutoResponder」功能返回的響應，只能是緩衝模式。

請求條的不同顏色對應著不同類型的響應，根據響應頭的 MIME Type 來歸類。如淺綠色表示圖片類型的響應；深綠色是 JavaScript；紫色是 CSS；其它都是藍色。

請求中的黑色豎線，表示的是瀏覽器收到服務端響應的第一個位元組這一時刻。這個時間受 DNS 解析、建立連接、發送請求、等待服務端響應等步驟的影響。

請求條後面的圖標表示響應的某些特徵。如軟盤圖標表示這個響應正文從本地獲得，也就是說服務端返回了 304；閃電錶示這是 Fiddler 的「AutoResponder」的響應；向下的箭頭表示響應是 302，需要重定向；紅色感嘆號說明這個請求有錯誤發生（狀態碼是 4XX 或 5XX）。特別的，如果請求條後面有一個紅色的X，說明服務端響應完這個請求之後，斷開了連接。出現這種情況一般有兩種可能：HTTP/1.0 的響應中沒有 Connection: Keep-Alive；或者是 HTTP/1.1 的響應中包含了 Connection: close。使用持久連接可以省去建立連接的開銷，也可以減小 TCP 慢啟動和其它擁塞控制機制帶來的影響，總之是好處多多。

請求前面的紅色圓圈表示這個連接是新建的，綠色表示是復用的。上面的圓圈表示的是瀏覽器到 Fiddler 的連接，下面的圓圈是 Fiddler 到服務端的連接。

關於請求的時間分析，HttpWatch 的時間線顯得更為詳盡和直觀，不過它是收費的，且最新版本 6.0 + 也只支援 IE 和 Firefox。

4.小結

有些小夥伴或者童鞋們在使用Fiddler的時候出現抓包失靈的情況，可能就是你在Filters選項卡中勾選了什麼東西才導致的! 所以使用過濾器要注意一下。