每年，我都會(huì)在IIT-RTC會(huì)議上與許多WebRTC標(biāo)準(zhǔn)人員進(jìn)行交流，這場(chǎng)疫情顯然讓今年有所不同。雖然我們?cè)诮衲甑腒ranky Geek會(huì)議上確實(shí)談到了標(biāo)準(zhǔn)化和“WebRTC的未來(lái)”，但我們沒(méi)有時(shí)間深入研究更多細(xì)節(jié)，所以我們將在這里討論。

Bernard在實(shí)時(shí)通信領(lǐng)域有著長(zhǎng)久而卓越的職業(yè)生涯。除了W3C WebRTCCo-Chair 的角色之外，他還是WEBTRANS和AVTCORE工作組的Co-Chair以及ORTC、WebRTC-SVC、WebRTC-NV Use Cases、WebRTC-ICE、WebTransport和WebRTC-QUIC文檔的編輯。不要忘記，WebRTC在IETF中也是部分標(biāo)準(zhǔn)化的，同時(shí)Bernard也是WEBTRANS和AVTCORE WGs的Co-Chair。在微軟，他是微軟團(tuán)隊(duì)媒體組織的首席架構(gòu)師，該組織名為IC3，支持微軟團(tuán)隊(duì)和基于團(tuán)隊(duì)基礎(chǔ)設(shè)施的其他項(xiàng)目，如Azure通信服務(wù)(Gustavo在此發(fā)布了相關(guān)信息)。

WebRTC標(biāo)準(zhǔn)化狀況 作為W3C WebRTC工作組的Chair之一，Bernard是WebRTC標(biāo)準(zhǔn)化過(guò)程中的權(quán)威人物。我首先向他詢(xún)問(wèn)了工作組目前的章程。

Bernard：正如在2020年4月在W3C的演講中所討論的，WebRTC 工作組章程描述了三個(gè)領(lǐng)域的工作： 1. 完成第一優(yōu)先的網(wǎng)絡(luò)實(shí)時(shí)通信對(duì)等連接（WebRTC-PC），以及網(wǎng)絡(luò)實(shí)時(shí)通信統(tǒng)計(jì)等相關(guān)規(guī)范，例如WebRTC-Stats。 2. 捕獲、流和輸出相關(guān)規(guī)范，包括媒體捕獲和流、屏幕捕獲、從DOM元素中捕獲媒體、媒體流圖像捕獲、媒體流錄制、音頻輸出設(shè)備和內(nèi)容提示。 3. WebRTC-NV，WebRTC的“下一個(gè)版本”。 WebRTC-NV是WebRTC的“下一個(gè)版本”。這是當(dāng)前1.0規(guī)范之后的內(nèi)容。

