本文將簡要介紹WebTransport的需求和發展、技術網絡堆棧、IETF開發的QuicTransport和Http3Transport推薦協議，以及W3C正在開發的瀏覽器API草案。

大家好，我是Will Law，目前在位于舊金山的Akamai Technologies舊金山辦公室工作。我生活和工作的地方距離金門大橋非常近，也就是圖片上的地方。能與美國和中國的工程師交流一直是我的榮幸，尤其是討論在全球范圍內具有重要意義的下一代Web協議問題。而我今天要介紹的主題就是關于WebTransport（網絡傳輸）。

話不多說，讓我們開始吧。我們首先要考慮下為什么需要一個新的協議？為什么HTTP1、HTTP2、HTTP3或WebSocket協議不能滿足我們的需求？我將介紹當前這些協議存在的問題，并引出什么是WebTransport；它包括哪些部分；以及什么是網絡堆棧；此外，我還會介紹W3C（國際網網絡路聯盟）提出的Web瀏覽器應用程序接口草案。最后，我們還將討論如何參與該協議的開發。 在開始之前，我想先感謝Jeff Posnick、Victor Vasilief、Peter Thatcher、Yutaka Hirano和Bernard Aboba為本次演示提供的數據和內容素材。他們一直是WebTransport發展中不可或缺的一部分，尤其是在社區草案形成過程中做出了很多貢獻，因此我想對他們提供的信息表示感謝。

讓我們正式開始今天的介紹，假設我們要設計一款游戲，您是架構師，我們希望您想出盡可能多的使用場景，而我們要考慮的第一個場景是基于Web或者主機的多人游戲，在這些游戲中，指令會從客戶端發送到基于云的服務器，其中有些指令對時間屬性十分敏感，例如您在游戲中的位置和角色等。而有些指令則與狀態的關聯程度更高，例如您的形象或武器。 所以，我們不介意狀態性指令的丟失，但那些對時間十分敏感的指令必須及時發送。這兩種情況下的數據流都是雙向的，因為您需要把位置發送到游戲中，游戲也需要將游戲目前的狀態和所有其他玩家的位置信息傳給您。因此，我們可以使用RESTful API（事實上大多數情況都是這么做的），也可以用HTTPS來保證安全，還可以使用WebSockets協議或WebRTC（網頁實時通信）數據通道，再或者我們還可以用自己的UDP（用戶數據報協議）傳輸。 這四種方式在不同的游戲和場景中都有運用。但是，仔細研究這些協議，我們會發現每種方式都存在一些問題，那么我們要如何來改善呢？

第二個例子是低延遲實時直播，典型的場景包括體育賽事、新聞和娛樂競猜節目的一對多單向直播流，我們希望視頻畫面能夠支持高清、高幀率、高動態范圍、寬色域以及DRM（數字版權管理），但現實是其中很多都無法實現。WebRTC（網頁即時通信）如今不支持這些功能。有時我們可能還想進行多對多視頻聊天，比如使用Zoom、Apple Facetime或Google Meet會議程序進行網絡會議。這種情況我們可以使用單向廣播，通過H1或H2使用Chunked的編碼功能，目前這也是大部分人所使用的；我們還可以用WebSockets協議、WebRTC數據通道來傳送我們的媒體片段；同樣，我們還可以使用自己的UDP私有協議傳輸。

以上是兩個詳細的例子，我們還可以繼續找到類似的例子，比如如果我們想做同聲傳譯的話，我們可能會用到AI技術，我認為這是在線會議未來的方向。再比如如果您讓我們做即時翻譯，那么我們需要將音頻快速上傳到云。此前我已經詳細介紹了安全攝像頭分析、大型多人網絡在線游戲和主機游戲，而云游戲模式的原理是在邊緣編碼器中實時渲染實際游戲，并發送游戲內容，使得低端配置的客戶端獲得等同高端主機的視覺效果。Google Stadia云游戲平臺就是一個很好的例子，當然這也需要雙向的游戲指令。我們已經有了基于服務器的視頻會議系統，但是我們希望簡化會議，而且WebRTC在會話建立期間會暴露大量的隱私信息，我們也希望能夠避免這種情況。再來說說遠程桌面管理，這是一個企業使用場景，有用戶使用物聯網傳感器和數據分析傳輸，我們能夠使用小型功耗敏感物聯網設備，非常有效地向云端發送少量的數據。這是怎么做到的呢？對于他們來說，RESTful API是最好的選擇嗎？最后一個選項是PubSub（發布/訂閱）模型。我們今天也許可以在很多應用程序中避免使用長輪詢代碼。

