本文將簡(jiǎn)要介紹WebTransport的需求和發(fā)展、技術(shù)網(wǎng)絡(luò)堆棧、IETF開發(fā)的QuicTransport和Http3Transport推薦協(xié)議，以及W3C正在開發(fā)的瀏覽器API草案。

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

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

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

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

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

因此，綜合這些案例，我們看到了一些核心需求。首先我們希望繼承現(xiàn)代Web的安全保護(hù)技術(shù)。換句話說，我們需要TLS（安全傳輸層協(xié)議）加密，我們想要某種類型的擁塞控制和CORS（跨域資源共享），我們?nèi)韵胍蛻舳?服務(wù)器體系結(jié)構(gòu)，我們不希望它建立在p2p的模型上，因?yàn)閜2p連接體系結(jié)構(gòu)會(huì)話的啟動(dòng)難度不小。我們?cè)诖蠖鄶?shù)應(yīng)用程序中也想使用雙向通信，我們需要發(fā)送可靠和有序的數(shù)據(jù)，我們將這種數(shù)據(jù)稱為“流”。流遵循先進(jìn)先出的模式，因此在此過程中不會(huì)丟失任何內(nèi)容。 我們還希望以最小的延遲來實(shí)現(xiàn)流，但同時(shí)我們還需要發(fā)送非可靠和無序的數(shù)據(jù)報(bào)文，這和UDP報(bào)文非常相似，它們都是小數(shù)據(jù)包，關(guān)鍵在于傳輸?shù)乃俣?，如果速度太慢，其中一些?shù)據(jù)可能會(huì)丟失，但只要我們能夠?qū)崿F(xiàn)高速傳輸，就能解決這個(gè)問題。我們還需要持續(xù)地給發(fā)送端提供反饋，您也可以將其視為反壓力，我們不能漫無目的地發(fā)射接收無法處理的數(shù)據(jù)。并且它們應(yīng)該使用URI進(jìn)行資源定位，因?yàn)閃eb中的URI和URL是我們定位Internet內(nèi)容的核心中樞，所以我們不想改變這種機(jī)制，我們想要一些符合URI機(jī)制的東西。

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

讓我們?cè)倏匆幌玛?duì)首阻塞的一些細(xì)節(jié)，因?yàn)閃ebSocket可能是我們的首選方案。因此通常情況下，我們會(huì)在隊(duì)首阻塞中看到由多個(gè)流共享的單個(gè)數(shù)據(jù)隊(duì)列，所以我可以把它比作紅車和藍(lán)車在一條馬路上行駛，假設(shè)現(xiàn)在我的紅色汽車要在這個(gè)十字路口左轉(zhuǎn)，藍(lán)色的車要繼續(xù)行駛，只要這條路沒有擁堵，一切都會(huì)按照我們所期望的那樣。

但是如果有一個(gè)等待傳輸?shù)臄?shù)據(jù)包隊(duì)列，并且隊(duì)首的數(shù)據(jù)包無法向前移動(dòng)那就會(huì)發(fā)生隊(duì)首阻塞。在這里可以把它想象成紅色汽車想左轉(zhuǎn)，但汽車因?yàn)槟撤N原因無法繼續(xù)行駛，現(xiàn)在我的單通道流中的所有其他流都將堆積在阻塞數(shù)據(jù)的后面，因此我的藍(lán)車和紅車都無法行駛，通道也被堵住了。

有多種解決方案可以解決隊(duì)首阻塞，其中之一是實(shí)現(xiàn)每個(gè)輸出轉(zhuǎn)發(fā)隊(duì)列并行獨(dú)立。因此在道路的類比中，這意味著我們要加寬道路以引入另一條車道。假設(shè)現(xiàn)在我們的紅車擋住了他們的車道，藍(lán)色的車還有另一條車道可以繼續(xù)行駛，但是由于第一個(gè)包堵在那里，紅色隊(duì)列仍然被阻塞，藍(lán)色流保持獨(dú)立并且不會(huì)被阻塞。

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

為什么不直接使用UDP呢？因?yàn)閁DP并不安全，它沒有繼承Web安全模型，缺少加密和擁塞控制，也缺少CORS和發(fā)送確認(rèn)。

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