Bernard：WebRTC-NV的工作分為四大類(lèi)。 1. 一類(lèi)是WebRTC對(duì)等連接的擴(kuò)展。這包括WebRTC擴(kuò)展，WebRTC-SVC和可插入流。我要提到的是，網(wǎng)絡(luò)實(shí)時(shí)傳輸中心建議和所有依賴(lài)于實(shí)時(shí)傳輸中心連接的工作都需要RTCPeerConnection“統(tǒng)一計(jì)劃”，這是所有瀏覽器中默認(rèn)的SDP語(yǔ)言。例如，如果不首先支持“統(tǒng)一計(jì)劃”，就不可能利用可插入流在您的應(yīng)用程序中支持端到端加密。 2. 第二類(lèi)涉及不符合WebRTC-PC建議中包含的實(shí)施或成熟度要求的功能，如WebRTC Identity、WebRTC Priority Control和WebRTC DSCP。 3. 第三類(lèi)是對(duì)Capture的擴(kuò)展，如MediaStreamTrack可插入流，Media Capture和Streams擴(kuò)展以及MediaCapture深度流擴(kuò)展(最近恢復(fù))。 4. 第四類(lèi)是我所說(shuō)的獨(dú)立規(guī)范，它不一定依賴(lài)于RTCPeerConnection或現(xiàn)有的Media Capture規(guī)范。WebRTC-ICE(目前已經(jīng)作為獨(dú)立的規(guī)范實(shí)現(xiàn))屬于這一類(lèi)，W3C WEBRTC工作組之外開(kāi)發(fā)的API規(guī)范也屬于這一類(lèi)，如WebTransport(W3C WebTransport工作組)、WebRTC-QUIC(ORTC工作組)和WebCodecades(WICG工作組)。 鑒于不同的工作類(lèi)別，“NV”一詞有些模糊，可能會(huì)使人困惑。該術(shù)語(yǔ)最初指的是ORTC，但今天它通常指的是多個(gè)規(guī)范，而不是一個(gè)文件。在當(dāng)前的用法中，有模糊之處，因?yàn)椤癗V”可能指的是RTCPeerConnection和現(xiàn)有捕獲應(yīng)用程序接口的擴(kuò)展，或者與RTCPeerConnection或現(xiàn)有捕獲應(yīng)用程序接口無(wú)關(guān)的應(yīng)用程序接口，如WebTransport 和WebCodecs。因此，當(dāng)有人提到“WebRTC-NV”時(shí)，通常有必要詢(xún)問(wèn)后續(xù)問(wèn)題，以了解他們想要的潛在含義。 成為完整推薦的途徑 WebRTC中使用的協(xié)議是由IETF定義的，而W3C定義了瀏覽器使用的API。W3C的正式標(biāo)準(zhǔn)化之路——以及關(guān)于應(yīng)該包括什么的爭(zhēng)論——有時(shí)是一個(gè)有爭(zhēng)議的話題。 Bernard給出了這個(gè)過(guò)程的一些背景和狀態(tài)。 Chad：你能帶領(lǐng)我們的觀眾梳理一遍W3C規(guī)范階段嗎？ Bernard：第一個(gè)標(biāo)準(zhǔn)化階段是CR-候選人推薦。候選人推薦意味著該規(guī)范已經(jīng)過(guò)廣泛審查，符合工作組的要求，并且是可實(shí)施的。在CR，規(guī)范可能沒(méi)有完全實(shí)現(xiàn)(那里可能存在“功能風(fēng)險(xiǎn)”)，瀏覽器之間可能存在互通性問(wèn)題。 您在這（https://www.w3.org/2020/Process-20200915/）可以看到描述的全部過(guò)程細(xì)節(jié)。 Chad：你說(shuō)的最后一個(gè)CR，我猜是暗示可以有多個(gè)CR，或者說(shuō)CR過(guò)程是一個(gè)多階段的事情？ Bernard：還有一個(gè)新的W3C過(guò)程，在這個(gè)過(guò)程中，基本上你有實(shí)時(shí)的規(guī)范。我們只能說(shuō)，在我們就這兩個(gè)問(wèn)題提出建議之前，我們已經(jīng)是最后一個(gè)了。 所以PR [Proposed Recommendation]是你試圖證明規(guī)范中的所有內(nèi)容都已經(jīng)實(shí)現(xiàn)并且通過(guò)了你的互通性標(biāo)準(zhǔn)的階段。然后是推薦，甚至更遠(yuǎn)。下一步是PR，我們正在收集你需要的所有數(shù)據(jù)。在對(duì)等連接的情況下，這是大量的數(shù)據(jù)，因?yàn)槟枰械幕ゲ僮鳒y(cè)試，包括您的WPT測(cè)試結(jié)果，還可能包括您的KITE測(cè)試結(jié)果。

WPT是指Web平臺(tái)測(cè)試，這是W3C檢查API實(shí)現(xiàn)的一組測(cè)試。結(jié)果位于https://wpt.fyi。

KITE是一個(gè)開(kāi)源的互通性測(cè)試項(xiàng)目，專(zhuān)門(mén)針對(duì)WebRTC。Alex Gouaillard博士在他的博客帖子《轉(zhuǎn)折點(diǎn)：SFU博客負(fù)載測(cè)試》中討論了這一點(diǎn)。

