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可能不會獲得太多優勢。


熱門新聞

Advertisement