因此，綜合這些案例，我們看到了一些核心需求。首先我們希望繼承現代Web的安全保護技術。換句話說，我們需要TLS（安全傳輸層協議）加密，我們想要某種類型的擁塞控制和CORS（跨域資源共享），我們仍想要客戶端-服務器體系結構，我們不希望它建立在p2p的模型上，因為p2p連接體系結構會話的啟動難度不小。我們在大多數應用程序中也想使用雙向通信，我們需要發送可靠和有序的數據，我們將這種數據稱為“流”。流遵循先進先出的模式，因此在此過程中不會丟失任何內容。 我們還希望以最小的延遲來實現流，但同時我們還需要發送非可靠和無序的數據報文，這和UDP報文非常相似，它們都是小數據包，關鍵在于傳輸的速度，如果速度太慢，其中一些數據可能會丟失，但只要我們能夠實現高速傳輸，就能解決這個問題。我們還需要持續地給發送端提供反饋，您也可以將其視為反壓力，我們不能漫無目的地發射接收無法處理的數據。并且它們應該使用URI進行資源定位，因為Web中的URI和URL是我們定位Internet內容的核心中樞，所以我們不想改變這種機制，我們想要一些符合URI機制的東西。

現在，讓我們回顧一下現有Web技術存在哪些問題？比如RESTful API（表現層狀態轉移應用程序接口）建立連接的速度相對較慢，尤其是在使用H1或H2的情況下，速度會更慢。使用TLS（安全傳輸層協議）時，Http/1速度最慢，Http/2次之，Http/3無疑性能最佳，它們始終能提供可靠的無損傳輸，這在許多領域中都是很重要的，不然就需要重新傳輸，增加延遲。即使使用HPACK和QPACK壓縮，HTTP包頭信息也會增加額外的負擔，當我們的數據有效載荷很小時，包頭所占的比重仍然很大。正如我們提到的那樣，在很多情況下我們并不需要它，我們能接受犧牲一些可靠性來換取速度。 WebSocket的主要問題是隊首阻塞，我在稍后將詳細說明什么是隊首堵塞，這是推廣WebSocket協議使用的一個主要障礙，不過WebSocket能隨時提供可靠的傳送服務。WebRTC數據通道的問題是建立連接的負擔很高，稍后我們將詳細闡述。 您可以開發自己的UDP協議來解決這些問題，但是這會帶來一個新的問題，即必須在每個客戶端和每臺服務器中安裝SDK，才能與協議通信。但這會使您喪失控制權，因為Web標準的優勢在于您的Web服務器和客戶端能夠使用您的語言。 此外，我們不能使用Chunked編碼的媒體片段，因為這會造成吞吐延遲（延遲目前將增加一到兩秒），究其原因在于HTTPS的連接速度較慢。另外每個片段都有一個RTT（往返時間）延遲，所以現有的網絡技術并不是我們所需要的。

讓我們再看一下隊首阻塞的一些細節，因為WebSocket可能是我們的首選方案。因此通常情況下，我們會在隊首阻塞中看到由多個流共享的單個數據隊列，所以我可以把它比作紅車和藍車在一條馬路上行駛，假設現在我的紅色汽車要在這個十字路口左轉，藍色的車要繼續行駛，只要這條路沒有擁堵，一切都會按照我們所期望的那樣。

但是如果有一個等待傳輸的數據包隊列，并且隊首的數據包無法向前移動那就會發生隊首阻塞。在這里可以把它想象成紅色汽車想左轉，但汽車因為某種原因無法繼續行駛，現在我的單通道流中的所有其他流都將堆積在阻塞數據的后面，因此我的藍車和紅車都無法行駛，通道也被堵住了。

有多種解決方案可以解決隊首阻塞，其中之一是實現每個輸出轉發隊列并行獨立。因此在道路的類比中，這意味著我們要加寬道路以引入另一條車道。假設現在我們的紅車擋住了他們的車道，藍色的車還有另一條車道可以繼續行駛，但是由于第一個包堵在那里，紅色隊列仍然被阻塞，藍色流保持獨立并且不會被阻塞。

那么為什么不使用現有的Web協議WebRTC呢？這張圖表就能解釋其中的原因，因為這是一個非常復雜的協議。它最初被構建為p2p通信協議，并且在建立連接之前會要求會話描述協議來建立SDP消息傳遞。在客戶端服務器通信模型中我們不需要這樣做，因為兩個服務器都希望客戶端尋址。 WebRTC也要求CDN避免部署ICE、DTL、SCTP協議。因此在某些情況下我們可以使用WebRTC，但WebRTC不是為服務器-客戶端模型的應用設計程序空間而專門設計的。