Chad：WPT是 wpt.fyi ，這是一種通用的自動(dòng)化特性測(cè)試，而KITE是WebRTC特定的互操作測(cè)試。 Bernard：WPT網(wǎng)絡(luò)廣播公司的測(cè)試運(yùn)行在單一的瀏覽器上。我們?cè)赪PT沒(méi)有針對(duì)網(wǎng)絡(luò)實(shí)時(shí)傳輸?shù)姆?wù)器測(cè)試，但是有針對(duì)網(wǎng)絡(luò)傳輸?shù)姆?wù)器測(cè)試。因此，WebRTC WPT測(cè)試沒(méi)有展示瀏覽器之間或?yàn)g覽器和會(huì)議服務(wù)器之間的互操作性，而KITE測(cè)試是在瀏覽器和潛在的多個(gè)實(shí)體之間進(jìn)行的。 Chad：這是WebRTC特有的——你實(shí)際上是在向不同的瀏覽器發(fā)送媒體。 Bernard：為了理解WPT測(cè)試覆蓋率的水平，我們已經(jīng)對(duì)規(guī)范進(jìn)行了注釋。因此，除了測(cè)試結(jié)果之外，你還想知道測(cè)試實(shí)際覆蓋了多少規(guī)范。 新冠疫情減緩了標(biāo)準(zhǔn)工作 WebRTC對(duì)WebRTC產(chǎn)生了一些有趣的影響。這讓我們WebRTC社區(qū)的所有人都忙得不可開(kāi)交，更加關(guān)注所有新流量的可擴(kuò)展性和可靠性。然而，這種焦點(diǎn)的改變會(huì)對(duì)現(xiàn)有的過(guò)程造成很大的破壞。這也適用于標(biāo)準(zhǔn)化工作嗎？ Bernard：底線是，我們正在努力收集所有這些證據(jù)，我們將向W3C提交這些證據(jù)，以表明我們已經(jīng)為建議階段做好了準(zhǔn)備。這是非常大的一步，但進(jìn)展被病毒拖慢了。我的意思是，我們認(rèn)為我們會(huì)在實(shí)施過(guò)程中取得更大的進(jìn)展，但病毒已經(jīng)讓每個(gè)人都慢了下來(lái)。 Chad：那是因?yàn)槿藗兠τ谧鲋С炙麄?a target="_blank">產(chǎn)品的事情，還是因?yàn)閷?shí)際上你們不能經(jīng)常聚在一起？ Bernard：新冠疫情打亂了很多事情。例如，KITE互操作測(cè)試通常是在IETF活動(dòng)中親自進(jìn)行的，但是我們還沒(méi)有能夠親自參加IETF。我們一直在努力弄清楚如何才能完成測(cè)試，但如果沒(méi)有每個(gè)人都在同一個(gè)地方，這很難。如果你在世界各地，在同一時(shí)間同一地點(diǎn)組織每個(gè)人的能力真的很難。想象一下，現(xiàn)在是凌晨3點(diǎn)，你需要和世界另一端不同時(shí)區(qū)的人進(jìn)行互操作性測(cè)試。 這場(chǎng)全球性的疫情不僅破壞了測(cè)試，而且還影響了實(shí)施計(jì)劃，如融合圖所示。雖然建議中的幾乎所有功能都已經(jīng)在至少一個(gè)瀏覽器中實(shí)現(xiàn)，但我們最初認(rèn)為，到2020年秋季，我們將在兩個(gè)或多個(gè)瀏覽器代碼庫(kù)中實(shí)現(xiàn)更多功能。因此，實(shí)施進(jìn)度和測(cè)試都不是我們所期望的。

