【Chrome】1196- Chrome 97 釋出了！TCP 時代要結束了？

2022年1月4日正式釋出的Chrome 97，帶來了哪些新特性呢？

前言

十多年來，Web技術突飛猛進，Chrome浏覽器發揮了最關鍵的作用，了解Chrome可以幫助我們了解前端行業的發展趨勢。

TL;TR

• Chrome 97最大的亮點是什麼？Chrome  97最大的亮點是WebTransport，得益于強大的QUIC協定，WebTranport可以提供更強更快的雙向通信能力，有望用于遊戲、直播、視訊會議等低延時場景。
• Chrome 97是哪天釋出的？2022-01-04
• Chrome 97更新了多少個特性？一共14個特性，其中9個為正式特性，具體有哪些特性可以檢視Chrome Platform Status
• Chrome 97将使用哪個版本的V8引擎？v9.7
• 我感興趣的正式（enabled by default）特性有哪些？

• WebTransport

• 我感興趣的的DevTools新特性有哪些？
• DevTools Recorder

詳細解讀

WebTransport

Chrome 97正式釋出了WebTransport，一個新的應用層通信協定，支援雙向通信，支援可靠與不可靠通信，支援多路複用，有望應用于遊戲、直播、視訊會議等低延時場景。

下表展示了WebTransport與其他同樣可以用于雙向通信的類似技術的對比：

雙向通信協定	底層協定	優點	缺點
WebSocket	TCP/TLS	技術成熟，使用簡單	TCP頭部阻塞，不支援不可靠無序通信，不适用于低延時場景
WebRTC data channels	SCTP/DTLS/ICE/UDP	可以用于适合P2P場景	使用難度大，不适用于Client/Server通信
WebTransport	HTTP/3（QUIC/UDP）或者HTTP/2（TLS/TCP）	延時更低，沒有頭部阻塞問題，适用場景更多	尚未成為正式标準

WebTransport預設使用HTTP/3，同時使用HTTP/2作為備胎。

HTTP/3是新一代HTTP協定，它最大的變化是不再依賴TCP協定，而是基于新的QUIC協定，如下圖所示：

由上圖可知，QUIC協定相當于同時承擔了TCP、TLS以及HTTP/2的職責：

• 提供類似于TCP的可靠通信，處理丢包、擁塞等網絡異常情況；
• 基于TLS/1.3進行加密，保證通信的安全性，同時避免中間節點幹擾導緻協定僵化；
• 提供類似于HTTP/2的多路複用能力，在網絡傳輸層增加了流的概念，解決了TCP協定的頭部阻塞問題；

TCP是一個偉大的網絡協定，但是它有很多問題，其最大的問題是已經僵化了，基本沒法改了。QUIC最大貢獻不在于解決了TCP頭部阻塞的問題或者提供1-RTT甚至0-RTT的連接配接時長，而是一系列保障可部署性、更快地疊代、避免協定僵化的設計，比如基于UDP、加密、脫離作業系統核心等。

QUIC協定的設計思想有點像React 17，在架構設計上簡化未來的更新，保障長期發展。

對QUIC協定興趣的同學，推薦看看QUIC 101視訊以及The QUIC Transport Protocol: Design and Internet-Scale Deployment論文，講得挺好的，我就不再贅述了。

總之，QUIC是一個大膽、激進、巧妙的網絡協定。正如所有其他改變世界的技術（比如WWW）一樣，QUIC也是站在巨人的肩膀上，吸取了數十年TCP協定的經驗和教訓。

QUIC協定在今年5月成為IETF的RFC，這是計算機網絡發展的革命性裡程碑，未來TCP将有可能會逐漸退出曆史舞台（這個過程會應該比較長，甚至像IPv6一樣時間拖很久）。也就是說，面試者們以後就不用熟記3次握手和4次揮手了？

QUIC已經成為正式标準了，那HTTP/3成為正式标準也就指日可待了。

WebTransport預設是基于HTTP/3的，是以也是基于QUIC的，由此獲得更強大的能力：

• 雙向通信
• 多路複用
• 1-RTT甚至0-RRT的連接配接時長
• 同時支援可靠以及不可靠通信
• 自帶加密

海外知名遊戲直播平台Twitch以及Google雲遊戲服務Stadia都在産品中使用了WebTransport，并且給予了正面的評價，遺憾的是并沒有給出具體的資料名額。它們都不約而同地将WebTransport的優點歸功于QUIC協定，可見WebTransport最大的優點就是使用了QUIC協定。

另外，視訊會議明星産品Zoom也表達過對WebTransport的興趣，隻不過現在并沒有看到具體的應用以及資料，不妨拭目以待。

由于WebTransport目前還隻有Chrome浏覽器支援，尚未成為正式标準，也沒有看到有說服力的應用案例。更重要的的是，WebTransport所依賴HTTP/3協定也沒有成為正式标準，QUIC協定尚在推廣過程中。是以，WebTransport的未來會怎樣，還是個未知數。大家不妨了解一下WebTransport，但是建議暫時保持謹慎态度。不過，WebTransport所依賴的QUIC協定還是值得我們認真了解的，這才是正真的亮點。

WebTransport标準包含了兩部分的内容，一部分是由IETF所制定的網絡協定：The WebTransport Protocol Framework，另一部分為W3C所制定的Web API：WebTransport，兩者目前都沒有成為正式的技術标準。