為什么不直接使用UDP呢？因為UDP并不安全，它沒有繼承Web安全模型，缺少加密和擁塞控制，也缺少CORS和發送確認。

如果看一下QUIC協議，您就會發現，它實際上可以滿足我們的許多要求。事實上，我們現在知道它可能是最好的選擇，因此如果現實中客戶端和服務器之前已成功握手，則它具有快速的連接設置1-round trip或者0-round trip。 同時QUIC也十分安全，它一直使用TLS1.3，具有低延時的擁塞控制和可靠的流，并且能實現標識1和2的無序數據報文。如果需要的話，它可以使用在p2p場景，作為H3的基礎。因此它在整個互聯網中被大量部署，尤其是CDM之中。現在IETF即將推出標準版本，我們將以HTTP/3的形式獲得出色的全球QUIC支持。

所以，我們希望QUIC符合我們的多數準則，因為但所有其他的協議或多或少都有些小問題。因此，開發人員應該為網絡開發新的傳輸選項，解決我剛剛談到的這些特殊問題。WebTransport由工程師創建，為工程師所用，并且被工程師命名，因此，我們就直接沿用WebTransport這個名字。 WebTransport是一個被稱為框架的協議，該協議使客戶端與遠程服務器端在安全模型下通信，并且采用安全多路復用傳輸技術。注意WebTransport是一個框架，在它下面是實際的協議，框架提供了一個一致的接口，因此它由一組可以安全地暴露給不受信任的應用程序的協議，以及一個允許它們互換使用的模型組成。它還提供了一組靈活的功能，為我們提供了可靠的單向和雙向流以及非可靠的數據報文傳輸。

那么WebTransport有哪些功能呢？我之前提到了單向流，這其實是一個方向上無限長的字節流。當接收端無法足夠快地讀取它們時，它會對發送端施加反壓力，這類似于我現在正在給大家演講的這個直播視頻。 正常序列消息傳遞中遵循先入先出FIFO原則，先進入的也從另一端先出，而對于亂序的消息傳遞則可以通過每個流中加入消息從而使得其有多個并發的流。雙向流只是一對單向流，每個方向相反，因此，這對于在我希望得到響應的情況下發送信息很有用。正如我們在許多使用過的案例中所討論的那樣，這種需求非常普遍，因此數據報文是小規模、無序、非可靠的消息，數據報文通常保存小于1MTU的數據（約1500字節），這主要取決于網絡配置。這對于發送小的更新非常有用，因為這些更新可能會丟失，但是我的應用程序可以處理這些丟失，傳輸可以專注于將數據包從服務器盡快地發送到客戶端。

所以請記住WebTransport是一個傳輸框架，那么WebTransport中包含哪些推薦的傳輸協議呢？正如我提到的，QUIC似乎是一個不錯的候選，首先是專用的QUIC傳輸，另外還有HTTP3Transport。我們還有一個備用機制叫做HTTP2Transport。

我們看一看網絡堆棧是什么樣子？HTTP1/2上無害的堆棧確實推動了當今的全球互聯網革命。有一個真實的案例，早在2001年，Akamai全部網絡帶寬是1Gbps，而今天這一數字變成了1650+Tbps。在不改變協議的情況下，速度增長了10幾約萬倍。到如今我們仍然部署HTTP1block，現在我們也部署HTTP2，但是這個簡單協議堆棧可以支持流量擴展15萬倍，因此這是個很好的設計。建立在QUIC之上的HTTP/3現已對其進行了改進，并刪除了在TCP不適用、不靈活的功能，轉而直接使用UDP。WebSocket構建在TCP之上，并形成了一個更復雜的協議堆棧。因此這四種協議覆蓋了當今互聯網上99.9%的流量。

那么WebTransport可能是什么樣子呢？正如我們提到的那樣，它主要建立在UDP和QUIC之上。WebTransport是我們的框架，在此框架下我們有幾種傳輸類型：QUICTransport、HTTP3Transport和HTTP2Transport。值得注意的是HTTP3Transport和QUICTransport都提供可靠流和非可靠數據報文。 截止到2020年11月，這些結論還存在爭議，可能的原因是QUICTransport沒有遵循HTTP的方向開發，或者兩者都在繼續開發，因此開發并不同步。

