善用 Web 調試代理工具

圖靈社區 : 閱讀 : 善用 Web 調試代理工具

善用 Web 調試代理工具推薦 12 收藏

原文地址：Using Web Debugging Proxies

當我們調試前端代碼的時候，通常會在檢查CSS和JavaScript如何渲染頁面上花費大量時間，但是瞭解網路請求對頁面的影響也同等重要。很多情況下由於我們在本地開發，可能會忽略頁面的大小、延遲以及指令碼的載入和阻塞對網站使用者體驗的巨大影響。因此，一套得心應手的網路流量檢查工具是必不可少的。

幸運的是，所有主流瀏覽器都提供了可以查看網路流量的調試工具，而且第三方工具比如 Fiddler 和 Charles 不僅允許查看網路請求，而且還提供了可以跟網站互動的擴充功能。

下面我們會對兩種類型的工具分別進行介紹。

基於瀏覽器的流量嗅探

正如我提過的，每個主流瀏覽器都有內建的調試工具。它們包括：

• Internet Explorer 的 F12 開發人員工具
• Firefox 的 Web開發人員工具以及 Firebug 附加組件
• Chrome 的 開發人員工具
• Opera 的 Dragonfly
• Safari 的 Web檢查器

（譯者註：關於這些工具，還可參見譯者的另一篇文章。）

每個工具集都有自己獨特的功能，並且它們都有搜集網路流量資訊的能力。看一下下面幾張圖，你會發現儘管UI不盡相同，但搜集和顯示的資料卻非常相像。

最終的結果就是，一個由瀏覽器下載的資源或資料而產生的網路請求所組成的列表。網路工具可以截獲這些請求並將主要的資料展示給你：

• 請求類型（GET，POST 等等）
• 請求的是什麼
• URI
• 狀態
• 大小
• 完成請求所耗時間

因此，如果我們在 Firebug 中查看結果，可以看到這些請求拉回了首頁面以及相關的CSS和JavaScript檔案，包括亞馬遜AWS上的資源。由於圖片的限制，我無法向你展示全部載入內容，不過這裡也還返回了圖片和Flash swf檔案。

深入研究

有了這些資訊後，就可以深入查看特定的請求，確定是否接收到了正確的資料，以及查看為什麼會有耗時很長的請求。假設我查看Webtrend的JavaScript檔案請求。它耗時1.2秒下載，並且我想看看請求是如何被處理的。我可以展開該請求，看看它是使用gzip壓縮（是的）：

和是否被最小化壓縮（minified）：

本例中的檔案並沒有被最小化壓縮，然後我就可以找開發人員跟進看這樣做是否合理。誠然，這隻是個2k的檔案，不過每個位元組其實都很重要，這些資訊可以讓我們更好地最佳化網站。

網路計時

網路延時可以成為致命殺手，尤其是對於那些依賴外部API或者多個指令檔來實現功能的單頁面應用（single-page apps）。大部分瀏覽器會儘可能地非同步載入資源，但是有些資源比如JavaScript檔案，可以觸發阻塞事件。儘可能地限制這些檔案，並以此來最佳化資源載入至關重要。如果我們看一下這張圖，就會發現這個檔案花費了1.4秒用來載入：

當懸停在時間軸上的時候，會出現一個對話方塊，展示了請求被處理的分解資訊：

部分原因是由於它被阻塞了760毫秒。如果這是個普遍存在的問題，你可以嘗試使用指令碼載入器（比如 RequireJS）來更好地管理指令碼載入和依賴關係。

Ajax請求

由於Live App無處不在，因此能夠查看XHR調用就至關重要了。之前你已經見識過無數的網路請求，試圖過濾這些請求並從中找出XHR調用並不高效。因此，大部分工具允許你按請求類型查看。這裡我是根據XHR請求過濾的，因此我可以評估請求和響應：

通過深入查看請求資訊，我可以獲得請求的重要細節，比如要求標頭、狀態、要求方法、cookies，更重要的是可以看到該請求返回的資料：

本例中返回的是HTML，不過響應可以是包括文本、JSON或XML在內的任何內容。更棒的是在我遇到任何問題時，都可以充分地查看請求細節。

Cookies

Cookies真的非常有用，由於我們會廣泛地用到它，因此一個方便地查看Cookie值的方法將使生活變得更輕鬆。開發人員工具即可輕鬆實現這些，它可以展示哪些Cookies被發送或者接收了。

如果你曾經做過伺服器端開發而沒有用戶端工具相伴，你就會知道這有多爽了。

總之，最棒的就是這些功能都內建在你的瀏覽器中，使開啟工具調試和查看細節都變得無比便捷。然而，有時你還需要多一點馬力。

第三方HTTP代理工具