資料來(lái)源：TPAC-2020-Meetings https://docs.google.com/presentation/d/1WHocMl47fukck4YQ6RuPzfagAj6bW0SjUELzwguC3qs/edit#slide=id.ga427533723_4_218 標(biāo)準(zhǔn)化有多重要？ 在過(guò)去的幾年里，幾乎每一個(gè)更新的Web瀏覽器都實(shí)現(xiàn)了WebRTC。WebRTC正在支持世界上很大一部分的IP語(yǔ)音(VoIP)流量。在這一點(diǎn)上，進(jìn)入標(biāo)準(zhǔn)化的下一個(gè)階段是否重要？ Bernard指出，標(biāo)準(zhǔn)化不僅僅是編寫(xiě)規(guī)范——它實(shí)際上是關(guān)于互操作性的。 Bernard：標(biāo)準(zhǔn)化把注意力集中在測(cè)試和穩(wěn)定性上。WebRTC對(duì)等連接的最大挑戰(zhàn)之一就是它的廣度。我們每天都只是從重要的bug中學(xué)習(xí)。我們發(fā)現(xiàn)我們的覆蓋面并不是我們理想中的樣子。我們還了解到，即使是我所說(shuō)的可接受的測(cè)試覆蓋率，也是多么困難。最近出現(xiàn)了一堆像復(fù)用這樣的問(wèn)題，它們實(shí)際上對(duì)現(xiàn)有的服務(wù)有很大的影響，我們沒(méi)有對(duì)它們進(jìn)行測(cè)試。我們?cè)谶@些錯(cuò)誤身上看到的是，它們不是WPT遇到的那種問(wèn)題。本質(zhì)上需要像KITE框架這樣的東西來(lái)做的事情，我們?cè)贙ITE中還沒(méi)有達(dá)到百分之百的測(cè)試覆蓋率。 總的來(lái)說(shuō)，我在實(shí)時(shí)通信和網(wǎng)絡(luò)其他方面經(jīng)歷的最大區(qū)別之一是測(cè)試矩陣的巨大規(guī)模。如果我告訴你Chad，我想讓你去開(kāi)發(fā)，得到95%的覆蓋率。我認(rèn)為通過(guò)測(cè)試的過(guò)程是有幫助的，但它也讓我們意識(shí)到真正涵蓋一切的挑戰(zhàn)的規(guī)模。這很艱難。 WebRTC擴(kuò)展 你可以用WebRTC做的事情越來(lái)越多。正如Bernard剛才提到的，WebRTC 1.0正在通過(guò)標(biāo)準(zhǔn)過(guò)程，所以他們必須在某個(gè)地方添加新功能。正如Bernard將解釋的那樣，WebRTC擴(kuò)展是一些沒(méi)有進(jìn)入WebRTC 1.0的功能的家園。 Bernard：有一系列的規(guī)范依賴(lài)于RTCPeerConnection。WebRTC擴(kuò)展就是其中之一。這些是為WebRTC PC增加功能的規(guī)范。這里有很多東西，例如，實(shí)時(shí)傳輸協(xié)議報(bào)頭擴(kuò)展加密。WebRTC SVC（可拓展視頻編碼）不在WebRTC擴(kuò)展文檔中，但我認(rèn)為它是一個(gè)擴(kuò)展。我認(rèn)為可插入流是WebRTC PC（其編碼版本）的擴(kuò)展，它的編碼版本。這些都是在假設(shè)你有RTCPeerConnection的基礎(chǔ)上。 getCurrentBrowsingContextMedia 隨著視頻會(huì)議使用的增加，已經(jīng)有幾個(gè)關(guān)于網(wǎng)絡(luò)攝像頭出錯(cuò)和意外屏幕共享的高調(diào)故事。與此同時(shí)，快速訪問(wèn)網(wǎng)絡(luò)攝像頭通常是WebRTC服務(wù)的一個(gè)問(wèn)題。平衡訪問(wèn)速度和隱私控制是一個(gè)難題。此外，使用getMediaDevices提供的媒體設(shè)備信息進(jìn)行指紋識(shí)別一直是一項(xiàng)隱私挑戰(zhàn)。 getCurrentBrowsingContextMedia提案是解決這些挑戰(zhàn)的一種嘗試。 Chad：我們能報(bào)道一下getCurrentBrowsingContextMedia媒體提案嗎？ Bernard：這真是一個(gè)擴(kuò)展，我認(rèn)為這是對(duì)屏幕截圖的擴(kuò)展。讓我來(lái)談?wù)刐媒體]的捕獲問(wèn)題——捕獲的很多焦點(diǎn)都集中在隱私和安全上。我們發(fā)現(xiàn)媒體捕捉流對(duì)隱私并沒(méi)有什么好處。假設(shè)你將為應(yīng)用程序提供設(shè)備上的所有信息，無(wú)論它們是否被選中，然后讓它創(chuàng)建自己的選擇器。這是指紋識(shí)別的一個(gè)真正問(wèn)題，因?yàn)楝F(xiàn)在我知道你機(jī)器上的所有設(shè)備。即使你不想用那個(gè)相機(jī)，但我知道它在那里。因此，這真的有助于識(shí)別你的指紋，Jan-Ivar一直建議我們轉(zhuǎn)向另一種更類(lèi)似于屏幕截圖的模型。 在屏幕捕捉中，你只能訪問(wèn)用戶(hù)選擇的捕捉表面。所以，我不能訪問(wèn)你所有的應(yīng)用程序，我可以看到每個(gè)窗口，然后我決定作為一個(gè)應(yīng)用程序來(lái)購(gòu)買(mǎi)我想看的東西。現(xiàn)在用戶(hù)選擇了源，您只能訪問(wèn)它。這是Jan-Ivar提出的媒體捕捉和流模式。本質(zhì)上，它將成為瀏覽器選擇器的一部分。該應(yīng)用程序只能訪問(wèn)用戶(hù)選擇的設(shè)備上的信息。這是一個(gè)很大的變化。它也對(duì)媒體捕捉和screams的一些基礎(chǔ)提出了質(zhì)疑。例如，如果用戶(hù)無(wú)論如何都要選擇，那么約束的目的是什么？ Chad：這是否意味著更多關(guān)于設(shè)備選擇器的規(guī)范？ Bernard：我認(rèn)為它的作用是。然而，我們已經(jīng)決定將我們的模型進(jìn)行或多或少改進(jìn)。然后， Jan-Ivar 為這個(gè)新模型創(chuàng)建了一個(gè)單獨(dú)的規(guī)范，可以解決所有這些問(wèn)題。棘手的是，這是一個(gè)非常不同的模式。當(dāng)人們習(xí)慣于應(yīng)用選擇器時(shí)，如何過(guò)渡到新的模式？這可能從用戶(hù)習(xí)慣來(lái)看需要很長(zhǎng)時(shí)間。

