Chrome 97加入實驗性低延遲雙向通訊WebTransport API

Chrome 97已經進入穩定階段，開發團隊提到，在接下來幾天或是幾星期內便會正式推出，這個版本除了有許多功能改進與安全修補之外，值得關注的是，Chrome 97加入了一個稱為WebTransport的實驗性API，提供類似WebSockets的介面，作為瀏覽器與伺服器間的安全多工通訊傳輸。

目前網頁應用程式開發人員，有兩個遠端伺服器雙向通訊的API可以使用，分別是WebSockets和RTCDataChannel。WebSockets建立在TCP之上，因此具有所有TCP的缺點，包括隊頭阻塞（Head-of-Line Blocking），也缺乏對不可靠資料的傳輸，因此整體來說，不適合用於低延遲的應用程式，另一種RTCDataChannel則是以SCTP為基礎，雖然沒有WebSockets這些缺點，但是其被設計用於點對點傳輸目的，因此在客戶端與伺服器端配置的使用率相當低。

而WebTransport的出現，便是要來解決這些問題，而且有望替代WebSockets。WebTransport是一個網頁API，使用HTTP/3協定，在網頁客戶端和HTTP/3伺服器間進行雙向傳輸，同時支援可靠與不可靠資料傳輸，以資料包（Datagram）API來傳輸不可靠資料，並且使用串流API來傳輸可靠資料。

資料包API適合用來發送和接收不需要強交付保證的資料，單個資料包大小，會受底層連接的最大資料傳輸單元（MTU）限制，傳輸可能不成功，而且一旦傳輸，資料包可能以任意順序抵達目的地，這些特性使得資料包API，成為低延遲且最佳努力（Best Effort）的資料傳輸理想選擇。使用者可以直接把資料包視為UDP訊息，只是經過加密並且具有擁塞控制。

相較於資料包API，WebTransport串流API提供可靠且有序的資料傳輸，非常適合需要發送或是接收，一個或是多個有序資料串流的應用，使用多個WebTransport串流類似建立多個TCP連接，但因為HTTP/3在底層使用了輕量級QUIC協定，因此開啟與關閉連接的成本更低。

WebTransport是比WebSockets更全面的傳輸協定框架，WebTransport串流API能夠提供如同WebSockets，單一、可靠且有序的訊息串流模型，WebTransport資料包API又可提供低延遲交付、不保證可靠性和排序的資料傳輸。而且沒有WebSockets隊頭阻塞的問題，受益於底層QUIC交握，比透過TLS啟動TCP更快的優勢，建立新連結還具有效能優勢。

只不過目前WebTransport只是W3C工作草案，在客戶端和伺服器函式庫生態系上，WebSocket還是更為完整，具有許多開箱即用的工具，WebTransport在Chrome上也僅是實驗性API，要進入穩定階段還需要一段時間。

Google也提到，WebTransport在部分情境也能夠替代WebRTC資料通道，在運作HTTP/3相容伺服器上，配置設定也較WebRTC伺服器更少，且WebTransport API設計考慮了網頁開發人員的用例，因此和WebRTC資料通道介面相比，WebTransport使用起來更像是編寫現代網頁平臺程式碼。而且Web Worker支援WebTransport，開發者可以讓特定HTML頁面執行客戶端到伺服器的通訊。

不過WebRTC資料通道支援點對點通訊，WebTransport僅支援客戶端到伺服器連接，因此當用戶有多個客戶端需要直接相互通訊，便無法使用WebTransport。Google表示，當開發者已經有一個不錯的WebRTC客戶端和伺服器端配置，切換到WebTransport可能不會獲得太多優勢。