Web調試技術詳解

• 蘇格團隊
• 做者：Jonny

1、調試技術的起源

對於每位開發者而言，bug已是不能再尋常的東西，debug也是屢見不鮮的事情。然而尋根溯源起來，還得從上個世紀五十年代講起。

1947年9月9日，哈佛大學在測試馬克II型艾肯中繼器計算機的時候，一隻飛蛾粘在一個繼電器上，致使計算機沒法正常工做，操做員把飛蛾移除以後，計算機又恢復了正常運轉。因而他們將這隻飛蛾貼在了他們當時記錄的日誌上，並在日誌最後寫了這樣一句話：First actual case of bug being found。這是他們發現的第一個真正意義上的 bug，這也是人類計算機軟件歷史上發現的第一個 bug。他們也提出了一個詞，「debug（調試）」了機器，由此引出了計算機調試技術的發展。

2、Chrome 開發者工具

對於web前端而言，咱們天天都在使用開發調試工具進行查看dom結構、js斷點和查看分析登陸請求等操做，最熟悉的開發調試工具 應該莫過於Chrome的Devtools和Firefox的FireBug了。

Chrome 開發者工具實際上是一個用 HTML，JavaScript 和 CSS 寫的 Web 應用程序，被集成在瀏覽器中。其基於遠程調試協議，與瀏覽器架構關係以下：

由圖可知：

• 遠程調試協議基於 WebSocket，利用 WebSocket 創建鏈接 DevTools 和瀏覽器內核的快速數據通道
• 瀏覽器擁有多個 Tab，併爲每一個 Tab 單獨提供 Websocket 的 Endpoint URI
• 每一個 DevTool 實例只能檢視一個 Tab，即只能與一個 Tab 保持通信

事實上，Chrome開發者工具不只只是能夠在當前的瀏覽器頁面直接打開，它做爲一個客戶端（開源），也能夠用來調試任何支持遠程調試協議的瀏覽器。

使用文檔：developers.google.com/web/tools/c…

github倉庫：github.com/ChromeDevTo…

3、遠程調試協議（remote debugging protocol）

遠程調試協議Webkit 在 2012 年就已經引入，目前全部 Webkit 內核的瀏覽器都支持這一特性。遠程調試協議基於 WebSocket，利用 WebSocket 創建鏈接 客戶端（如DevTools） 和瀏覽器內核的快速數據通道，Chrome的Devtools僅僅只是Webkit遠程調試協議的一個應用案例。

1. 通信模式和消息結構： 對於每一個頁面的全部操做，遠程調試協議將其劃分紅了不一樣的命令域，如Browser、Dom、Debugger和Network等等，每一個域定義了不一樣的命令和事件。在開發調試過程當中，瀏覽器內核和遠程客戶端經過WebSocket發送消息進行通訊，消息基本上分兩種格式，一種是含有 message id 的，另外一種是不含 message id 的，分別表明倆種通信模式：

• request/response：就如同一個異步調用，經過請求的信息，獲取相應的返回結果。這樣的通信必然有一個 message id，不然兩方都沒法正確的判斷請求和返回的匹配情況。

• notification：和第一種不一樣，這種模式用於由一方單方面的通知另外一方某個信息。和 「事件」 的概念相似。

2. Chrome的上層封裝： 爲了更加方便Chrome extension的開發，Chrome調試器擴展API提供了更高級別的API ——Chrome Debugger API。此API隱藏請求ID並處理請求與其響應的綁定，所以容許sendCommand在回調函數調用中處理結果。每一個 command 包含 request 和 response 兩部分，request 部分指定所要進行的操做以及操做說要的參數，response 部分代表操做狀態，成功或失敗。

以Debugger Domain爲例，

• command結構以下：

• 事件結構以下：

協議文檔：chromedevtools.github.io/devtools-pr…

Debugger API： developer.chrome.com/extensions/…

咱們能夠經過devtools來查看Devtools Extension與瀏覽器內核實際通訊的數據狀況，步驟以下：

一、開啓開發者工具實驗模式：

• 瀏覽器進入chrome://flags
• 找到Developer Tools Experiments
• 狀態改成enable
• 重啓瀏覽器

二、打開協議監控tab