HTTP代理程式如 Fiddler 和 the Charles Web Debugging Proxy 是基於瀏覽器的網路流量嗅探工具的老大哥。它們不僅能截獲來自瀏覽器的網路請求，也能截獲你機器上其他程式的網路請求，這使得它們在調試方面用途廣泛。通常它們也會提供更豐富的特性，比如：

• 頻寬節流設定
• 特定請求的自動響應
• 傳輸過程中的資源替換
• SSL代理
• 外掛程式生態系統
• 可自訂的指令碼
• 記錄和回放測試情境

我常用基於Windows的、功能豐富的 Fiddler（免費的！）。由於其強大的特性集合，在微軟內部的使用也很廣泛。Fiddler的開發人員 Eric Lawrence 之前就在微軟工作，並且仍然維護著該軟體。

如果我們看下介面，就會發現與那些瀏覽器工具類似的輸出。所有的網路請求都按照關鍵資訊顯示。

深入查看某個請求，可以看到更多的細節，包括壓縮後jQuery原始碼：

大部分這種資訊也可以通過基於瀏覽器的工具擷取到，但是當你想確定是不是某個庫搞垮了你的網站的時候怎麼辦？你可以直接換掉這些庫來進行定位。一個較好的路徑就是建立一個Fiddler自動響應器（AutoResponder），攔截並替換掉生產環境中的庫。Fiddler會接收這個請求並將其替換為本地檔案。下面我們就來一探究竟。

首先，我需要標識出需要替換的URI。在本例中，我看到我的部落客題使用了jQuery v1.2.6。真是瘋了，不過在我丟掉它之前，需要看一下jQuery v1.8.3是否能如預期一樣正常工作。

我點擊 jQuery v1.2.6 這條記錄，在 Fiddler 的右欄中，選擇“AutoResponder”頁卡並選擇“Enable automatic responses”。可以直接將URI拖拽到規則編輯器中。你會發現規則是從比較URI開始的。如果匹配，它將以你選擇的某個事件作為響應。

由於我想測試的是 jQuery 1.8.3，我希望這條規則可以用我本地的jQuery副本替換生產環境的版本。

儲存這條規則並重新整理我的頁面。最終結果是，儘管URI可能看上去相同，檢查結果可以驗證 jQuery v1.8.3 實際上已經嵌入了。這樣我就可以在不對網站進行任何更改的情況下直接測試了。

從調試的角度來講，這種功能無比實用，尤其是當你想定位一個藏在老版本架構或庫中的bug時候。

附加組件生態系統

Fiddler從它的附件組件生態系統中獲益良多，這個系統通過iFiddlerExtension介面為Fiddler擴充功能。目前有如下功能的附加組件：

• 壓力測試
• 安全審計
• 流量對比用來對比概況
• JavaScript格式化

對於它本身來說，Fiddler擁有無數特性，實在無法在本文一一列舉。這就是為啥有個330頁的書來教你如何用好它的原因了。這本書只有10美元，即可讓你從內到外掌握這個偉大的工具。

OSX 和 Linux

如果你在用OSX或者Linux，那麼最佳選擇就是Charles Web調試代理工具。該工具支援廣泛並且商業化成熟，每一分錢都花得很值得。我曾尋找過專註於web開發的替代品，而Charles卻脫穎而出。

介面跟Fiddler很類似，不過它提供了兩種不同的方式查看網路流量：

樣式完全隨你，我更傾向於結構化視圖，因為感覺它更有條理，不過搜尋特定的URI就稍有不便。

與Fiddler類似，Charles也提供了自動響應功能，叫做“Map Local…”，可以通過滑鼠右擊某個URI呼出。該功能允許你選擇一個本地檔案進行工作。

當重新整理頁面後，我的jQuery v1.2.6就被我本機上的jQuery v1.9替換掉了。

Charles另外一個極好的特性就是，它可以抑制網路請求來類比特定的頻寬速度。仍記得使用56K貓時的那些令人捉急的日子，使用這個功能可以讓你盡情追憶似水年華：

Chares也提供了一個跨平台的介面，因此也可以在Windows上工作。

該用哪一個

所有這些工具我每時每刻都在用，因為我需要測試每個主流的瀏覽器，有了這些功能著實可以使問題定位更容易些。當然，是選擇基於瀏覽器的嗅探工具，還是基於應用程式的代理工具完全取決於你的調試需要。

如果你只需要檢查某些流量並查看結果，那麼基於瀏覽器的嗅探工具可能是你的最佳選擇。

另一方面，如果你需要精確控制URI如何響應，或者希望可以靈活地建立自訂指令碼，那麼像Fiddler或Charles這種工具才是你需要的。令人欣慰的是，我們有穩定的備選方案可以協助我們實現這些功能，尤其是當項目複雜度日益增加時，也不會感到無力。