The Chrome DevTools Protocol allows for tools to instrument, inspect, debug and profile Chromium, Chrome and other Blink-based browsers. Many existing projects currently use the protocol. The Chrome DevTools uses this protocol and the team maintains its API.
Instrumentation is divided into a number of domains (DOM, Debugger, Network etc.). Each domain defines a number of commands it supports and events it generates. Both commands and events are serialized JSON objects of a fixed structure.
Chrome DevTools protocol 分成幾個不同的部分（DOM，Debugger，Network 等）
Protocol API Docs
The latest (tip-of-tree) protocol (tot) — It changes frequently and can break at any time. However it captures the full capabilities of the Protocol, whereas the stable release is a subset. There is no backwards compatibility support guaranteed for the capabilities it introduces.
v8-inspector protocol (v8) — It is available in node 6.3+ and enables debugging & profiling of Node.js apps.
stable 1.2 protocol (1-2) — The stable release of the protocol, tagged at Chrome 54. It includes a smaller subset of the complete protocol compatibilities.
stable 1.3 protocol (1-3) — The stable release of the protocol, tagged at Chrome 64. It includes a smaller subset of the complete protocol compatibilities.
協議的API文檔
最新的協議（不穩定），
V8-inspector protocol，
1.2版本穩定協議，
1.3版本穩定協議
注： 之所以文章中這么分，我理解是 V8-inspector protocol是Chrome devtools protocol(CDP)的一部分，
因為V8是Chrome的js引擎，所以其是CDP的一部分
nodejs也使用v8，nodejs內部實現了v8 inspector，可以和一個實現了Chrome DevTools Protocol的debugger客戶端來交互
(https://www.cnblogs.com/eret9616/p/12181700.html)
Resources
The devtools-protocol repo issue tracker can also be used for concerns with the protocol. It also hosts the canonical copy of the json files.
Useful: Getting Started with Headless Chrome and the Headless Chromium readme.
The chrome-remote-interface node module is recommended, and its wiki and issue tracker are full of useful recipes.
The awesome-chrome-devtools page links to many of the tools in the protocol ecosystem, including protocol API libraries in JavaScript, TypeScript, Python, Java, and Go.
Consider subscribing to the chrome-debugging-protocol mailing list.
一些相關資源
Basics: Using DevTools as protocol client
The Developer Tools front-end can attach to a remotely running Chrome instance for debugging. For this scenario to work, you should start your host Chrome instance with the remote-debugging-port command line switch:
chrome.exe --remote-debugging-port=9222
Then you can start a separate client Chrome instance, using a distinct user profile:
chrome.exe --user-data-dir=<some directory>
基礎：使用Devtools作為協議的客戶端
DevTools 前端可以attach 到一個遠程運行的Chrome實例，來進行debug，在這個場景下，我們先啟動一個host Chrome實例：
chrome.exe --remote-debugging-port=9222
然后再啟動一個client 客戶端Chrome實例，使用一個指定的用戶profile：
chrome.exe --user-data-dir=<some directory>
Now you can navigate to the given port from your client and attach to any of the discovered tabs for debugging: http://localhost:9222
You will find the Developer Tools interface identical to the embedded one and here is why:
現在在客戶端中輸入 http://localhost:9222，你會看到當前client端的DevTools就像內嵌在host中的那devtools一樣，你可以操作他下面講解為什么：
- When you navigate your client browser to the remote's Chrome port, Developer Tools front-end is being served from the host Chrome as a Web Application from the Web Server.
- It fetches HTML, JavaScript and CSS files over HTTP
- Once loaded, Developer Tools establishes a Web Socket connection to its host and starts exchanging JSON messages with it.
In this scenario, you can substitute Developer Tools front-end with your own implementation. Instead of navigating to the HTML page at http://localhost:9222, your application can discover available pages by requesting: http://localhost:9222/json and getting a JSON object with information about inspectable pages along with the WebSocket addresses that you could use in order to start instrumenting them. See the HTTP Endpoints section below for more.
·當你用client 連接到9222的時候，DevTools前端 會被host Chrome實例serve為一個遠程服務端的web application
·他會通過HTTP協議fetch HTML，JavaScript，CSS
·一旦加載，DevTools會和host簡歷一個ws鏈接，並開始交換JSON信息
在這個場景下， 你可以用你自己的實現來替代DevTools前端，除了看localhost:9222，你還可以看localhost:9222/json 來獲取到ws通信的JSONobject，並修改使用它們，后面的HTTP Endpoints章節有更詳細內容。
Listening to the protocol
This is especially handy to understand how the DevTools frontend makes use of the protocol. You can view all requests/responses and methods as they happen.
下面會講解DevTools前端是怎么使用這個協議的，你可以查看所有的request/response
To use, first enable DevTools experiments. Then click the ⋮ menu icon in the top-right of the DevTools, and select Settings. Select Experiments on the left of settings. Turn on "Protocol Monitor", then close and reopen DevTools. Now click the ⋮ menu icon again, choose More Tools and then select Protocol monitor.
·首先開啟DevTools experiments
·然后點擊devtools頂部右側的“：”標志，然后選擇Settings，選擇Experiments，然后開啟Protocol Monitor
·然后關閉、重新打開DevTools
·然后重新點擊“：”標志，點擊More Tools，選擇Protocol monitor
You can also issue your own commands. First, open devtools-on-devtools, then within the inner DevTools window, use Main.sendOverProtocol() in the console:
你可以提起你自己的命令，首先打開DevlTools的DevTools，然后在控制台內輸入：
await Main.sendOverProtocol('Emulation.setDeviceMetricsOverride', {
mobile: true,
width: 412,
height: 732,
deviceScaleFactor: 2.625,
});
const data = await Main.sendOverProtocol("Page.captureScreenshot");
DevTools protocol via Chrome extension
通過Chrome 擴展程序使用DevTools protocol
To allow chrome extensions to interact with the protocol, we introduced chrome.debugger extension API that exposes this JSON message transport interface. As a result, you can not only attach to the remotely running Chrome instance, but also instrument it from its own extension.
Chrome Debugger Extension API provides a higher level API where command domain, name and body are provided explicitly in the sendCommand call. This API hides request ids and handles binding of the request with its response, hence allowing sendCommand to report result in the callback function call. One can also use this API in combination with the other Extension APIs.
If you are developing a Web-based IDE, you should implement an extension that exposes debugging capabilities to your page and your IDE will be able to open pages with the target application, set breakpoints there, evaluate expressions in console, live edit JavaScript and CSS, display live DOM, network interaction and any other aspect that Developer Tools is instrumenting today.
Opening embedded Developer Tools will terminate the remote connection and thus detach the extension.
Frequently Asked Questions
常見問題
How is the protocol defined?
The canonical protocol definitions live in the Chromium source tree: (browser_protocol.pdl and js_protocol.pdl). They are maintained manually by the DevTools engineering team. The declarative protocol definitions are used across tools; for instance, a binding layer is created within Chromium for the Chrome DevTools to interact with, and separately bindings generated for Chrome Headless’s C++ interface.
Can I get the protocol as JSON?
These canonical .pdl files are mirrored on GitHub in the devtools-protocol repo where JSON versions, TypeScript definitions and closure typedefs are generated. Most tools rely on these JSON versions.
Also, if you've set --remote-debugging-port=9222 with Chrome, the complete protocol version it speaks is available at localhost:9222/json/protocol.
How do I access the browser target?
The endpoint is exposed as webSocketDebuggerUrl in /json/version. Note the browser in the URL, rather than page. If Chrome was launched with --remote-debugging-port=0 and chose an open port, the browser endpoint is written to both stderr and the DevToolsActivePort file in browser profile folder.
Does the protocol support multiple simultaneous clients?
Chrome 63 introduced support for multiple clients. See this article for details.
Upon disconnnection, the outgoing client will receive a detached event. For example: {"method":"Inspector.detached","params":{"reason":"replaced_with_devtools"}}. View the enum of possible reasons. (For reference: the original patch). After disconnection, some apps have chosen to pause their state and offer a reconnect button.
HTTP Endpoints
HTTP Endpoints
If started with a remote-debugging-port, these HTTP endpoints are available on the same port. (Chromium implementation)
GET /json/version
Browser version metadata
{
"Browser": "Chrome/72.0.3601.0",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3601.0 Safari/537.36",
"V8-Version": "7.2.233",
"WebKit-Version": "537.36 (@cfede9db1d154de0468cb0538479f34c0755a0f4)",
"webSocketDebuggerUrl": "ws://localhost:9222/devtools/browser/b0b8a4fb-bb17-4359-9533-a8d9f3908bd8"
}
GET /json or /json/list
A list of all available websocket targets.
[ {
"description": "",
"devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/DAB7FB6187B554E10B0BD18821265734",
"id": "DAB7FB6187B554E10B0BD18821265734",
"title": "Yahoo",
"type": "page",
"url": "https://www.yahoo.com/",
"webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/DAB7FB6187B554E10B0BD18821265734"
} ]
GET /json/protocol/
The current devtools protocol, as JSON:
{
"domains": [
{
"domain": "Accessibility",
"experimental": true,
"dependencies": [
"DOM"
],
"types": [
{
"id": "AXValueType",
"description": "Enum of possible property types.",
"type": "string",
"enum": [
"boolean",
"tristate",
// ...
GET /json/new?{url}
Opens a new tab. Responds with the websocket target data for the new tab.
GET /json/activate/{targetId}
Brings a page into the foreground (activate a tab).
For valid targets, the response is 200: "Target activated". If the target is invalid, the response is 404: "No such target id: {targetId}"
GET /json/close/{targetId}
Closes the target page identified by targetId.
For valid targets, the response is 200: "Target is closing". If the target is invalid, the response is 404: "No such target id: {targetId}"
WebSocket /devtools/page/{targetId}
The WebSocket endpoint for the protocol.
GET /devtools/inspector.html
A copy of the DevTools frontend that ship with Chrome.