• 點擊devtools工具右上角菜單圖標，進入「settings」，左邊選擇「Experiments」tab，將「Protocol Monitor」打上勾
• 關閉devtools後從新打開，點擊devtools工具右上角菜單圖標，再進入「More Tools」，選擇「Protocol monitor"

以後咱們即可以看到:

4、Chrome的遠程調試模式:

從上面咱們已經知道，Devtools是如何基於遠程調試協議與瀏覽器內核進行交互的了，然而，不只僅如此，Chrome還能夠開啓遠程調試模式，容許外部客戶端（支持遠程調試協議）對其進行調試。

1. 協議Server端：

首先，以遠程調試模式打開Chrome:

./chrome --remote-debugging-port=9222

以後調試數據會轉發到本地9222端口，瀏覽器輸入localhost:9222/json能夠看到：

其中咱們能夠看到每一個tab頁面對應的websocket url，經過該url創建鏈接即可以和系統內核進行通訊了。

2. 協議客戶端：

咱們能夠採用Chrome內置的工具與其創建鏈接進行調試，步驟以下：

1）打開Chrome 內置客戶端，在瀏覽器輸入：

http://localhost:9222

能夠看到如下界面:

2）或者在chrome://inspect界面，咱們能夠發現，此時本地瀏覽器也能夠被做爲一個remote device來調試了。

3）咱們也能夠採用一個外部的調試工具，如node程序，vscode插件等，經過從9222端口獲取到各個頁面的json數據，而後進行websocket鏈接進行通訊，進行實現各類豐富的開發調試功能。

5、移動端遠程調試技術：

從上面看，chrome等瀏覽器的遠程調試模式彷佛有點雞肋，我都有Devtools工具了，何須還要畫蛇添足去開啓遠程調試模式用其餘工具來調試。別急，遠程調試模式真正發揮做用的仍是移動端設備的調試場景。移動端設備有運行環境，卻沒有合適的開發和調試環境，藉助於webkit的遠程調試模式，可使得咱們很方便的查看和調試移動端設備。

移動端web遠程調試技術不少種，像weinre等在代碼中嵌入腳本的就不說了，咱們以基於webkit遠程調試協議的方式來說解。 從上面咱們已經知道，移動端chrome開啓遠程調試模式後json數據會被打到debugging端口（localhost:9222），由於安全考慮，chrome限制了只能是本地localhost的，不能打到指定ip之上。此時，須要經過某種方式，將移動端9222端口的數據綁定到pc端，以後才能PC端即可以經過PC端本地端口與移動端頁面進行調試。

一、端口綁定方式：

• 有線（USB線）：以webkit爲內核的移動端瀏覽器，開啓瀏覽器遠程調試功能以後經過usb鏈接到pc端，以後經過adb進行端口綁定：

adb forward tcp:9222 localabstract:chrome_devtools_remote

• 無線（network）：經過ssh 進行端口轉發，本方式適合移動端支持ssh鏈接登陸。

#在本地主機A1登錄遠程雲主機B1，並進行本地端口轉發。2000端口綁定本地全部網卡 ssh -L 2000:localhost:3000 root@192.168.*.*

6、調試服務器腳本（node程序）：

2016年，Node將 Chrome瀏覽器的"開發者工具"做爲官方的調試工具，使得 Node 腳本也可使用圖形界面調試，這大大方便了開發者。開啓調試方式以下：

node --inspect --debug-brk index.js

而後經過chrome://inspect能夠看到app.js的調試入口，打開以後出現Devtools的定製版，只有四個Tab，移除了和服務器腳本調試無關的部分。

能夠發現，node腳本調試的原理與chrome js腳本類似，其內置V8支持遠程調試協議，開啓調試後做爲一個server端，devtools客戶端經過websocket與其創建鏈接進行通訊。

6、總結

至此，咱們已經介紹了本地調試和遠程調試已經隱藏在其背後的通信原理。遠程調試協議做爲一個強大的通用的協議，支持了不一樣server或客戶端的通訊。

瀏覽器的調試，其實最後都落腳到引擎：渲染引擎和 JavaScipt 引擎。對於css的修改、js的斷點等，如何落實到渲染引擎上，上下文環境切換，函數調用棧追蹤等等，還有更多東西值得挖掘。