WebRTC NV 標(biāo)準(zhǔn)之爭(zhēng)的一個(gè)后果是不愿意指定正式的版本名稱(chēng)，因?yàn)槊總€(gè)人對(duì)什么是主要版本(即1.0、2.0)和次要版本(即1.1、1.2等)有不同的看法。曾經(jīng)也有一個(gè)被稱(chēng)為ORTC的替代推薦，有時(shí)被定位為WebRTC的繼任者，我們將在一個(gè)大型的。WebRTC 1.0圍繞我們討論的當(dāng)前規(guī)范進(jìn)行了整合。盡管如此，關(guān)于接下來(lái)會(huì)發(fā)生什么仍有很多爭(zhēng)論。他們最終決定用一個(gè)非常溫和、不精確的術(shù)語(yǔ)來(lái)命名接下來(lái)的一切：“WebRTC下一個(gè)版本”或WebRTC-NV。 Bernard解釋了這意味著什么。 Chad：我們談了一點(diǎn)關(guān)于我們將在“下一個(gè)版本”的WebRTC中看到什么——我想我們不會(huì)稱(chēng)之為2.0，因?yàn)?.0還沒(méi)有完成？ Bernard：我想也許是時(shí)候我們應(yīng)該考慮去掉整個(gè)NV這個(gè)術(shù)語(yǔ)了，因?yàn)樗鼘?shí)際上可以指兩種潛在的非常不同的東西。一個(gè)是我提到的對(duì)等連接的擴(kuò)展——比如可插入流、WebRTC擴(kuò)展、WebRTC SVC。我的想法是，當(dāng)你把所有這些規(guī)格放在一起時(shí)，它們加起來(lái)的功能水平和ORTC一樣。因此，我們已經(jīng)將大部分ORTC對(duì)象模型整合到了WebRTC PC中。 另一個(gè)非常獨(dú)立的軌道是我所說(shuō)的獨(dú)立規(guī)格。這包括像網(wǎng)絡(luò)傳輸、WebCodecs、網(wǎng)絡(luò)實(shí)時(shí)通信等——這些都是完全獨(dú)立的東西，不依賴(lài)于RTCPeerConnection。所以這真的是下一代與現(xiàn)在的一種決裂。 顯然，還早著呢。WebTransport是一個(gè)原始試用版。WebCodecs是Chrome的原始試用版。現(xiàn)在，這是非常不同的，因?yàn)槟阍?jīng)作為整體WebRTC PC的一部分獲得的許多東西現(xiàn)在必須用Web Assembly編寫(xiě)。所以這是一個(gè)非常非常不同的開(kāi)發(fā)模型。 有些東西不在那里。例如WebTransport現(xiàn)在本質(zhì)上是客戶(hù)端服務(wù)器。我們已經(jīng)編寫(xiě)了一個(gè)對(duì)等擴(kuò)展，不久前有一個(gè)最初的試用版，但是現(xiàn)在是客戶(hù)端服務(wù)器。因此，您不能只使用現(xiàn)有的WebCodecs和網(wǎng)絡(luò)傳輸來(lái)編寫(xiě)完整的WebRTC PC用例。 我要說(shuō)的是，在WebRTC NV中發(fā)生的另一件事已經(jīng)變得非常重要，那就是人們對(duì)機(jī)器學(xué)習(xí)和訪問(wèn)原始媒體有了真正的關(guān)注。這是ORTC沒(méi)有提供的。在某種意義上，我想說(shuō)的是，網(wǎng)絡(luò)傳輸或WebCodecs模型在這方面甚至比ORTC還低。ORTC沒(méi)有讓你直接訪問(wèn)解碼器和編碼器。這就是你從WebCodecs中得到的。所以我認(rèn)為我們采納了ORTC的想法，并將其應(yīng)用到更低的傳輸層。 ORTC怎么了？ 對(duì)象實(shí)時(shí)傳輸控制(ORTC)是網(wǎng)絡(luò)實(shí)時(shí)傳輸控制的一個(gè)替代模型，它提供了不使用軟件開(kāi)發(fā)平臺(tái)的低級(jí)控制。Bernard是它的作者之一，微軟在ORTC的支持下推出了最初的Edge。我們?cè)僖猜?tīng)不到很多關(guān)于ORTC的事情了，那么它發(fā)生了什么？正如Bernard剛才解釋的那樣，大部分內(nèi)容都被吸收到了WebRTC的核心標(biāo)準(zhǔn)中。這是ORTC愿景的失敗還是勝利？ Chad：你是ORTC原始規(guī)范的作者之一。與您最初的ORTC愿景相比，您認(rèn)為我們現(xiàn)在的狀況如何？ Bernard：對(duì)象模型完全在Chromium瀏覽器中。因此，我們幾乎擁有了來(lái)自O(shè)RTC的所有對(duì)象——Ice Transport、DTLS Transport傳輸、SCTP Transport (來(lái)自數(shù)據(jù)通道)——所有這些對(duì)象現(xiàn)在都在WebRTC PC和Chromium瀏覽器中。 RTC也有先進(jìn)的功能，如聯(lián)播和SVC，我們已經(jīng)納入。此外，我們有比原始的ORTC通過(guò)端到端加密，可以通過(guò)可插入的流支持。因此，我們已經(jīng)用對(duì)象模型和所有這些擴(kuò)展將WebRTC PC等同于ORTC。 我們期待的場(chǎng)景是像物聯(lián)網(wǎng)這樣只關(guān)注數(shù)據(jù)傳輸?shù)臇|西。您可以看到這反映在WebRTC和用例中——這些場(chǎng)景就像對(duì)等數(shù)據(jù)交換一樣。 網(wǎng)絡(luò)傳輸 WebTransport是W3C的另一個(gè)規(guī)范，有自己的工作組和規(guī)范。你會(huì)看到很多熟悉的涉及WebRTC 的名字，包括Bernard。 QUIC是一種改進(jìn)的傳輸協(xié)議——有點(diǎn)像網(wǎng)絡(luò)傳輸可以使用的“TCP/2”。 Chad：那么什么是WebTransport，它是從哪里來(lái)的，和WebRTC有什么關(guān)系呢？ Bernard：網(wǎng)絡(luò)傳輸既是一個(gè)API，又是W3C網(wǎng)絡(luò)傳輸組的成員。它也是IETF中的一系列協(xié)議——一系列傳輸。協(xié)議包括QUIC上的網(wǎng)絡(luò)傳輸，稱(chēng)為QUIC傳輸，也包括HTTP/3和潛在的HTTP/2上的網(wǎng)絡(luò)傳輸。所以W3C中的網(wǎng)絡(luò)傳輸API只適用于QUIC和HTTP/3。HTTP/2被認(rèn)為是一種故障轉(zhuǎn)移傳輸，它可能有一個(gè)單獨(dú)的API。那個(gè)API是客戶(hù)端服務(wù)器API。構(gòu)造函數(shù)和一切都很像WebSocket。在構(gòu)造函數(shù)網(wǎng)絡(luò)傳輸構(gòu)造函數(shù)中，你給它一個(gè)網(wǎng)址，然后你會(huì)得到一個(gè)網(wǎng)絡(luò)傳輸。但是它是不同的，因?yàn)槟梢詣?chuàng)建可靠的流和數(shù)據(jù)報(bào)。 Chad：數(shù)據(jù)包，就像UDP中用于快速但不可靠的傳輸一樣。 Bernard：它是雙向的，也就是說(shuō)，一旦網(wǎng)絡(luò)傳輸由客戶(hù)端發(fā)起，但是一旦連接建立，服務(wù)器可以向客戶(hù)端發(fā)起單向雙向流，數(shù)據(jù)報(bào)可以來(lái)回流動(dòng)。 Chad：雙向，就像雙向通信一樣？ Bernard：WebSocket實(shí)際上只是客戶(hù)端。WebSocket不能由服務(wù)器啟動(dòng)，但網(wǎng)絡(luò)傳輸可以。在基于QUIC的網(wǎng)絡(luò)傳輸中，連接不是共享的。在針對(duì)HTTP/3的網(wǎng)絡(luò)傳輸中，它可以被匯集在一起——這創(chuàng)造了一系列非常有趣的場(chǎng)景，其中一些場(chǎng)景恢復(fù)了IETF BoF。考慮一下，你可以同時(shí)進(jìn)行HTTP/3請(qǐng)求-響應(yīng)和網(wǎng)絡(luò)傳輸，包括流，以及在同一個(gè)QIUC連接上的數(shù)據(jù)報(bào)。 這是Justin Uberti為IETF的一個(gè)名為RIPT BOF的項(xiàng)目設(shè)計(jì)的一個(gè)場(chǎng)景，讓人們大吃一驚。在這種情況下，你有一個(gè)來(lái)回的RPC-請(qǐng)求-響應(yīng)，但RPC-導(dǎo)致從服務(wù)器到客戶(hù)端的流。所以把它想象成一個(gè)客戶(hù)說(shuō)，我想播放這部電影，或者玩這個(gè)游戲，再或者參加這個(gè)視頻會(huì)議，然后一個(gè)可能是可靠的QUIC流的流，或者可能是一個(gè)來(lái)自服務(wù)器的數(shù)據(jù)報(bào)流。 我認(rèn)為WebTransport有潛力給網(wǎng)絡(luò)帶來(lái)革命性的變化。HTTP/3本身就是對(duì)Web的革命性改變。這場(chǎng)革命的大部分是在更復(fù)雜的版本中，即HTTP/3池傳輸。QUIC傳輸要簡(jiǎn)單得多，它只給了我一個(gè)socket，我可以在上面來(lái)回發(fā)送東西。 Chad：WebTransport還有多遠(yuǎn)？ Bernard：我想說(shuō)WebTransport API現(xiàn)在已經(jīng)相當(dāng)完善了，它剛剛完成它的原始測(cè)試，試用版本以M88結(jié)束。有幾個(gè)bug，有些東西不太好用，但是API比較打磨。您可以用它編寫(xiě)一個(gè)相當(dāng)復(fù)雜的示例代碼。我想這是因?yàn)槲覀冇脤?shí)際代碼更新了規(guī)范。所以如果你讀了這個(gè)規(guī)范，你就可以用代碼來(lái)做這些事情了。希望我們很快會(huì)在那里提供一個(gè)完整的例子，你可以嘗試一下。 在服務(wù)器端，仍然有一些QUIC互操作問(wèn)題。所以我認(rèn)為人們使用的服務(wù)器是aioquic（Python庫(kù)），你也可以使用quiche作為服務(wù)器，但是它沒(méi)有集成到框架中。不幸的是，我們沒(méi)有Node.JS服務(wù)器，擁有它真的很好——那可能很遙遠(yuǎn)。 Chad：正如Bernard所說(shuō)，WebTransport是客戶(hù)端服務(wù)器，而不是像WebRTC那樣的對(duì)等(P2P)。然而，我們已經(jīng)看到了P2P QUIC的預(yù)覽版。事實(shí)上，F(xiàn)ippo早在2019年2月就在QUIC數(shù)據(jù)頻道上寫(xiě)了一篇文章。與這種新的網(wǎng)絡(luò)傳輸方法相比有何不同？ Bernard：那是ORTC風(fēng)格的。它不支持WHATWG/W3C流，也是基于gQUIC協(xié)議，而不是IETF的QUIC。WebTransport——代碼在Chrome中——基于WHATWG流，也基于IETF QUIC。所以RTCQuicTransport代碼非常過(guò)時(shí)，因?yàn)樗仁且粋€(gè)舊的API，也是一個(gè)舊的協(xié)議。那個(gè)代碼已經(jīng)從Chromium中刪除了。 Chad：那么，對(duì)于低延遲的場(chǎng)景，我們?nèi)绾螌?shí)現(xiàn)Peer-to-Peer WebTransport呢？ Bernard：我們有一個(gè)小的擴(kuò)展規(guī)范，它仍然在ORTC CG中。基本上認(rèn)為它只是一個(gè)WebTransport，但是你讓它運(yùn)行在RTCIceTransport上，而不是一個(gè)URL上。所以要做構(gòu)建，你不給它一個(gè)URL，而是給它一個(gè)ICE Transport。 你就是這么構(gòu)造的。有一些ORTC的東西基本上是從RTCDtlsTransport中提取的，你可以添加到對(duì)等的東西中。但是擴(kuò)展規(guī)范只有幾頁(yè)。它非常非常小，就像95%的網(wǎng)絡(luò)傳輸規(guī)范完全一樣。 Chad：有人構(gòu)建過(guò)嗎？ Bernard：我們還沒(méi)有新的應(yīng)用編程接口和新的QUIC庫(kù)的工作版本。沒(méi)有新東西的版本。RTCQuicTransport的一個(gè)特點(diǎn)是它是獨(dú)立的。今天Chromium中有一個(gè)代碼，叫做WebRTC ICE。想象一下從網(wǎng)絡(luò)實(shí)時(shí)傳輸中心到PC的洲際交易所傳輸——這是一個(gè)獨(dú)立的實(shí)時(shí)傳輸中心版本。當(dāng)您從一個(gè)RTCQuicTransport構(gòu)造一個(gè)RTCQuicTransport時(shí)，它不會(huì)與您的對(duì)等連接組件復(fù)用。 它在一個(gè)單獨(dú)的端口上。現(xiàn)在我們不得不在過(guò)去的RTCQuicTransport中這樣做，因?yàn)間QUIC不能與RTP/RTCP STUN和TURN復(fù)用。IETF QUIC可以復(fù)用。 Chad：gQUIC是來(lái)自谷歌的QUIC的原版。這聽(tīng)起來(lái)可能會(huì)對(duì)IP端口的使用產(chǎn)生很大影響，捆綁有助于通過(guò)防火墻限制端口使用。 Bernard：開(kāi)發(fā)人員會(huì)希望在同一個(gè)端口上使用QUIC作為他們所有其他的音頻和視頻工具嗎？如今在WebRTC PC中，捆綁銷(xiāo)售非常非常流行。每個(gè)人都在同一個(gè)端口上把所有東西推在一起——這遠(yuǎn)遠(yuǎn)超過(guò)了WebRTC所有使用的99%。有人可能會(huì)認(rèn)為QUIC會(huì)有類(lèi)似的需求。如果這是他們真正想要的，我們不想用ORTC風(fēng)格化的交通工具來(lái)建造(快速傳輸)；你希望能夠從一個(gè)網(wǎng)絡(luò)傳輸中心的PC上構(gòu)建它。 這有點(diǎn)奇怪，因?yàn)楝F(xiàn)在你說(shuō)部分網(wǎng)絡(luò)傳輸依賴(lài)于RTCPeerConnection。