在沒有具體應用資料、沒有成為正式标準、也有沒其他浏覽器實作的情況下，就直接把WebTransport這樣重要的特性正式釋出，個人認為這種做法似乎有點沖動了。

DevTools Recorder

Chrome 97的DeveTools新增一個預覽特性（Preview Feature），即Recorder，可以錄制頁面的操作流程（User Flow），用于測試和性能分析。

我錄了一個非常簡單的Google流程，還挺有意思的（主要是因為搜的是自己？），操作挺簡單的：

錄制的User Flow可以回放，也可以分析頁面性能，還可以導出Puppeteer腳本，用于頁面測試。

不過，我運作導出的Puppeteer腳本search.js時翻車了，目測是導出的腳本有BUG，這就很尴尬了：

node search.js
(node:3972) UnhandledPromiseRejectionWarning: Error: net::ERR_INVALID_URL at chrome://new-tab-page/
    at navigate (/Users/kiwenlau/Desktop/puppeteer-test/node_modules/[email protected]@puppeteer/lib/cjs/puppeteer/common/FrameManager.js:155:23)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async FrameManager.navigateFrame (/Users/kiwenlau/Desktop/puppeteer-test/node_modules/[email protected]@puppeteer/lib/cjs/puppeteer/common/FrameManager.js:130:21)
    at async Frame.goto (/Users/kiwenlau/Desktop/puppeteer-test/node_modules/[email protected]@puppeteer/lib/cjs/puppeteer/common/FrameManager.js:500:16)
    at async Page.goto (/Users/kiwenlau/Desktop/puppeteer-test/node_modules/[email protected]@puppeteer/lib/cjs/puppeteer/common/Page.js:1167:16)
    at async /Users/kiwenlau/Desktop/puppeteer-test/search.js:129:9
(Use `node --trace-warnings ...` to show where the warning was created)
(node:3972) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:3972) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.      

這個問題我已經給提了issue，據說是因為Puppeteer不支援打開chrome://new-tab-page所導緻的。

瑕不掩瑜，Recorder功能還是很實用的，感興趣的同學闊以試一下！

總結

本文主要介紹了WebTransport，并重點介紹了QUIC協定。HTTP/2協定是2015年釋出的，僅僅過去6年，QUIC協定已經釋出了，基于QUIC協定的HTTP/3協定目測很快就要釋出了。技術疊代的速度還是挺快的，大家還學的動嗎？

TCP協定的問題以及QUIC協定的解法都不難了解，還能記得大學課程《計算機網絡》的人都能看懂，是以這事在技術上并不難，這不是量子力學也不是光刻機。但是，從開發QUIC協定、到協定标準化、再到協定大規模部署，前後至少需要長達10年甚至20年的努力，略顯浮躁的我們有這樣的戰略眼光和長期定力嗎？是以，推動QUIC協定的公司和個人還是非常值得讓人尊敬的，是他們在默默地用技術改變世界。

Chrome部落格寫得越多，越能深深感受到Chrome的厲害之處，是以我有底氣繼續使用《了不起的Chrome浏覽器》這樣的标題。移動網際網路的發展讓浏覽器在移動端的重要性降低了很多，但是Chrome幾乎憑一己之力讓Web技術全方位地上了一個台階，讓Web技術在2B領域站穩腳跟。移動網際網路的紅利時代已然落幕，2B應用的崛起還剛剛開始，Web技術以及Chrome浏覽器将在其中扮演關鍵的角色，讓我們拭目以待。

參考資料

• ​​了不起的Chrome浏覽器（1）：Chrome 89開啟Web應用的物聯網時代​​
• ​​了不起的Chrome浏覽器（2）：Chrome 90将預設使用HTTPS，Web更安全了​​
• ​​了不起的Chrome浏覽器（3）：Chrome 91支援WebAssembly SIMD，加​​​​Web在AI等領域的應用​​
• ​​了不起的Chrome浏覽器（4）：Chrome 92新增at和randomUUID方法，Canvas支援Display P3色域​​
• ​​了不起的Chrome浏覽器（5）：Chrome 93支援Error Cause，我國首個ECMAScript提案可以用了​​
• ​​了不起的Chrome浏覽器（6）：Chrome 94開始WebGPU試用，Web的圖像渲染及機器學能力更強了​​
• ​​了不起的Chrome浏覽器（7）：Chrome 95終于支援WebAssembly異常處理了​​
• ​​了不起的Chrome浏覽器（8）：Chrome 96也支援WebAssembly引用類型了！​​
• Chrome 97: WebTransport, New Array Static Methods and More
• V8 release v9.7
• Experimenting with WebTransport
• W3C WebTransport Working Group Updates - October 2021
• W3C WebTransport WG Meeting
• WebTransport & WebCodecs
• Zoom on Web: getting connected with advanced web technology
• The QUIC Transport Protocol: Design and Internet-Scale Deployment
• QUIC 101
• QUIC is now RFC 9000
• ​​谷歌Stadia雲遊戲迎來兩周年，如今怎麼樣了？​​
• ​​從小衆到獨角獸：Twitch第19号員工講述Twitch“黃金十年”​​
• Record, replay and measure user flows