我們來比較一下HTTP3Transport和QUICTransport。HTTP3Transport的主要區別在于它與其他HTTP3流量在一個池中，假設我有一個終端，并且正在運行許多應用程序，而它們正在以公共主機的名義與服務器進行通信，那么所有HTTP/3流量都會共享給這個鏈接。HTTP/3繼承了很多我們喜歡的HTTP的特性，比如負載均衡、頭部信息，以及防火墻和代理的全面支持。因此，您的防火墻在看到HTTP/3時，就能理解它，但它可能不理解QUICTransport。這里討論的應用程序是常規的Web應用、Web聊天應用程序和Pub/Sub訂閱模型。 另一方面QUICTransport是客戶端和服務器之間建立連接的專用連接方式，服務器可以優化客戶端的傳輸并向客戶端公開更多的統計信息，而無需依賴HTTP/3。同時，它也繼承了HTTP的可擴展性特性。這里我們真正關心的是速度或性能，比如網絡視頻游戲和實時媒體中的應用。 HTTP3或QUIC都可以滿足某些Web應用場景并且這些協議仍在不斷地發展，您可以討論是否可以使用其中任何一個來解決大多數此類案例。實際上，并不存在最好的方法，而只能基于當前環境做出的最優選擇。

TCP作為回退計劃也很有趣，那么如果QUIC被阻止怎么辦？我們可以回退到WebSocket。它可以在根本不支持WebTransport的瀏覽器上實現。HTTP2Transport被認為是HTTP3Transport的一個自然回退的方案。所以，要么QUICTransport可以回退到WebSocket，要么就無路可退。

那么QUICTransport URI方案是什么樣子呢？如果您熟悉系Web運行方式，就會有很深刻的了解。我們有協議描述符QUIC/DASH Transport，在這種情況下我們將主機server test作為SNI的一部分與端口號一起發送，剩下的URI方案就是正在傳輸的頁面。在TLS建立后，客戶端才會接收它。

您可能想看一個QUICTransport的握手示例。我們可以打開一個QUICTransport連接，但是部分發生了一些變化，我稍后將為您詳細介紹。我們想要QUICTransport轉到此服務器的端口上，瀏覽器將用ALPN列表“wq”向該端口上的服務器發送一個hello，服務器接收后發回Server Hello，并在其中包括“wq”，瀏覽器接收Server Hello并在QUIC上發送帶有數據流和FIN（關閉連接）的數據包，因此它發送的流非常短。服務器接收流，并接受發送源，現在應用程序可以發送和接收流和數據報文。

HT3Transport具有全新的傳輸，采用協議HTTPS，當創建新的HTTP/3連接時，它會使用現有的連接池，它會發送帶有特定頭部信息的連接請求，當然這并不是HTTP/3中的創新。服務器響應200 OK，將“sessionid”標頭設置為1。現在對等客戶端和服務器可以發送流和數據報文，因為它是通過ID雙向關聯，一旦關聯的CONNECT流關閉，會話就會關閉。

現在讓我們比較一下QUICTransport和WebSocket。他們的主要區別在于隊首阻塞始終會影響WebSocket，但隊首阻塞僅對QUICTransport中相同的流有影響，WebSocket會帶給您更全面的可靠性，而QUICTransport可以提供可靠的流傳輸以及非可靠的數據報文。實際上，您可以取消正在進行的流，TLS和源頭的信任模型是相同的，這一點二者并無區別。為防止跨協議攻擊，您可以使用基于SHA-1的WebSocket握手，而在QUICTransport上應采用ALPN。為了防止中間件混亂，WebSocket采用基于XOR的掩碼機制，而QUICTransport始終用TLS1.3加密。WebSocket身份驗證功能可以通過Cookie啟用，但是對于QUICTransport應用程序，應用程序本身必須提供一些方法來實現身份驗證。所以QUIC和WebSocket有較大的差異，QUICTransport中存在隊首阻塞和部分可靠性問題。

那么哪些團隊在更新WebTransport呢？首先當然是IETF，他們定義了HTTP/1、HTTP/2，以及您可能使用的所有RFC。這是一個新團隊，成立于2020年3月6日，所以這是IETF的一個新項目，您可以通過這里顯示的鏈接閱讀他們的提議。

誰在更新基于瀏覽器的API？W3C建立了一個WebTransport工作組，這個工作組于2020年9月成立，您可以在這里轉到WebTransport工作組的主頁。實際上我和來自Mozilla的Jan Ivar Bruaroey是這個小組的聯合組長之一，合同有效期為2年。我們有一個WICG承諾的API草案，所以我們希望我們的工作能夠迅速取得進展，并且我們可以從現在起的兩年內將其正式化為一個標準。