RPC設(shè)置以通過(guò)WebTransport發(fā)送媒體。來(lái)源：IETF 107 – Justin Uberti，107-ript-rtc-implementation-experiences（https://www.ietf.org/proceedings/107/slides/slides-107-ript-rtc-implementation-experiences-00） Simulcasts WebTransport似乎是一種全新的潛在處理方式。但如今困擾WebRTC實(shí)現(xiàn)的一些棘手問(wèn)題主要是，幾乎每一個(gè)主要的WebRTC視頻會(huì)議服務(wù)中都有Simulcast，參與者眾多，并且在標(biāo)準(zhǔn)化和互操作性方面一直處于掙扎狀態(tài)。 Chad：Simulcasts是如何進(jìn)行的？ Bernard：據(jù)稱(chēng)，在Chromium中，所有編解碼器都支持with simulcast，或者至少是現(xiàn)在所有的編解碼器。因此，從理論上講，你應(yīng)該能夠使用H.264，VP8和VP9做到這一點(diǎn)。 我們一直在尋找錯(cuò)誤，也遇到過(guò)一些非常可怕的錯(cuò)誤，例如H264無(wú)法正常工作。我們已經(jīng)進(jìn)行了完整的KITE測(cè)試，但是還需要一個(gè)簡(jiǎn)單的回送測(cè)試測(cè)試基本操作，你可以在其中向自己發(fā)送Simulcast。最終Fippo編寫(xiě)了回送測(cè)試。 如果你想查看該測(cè)試，在Fippo的“simulcast playground”（https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/）帖子中。 Bernard：該測(cè)試并未在所有瀏覽器上通過(guò)。它之所以沒(méi)有通過(guò)，是因?yàn)槟惆l(fā)送了RID，被SDP欺騙了，并以MID的形式接收了它們。因此，從本質(zhì)上講，如果你發(fā)送了三個(gè)流，則可以取回三個(gè)流，但是它們各自位于不同的MID上。 Firefox不支持MID RTP標(biāo)頭擴(kuò)展。所以，實(shí)際上該環(huán)回測(cè)試無(wú)效。 我們發(fā)現(xiàn)無(wú)論何時(shí)編寫(xiě)測(cè)試，都會(huì)發(fā)現(xiàn)一些不太清楚的地方。 我再給你舉一個(gè)奇怪的例子，我們一直在進(jìn)行硬件加速方面的工作。事實(shí)證明，當(dāng)你使用硬件加速器時(shí)，可以獲得不同的比特流。它不僅使事情變得更快，實(shí)際上是改變了編解碼器的比特流，然后你就可以開(kāi)始破壞互操作了。你進(jìn)行了Simulcast測(cè)試，突然SFU無(wú)法處理即將發(fā)生的一切。我真的希望我們能夠在這些IETF會(huì)議之一中親自見(jiàn)面，進(jìn)行另一次Simulcast測(cè)試，就像Alex博士能夠做的那樣，看看我們?cè)谀睦铩? 你知道，如果每個(gè)人都在交付統(tǒng)一計(jì)劃，我們會(huì)很好。 Chad：統(tǒng)一計(jì)劃是一種新的、標(biāo)準(zhǔn)化的SDP格式，除其他外，它指定了應(yīng)如何在SDP中處理聯(lián)播流。統(tǒng)一計(jì)劃不應(yīng)該成為節(jié)省一天的規(guī)范嗎？而我們?yōu)槭裁礇](méi)有這么做？ Bernard：如果每個(gè)人都對(duì)所有編解碼器都使用統(tǒng)一計(jì)劃，并且[互操作測(cè)試]都很高興，那么你會(huì)知道一切正常。我們還不在附近。讓我這樣說(shuō)–我們功能完善。我認(rèn)為這是事實(shí)，但是事情在測(cè)試范圍內(nèi)不斷下滑。我不會(huì)說(shuō)每個(gè)瀏覽器都具有發(fā)布商業(yè)應(yīng)用程序所需的所有功能。舉例來(lái)說(shuō)，例如，我認(rèn)為確實(shí)有很多商業(yè)應(yīng)用程序都在多個(gè)瀏覽器上發(fā)布，但我認(rèn)為在所有瀏覽器上都發(fā)布的應(yīng)用很少。 因此，考慮到這種情況的一種方法（可能比所有這些測(cè)試結(jié)果要容易一些）是，如果你對(duì)所有主要會(huì)議服務(wù)及其運(yùn)行的所有瀏覽器以及所有不同的模式進(jìn)行了矩陣分析，則可能會(huì)發(fā)現(xiàn)最好看看我們實(shí)際上在哪里。 一直以來(lái)這都不是很令人鼓舞。多數(shù)服務(wù)都支持大多數(shù)瀏覽器是很好的，但是你經(jīng)常會(huì)看到各種功能支持以及跨瀏覽器的稍微不同的體驗(yàn)。

由于原文篇幅較長(zhǎng)，為保證讀者的閱讀體驗(yàn)，本文后半部分內(nèi)容將安排在下周發(fā)布。

責(zé)任編輯：lq