所以，我們希望QUIC符合我們的多數(shù)準(zhǔn)則，因?yàn)榈衅渌膮f(xié)議或多或少都有些小問題。因此，開發(fā)人員應(yīng)該為網(wǎng)絡(luò)開發(fā)新的傳輸選項(xiàng)，解決我剛剛談到的這些特殊問題。WebTransport由工程師創(chuàng)建，為工程師所用，并且被工程師命名，因此，我們就直接沿用WebTransport這個(gè)名字。 WebTransport是一個(gè)被稱為框架的協(xié)議，該協(xié)議使客戶端與遠(yuǎn)程服務(wù)器端在安全模型下通信，并且采用安全多路復(fù)用傳輸技術(shù)。注意WebTransport是一個(gè)框架，在它下面是實(shí)際的協(xié)議，框架提供了一個(gè)一致的接口，因此它由一組可以安全地暴露給不受信任的應(yīng)用程序的協(xié)議，以及一個(gè)允許它們互換使用的模型組成。它還提供了一組靈活的功能，為我們提供了可靠的單向和雙向流以及非可靠的數(shù)據(jù)報(bào)文傳輸。

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

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

我們看一看網(wǎng)絡(luò)堆棧是什么樣子？HTTP1/2上無害的堆棧確實(shí)推動(dòng)了當(dāng)今的全球互聯(lián)網(wǎng)革命。有一個(gè)真實(shí)的案例，早在2001年，Akamai全部網(wǎng)絡(luò)帶寬是1Gbps，而今天這一數(shù)字變成了1650+Tbps。在不改變協(xié)議的情況下，速度增長了10幾約萬倍。到如今我們?nèi)匀徊渴餒TTP1block，現(xiàn)在我們也部署HTTP2，但是這個(gè)簡(jiǎn)單協(xié)議堆?？梢灾С至髁繑U(kuò)展15萬倍，因此這是個(gè)很好的設(shè)計(jì)。建立在QUIC之上的HTTP/3現(xiàn)已對(duì)其進(jìn)行了改進(jìn)，并刪除了在TCP不適用、不靈活的功能，轉(zhuǎn)而直接使用UDP。WebSocket構(gòu)建在TCP之上，并形成了一個(gè)更復(fù)雜的協(xié)議堆棧。因此這四種協(xié)議覆蓋了當(dāng)今互聯(lián)網(wǎng)上99.9%的流量。

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

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

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

那么QUICTransport URI方案是什么樣子呢？如果您熟悉系Web運(yùn)行方式，就會(huì)有很深刻的了解。我們有協(xié)議描述符QUIC/DASH Transport，在這種情況下我們將主機(jī)server test作為SNI的一部分與端口號(hào)一起發(fā)送，剩下的URI方案就是正在傳輸?shù)捻撁?。在TLS建立后，客戶端才會(huì)接收它。

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

HT3Transport具有全新的傳輸，采用協(xié)議HTTPS，當(dāng)創(chuàng)建新的HTTP/3連接時(shí)，它會(huì)使用現(xiàn)有的連接池，它會(huì)發(fā)送帶有特定頭部信息的連接請(qǐng)求，當(dāng)然這并不是HTTP/3中的創(chuàng)新。服務(wù)器響應(yīng)200 OK，將“sessionid”標(biāo)頭設(shè)置為1?，F(xiàn)在對(duì)等客戶端和服務(wù)器可以發(fā)送流和數(shù)據(jù)報(bào)文，因?yàn)樗峭ㄟ^ID雙向關(guān)聯(lián)，一旦關(guān)聯(lián)的CONNECT流關(guān)閉，會(huì)話就會(huì)關(guān)閉。

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

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

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

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

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

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

現(xiàn)在API仍然處于流動(dòng)狀態(tài)，我在前面的示例中提到過，您可以使用不久前更改的QUICTransport或HTTP3Transpaort傳輸，也可以建立一個(gè)新的WebTransport，而您使用的傳輸類型由初始化WebTransport時(shí)使用的URI中的協(xié)議定義。

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

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

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

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

責(zé)任編輯：lq