因此讓我們看一下孵化草案中的一些代碼示例，如果您習慣于編寫JavaScript類型腳本，那這里用到的語法對您來說一定并不復雜。我們假設這里有函數用來獲取存在的序列化游戲狀態，為了用具體例子說明我們的傳輸，我們只需闡明新的WebTransport。記得之前說過的HTTP3Transport和QUICTransport，現在已更改為簡單的新WebTransport協議層來查找將要使用的傳輸類型，我們在傳輸層編寫報文中的可編寫對象，從而建立報文內容。然后，我們可以簡單地使用數據報文，來編寫我們從我們那里得到的信息來實現游戲狀態。這一切都能得以簡單實現。

這是一個使用QUIC單向流將可靠的游戲狀態發送到服務器的代碼示例。我們以完全相同的方式實現我們的傳輸。但是現在我們現在需要等一等，直到流返回。因此一旦流建立，我們就要從流中創建單向流。我們可以再次從可寫組件中獲取內容，有了這些信息，我們就可以寫下我們可以發送的信息，然后關閉編寫器。所以這是一種非常簡單的方法，能實現沿著單向流發送數據。

接下來看看我想展示的第三個代碼示例，本質上這是通過HTTP發送請求數據，通過同一個網絡連接，可靠地接收無序的媒體文件。因為這是視頻，所以這里我們將涉及到媒體來源。我們建立了自己的媒體源，在這之后，我們將連接源緩沖器（即初始化緩沖器），并在這里建立新的WebTransport，然后等待傳入單向接收流的建立，在接收流上，我們等待可讀對象的建立，從而簡單地將這個緩沖器（在這個例子中是接收流的可讀組件）直接附加到源緩沖區上的指定緩沖器中，并進行管道處理。這提供了一個非常清晰的接口來接收數據流，我將其放入MCS（調制與編碼策略）并將其呈現在網頁的視頻元素中。

現在API仍然處于流動狀態，我在前面的示例中提到過，您可以使用不久前更改的QUICTransport或HTTP3Transpaort傳輸，也可以建立一個新的WebTransport，而您使用的傳輸類型由初始化WebTransport時使用的URI中的協議定義。

現在Google已經在WebTransport方面做了很多工作。QUICTransport正在Chrome84進行源代碼測試，部分Python代碼使用的就是AIOQUIC。如果我沒記錯的話，對于QUIC部分，您可以從GitHub下載該項目，此外還有一個可以與之通信的客戶端。Adam Yutaka和Victor還做了一個涉及Chrome 87+的演示。您可以在此處訪問此網頁并進行測試。請關注下一個屏幕截圖，請注意，您必須在Chrome Canary中啟用實驗性Web平臺功能，否則將無法使用。 這是我的Chrome Canary瀏覽器，我在驗證實驗性Web平臺功能是否已經啟用。我們來加載網頁，然后我點擊連接到他們公開托管的服務器，系統顯示連接就緒數據報文編寫器已就緒。在控制臺這里，我只需確認window.com傳輸顯示我們已經建立了一個對象，并且您可以在這里看到可公開訪問的界面，現在我可以發送數據報文了，當我們發送時，他們建立的簡單服務器只需回送數據報文中發送的字節數，對于單向流同樣可以發送，服務器將發回在該流上接收到的字節，并關閉流和同一個雙向流。我所有的組件都在這里。我們現在需要構建一些用例，其中涉及不可靠、無序的數據報文，以及非可靠并且在運行的有序流。在此基礎上，您可以開始構建應用程序，并真正測試是否可行，這是一個非常令人興奮的測試。

您怎樣才能參與測試呢？IETF是一個全球性的機構，您可以免費參加IETF活動，您只需支付線下活動的參會費用。這有一個公共郵件列表，您可以免費訂閱，我把它列了出來以便大家隨時了解IETF中WebTransport的發展。W32C雖然需要會員身份，但網上提供了可公開訪問的公共郵件列表，如果您需要其中任何注冊信息，請隨時聯系我們。您也可以訪問所示的網站，其中有一小群人正在開發這些規范，如果您有相應的使用場景，歡迎您提供寶貴意見。

這里列出了一些有用的鏈接，這些鏈接提供了關于WebTransport的背景信息。

感謝大家讓我在這么短的時間里詳細介紹WebTransport。很高興與您交流，如果您對WebTransport有任何疑問，或者您想加入W3C WebTransport工作組，請隨時聯系我，再次感謝大家百忙之中參與我們的活動。再見！

責任編輯：lq