本文將簡要介紹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ò)傳輸）。

話不多說，讓我們開始吧。我們首先要考慮下為什么需要一個新的協(xié)議？為什么HTTP1、HTTP2、HTTP3或WebSocket協(xié)議不能滿足我們的需求？我將介紹當(dāng)前這些協(xié)議存在的問題，并引出什么是WebTransport；它包括哪些部分；以及什么是網(wǎng)絡(luò)堆棧；此外，我還會介紹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)，因此我想對他們提供的信息表示感謝。

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

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

以上是兩個詳細(xì)的例子，我們還可以繼續(xù)找到類似的例子，比如如果我們想做同聲傳譯的話，我們可能會用到AI技術(shù)，我認(rèn)為這是在線會議未來的方向。再比如如果您讓我們做即時翻譯，那么我們需要將音頻快速上傳到云。此前我已經(jīng)詳細(xì)介紹了安全攝像頭分析、大型多人網(wǎng)絡(luò)在線游戲和主機(jī)游戲，而云游戲模式的原理是在邊緣編碼器中實(shí)時渲染實(shí)際游戲，并發(fā)送游戲內(nèi)容，使得低端配置的客戶端獲得等同高端主機(jī)的視覺效果。Google Stadia云游戲平臺就是一個很好的例子，當(dāng)然這也需要雙向的游戲指令。我們已經(jīng)有了基于服務(wù)器的視頻會議系統(tǒng)，但是我們希望簡化會議，而且WebRTC在會話建立期間會暴露大量的隱私信息，我們也希望能夠避免這種情況。再來說說遠(yuǎn)程桌面管理，這是一個企業(yè)使用場景，有用戶使用物聯(lián)網(wǎng)傳感器和數(shù)據(jù)分析傳輸，我們能夠使用小型功耗敏感物聯(lián)網(wǎng)設(shè)備，非常有效地向云端發(fā)送少量的數(shù)據(jù)。這是怎么做到的呢？對于他們來說，RESTful API是最好的選擇嗎？最后一個選項(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)會話的啟動難度不小。我們在大多數(shù)應(yīng)用程序中也想使用雙向通信，我們需要發(fā)送可靠和有序的數(shù)據(jù)，我們將這種數(shù)據(jù)稱為“流”。流遵循先進(jìn)先出的模式，因此在此過程中不會丟失任何內(nèi)容。 我們還希望以最小的延遲來實(shí)現(xiàn)流，但同時我們還需要發(fā)送非可靠和無序的數(shù)據(jù)報文，這和UDP報文非常相似，它們都是小數(shù)據(jù)包，關(guān)鍵在于傳輸?shù)乃俣?，如果速度太慢，其中一些?shù)據(jù)可能會丟失，但只要我們能夠?qū)崿F(xiàn)高速傳輸，就能解決這個問題。我們還需要持續(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)用程序接口）建立連接的速度相對較慢，尤其是在使用H1或H2的情況下，速度會更慢。使用TLS（安全傳輸層協(xié)議）時，Http/1速度最慢，Http/2次之，Http/3無疑性能最佳，它們始終能提供可靠的無損傳輸，這在許多領(lǐng)域中都是很重要的，不然就需要重新傳輸，增加延遲。即使使用HPACK和QPACK壓縮，HTTP包頭信息也會增加額外的負(fù)擔(dān)，當(dāng)我們的數(shù)據(jù)有效載荷很小時，包頭所占的比重仍然很大。正如我們提到的那樣，在很多情況下我們并不需要它，我們能接受犧牲一些可靠性來換取速度。 WebSocket的主要問題是隊(duì)首阻塞，我在稍后將詳細(xì)說明什么是隊(duì)首堵塞，這是推廣WebSocket協(xié)議使用的一個主要障礙，不過WebSocket能隨時提供可靠的傳送服務(wù)。WebRTC數(shù)據(jù)通道的問題是建立連接的負(fù)擔(dān)很高，稍后我們將詳細(xì)闡述。 您可以開發(fā)自己的UDP協(xié)議來解決這些問題，但是這會帶來一個新的問題，即必須在每個客戶端和每臺服務(wù)器中安裝SDK，才能與協(xié)議通信。但這會使您喪失控制權(quán)，因?yàn)閃eb標(biāo)準(zhǔn)的優(yōu)勢在于您的Web服務(wù)器和客戶端能夠使用您的語言。 此外，我們不能使用Chunked編碼的媒體片段，因?yàn)檫@會造成吞吐延遲（延遲目前將增加一到兩秒），究其原因在于HTTPS的連接速度較慢。另外每個片段都有一個RTT（往返時間）延遲，所以現(xiàn)有的網(wǎng)絡(luò)技術(shù)并不是我們所需要的。

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

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

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

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

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

如果看一下QUIC協(xié)議，您就會發(fā)現(xiàn)，它實(shí)際上可以滿足我們的許多要求。事實(shí)上，我們現(xiàn)在知道它可能是最好的選擇，因此如果現(xiàn)實(shí)中客戶端和服務(wù)器之前已成功握手，則它具有快速的連接設(shè)置1-round trip或者0-round trip。 同時QUIC也十分安全，它一直使用TLS1.3，具有低延時的擁塞控制和可靠的流，并且能實(shí)現(xiàn)標(biāo)識1和2的無序數(shù)據(jù)報文。如果需要的話，它可以使用在p2p場景，作為H3的基礎(chǔ)。因此它在整個互聯(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這個名字。 WebTransport是一個被稱為框架的協(xié)議，該協(xié)議使客戶端與遠(yuǎn)程服務(wù)器端在安全模型下通信，并且采用安全多路復(fù)用傳輸技術(shù)。注意WebTransport是一個框架，在它下面是實(shí)際的協(xié)議，框架提供了一個一致的接口，因此它由一組可以安全地暴露給不受信任的應(yīng)用程序的協(xié)議，以及一個允許它們互換使用的模型組成。它還提供了一組靈活的功能，為我們提供了可靠的單向和雙向流以及非可靠的數(shù)據(jù)報文傳輸。

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

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

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

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

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

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

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

您可能想看一個QUICTransport的握手示例。我們可以打開一個QUICTransport連接，但是部分發(fā)生了一些變化，我稍后將為您詳細(xì)介紹。我們想要QUICTransport轉(zhuǎn)到此服務(wù)器的端口上，瀏覽器將用ALPN列表“wq”向該端口上的服務(wù)器發(fā)送一個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ù)報文。

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

現(xiàn)在讓我們比較一下QUICTransport和WebSocket。他們的主要區(qū)別在于隊(duì)首阻塞始終會影響WebSocket，但隊(duì)首阻塞僅對QUICTransport中相同的流有影響，WebSocket會帶給您更全面的可靠性，而QUICTransport可以提供可靠的流傳輸以及非可靠的數(shù)據(jù)報文。實(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啟用，但是對于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。這是一個新團(tuán)隊(duì)，成立于2020年3月6日，所以這是IETF的一個新項(xiàng)目，您可以通過這里顯示的鏈接閱讀他們的提議。

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

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

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

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

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

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

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

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

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

責(zé)任編輯：lq