我們看一下網(wǎng)頁(yè)端的實(shí)時(shí)通信有什么樣的特點(diǎn)。
首先，在瀏覽器端，依賴(lài)于瀏覽器獲取音視頻的能力，以及強大的網(wǎng)頁(yè)上的渲染能力，所以，就能夠為高清的通信體驗打下基礎。同時(shí)，相比移動(dòng)端來(lái)說(shuō)，屏幕比較大，視窗選擇也比較靈活。
第二，跨平臺。大家都了解瀏覽器對各個(gè)終端的特殊性，不止PC上有瀏覽器、移動(dòng)端上有瀏覽器，甚至是一些知名的社交APP也嵌入了瀏覽器。這需要一個(gè)跨平臺的體驗，現在支持WebRTC的瀏覽器也越來(lái)越多了，這也是網(wǎng)頁(yè)實(shí)時(shí)通信的一個(gè)特點(diǎn)
第三，免安裝，方便接入。隨著(zhù)WebRTC的普及，它不需要安裝任何插件就可以實(shí)現網(wǎng)頁(yè)端的實(shí)時(shí)通信。
再來(lái)看一下網(wǎng)頁(yè)端實(shí)時(shí)通信可以應用在什么場(chǎng)景里？
首先是直播，直播非常火。直播的主播端會(huì )有需求，在網(wǎng)頁(yè)端進(jìn)行開(kāi)播，因為網(wǎng)頁(yè)端的屏幕比較大、視頻比較清晰、處理能力比較強。同時(shí)，也非常有意思，我們一個(gè)客戶(hù)也在用我們網(wǎng)頁(yè)端的SDK做直播的監控。大家也知道，直播開(kāi)播的房間數很多，在一個(gè)網(wǎng)頁(yè)上可以監控40-50個(gè)房間，來(lái)做直播的巡視員，用網(wǎng)頁(yè)端的實(shí)時(shí)音視頻SDK是比較方便的。
另外一個(gè)是在線(xiàn)教育，在線(xiàn)教育的老師端一般都在PC上，如果要安裝應用程序，有些老師也不是很懂電腦技術(shù)，要去配置的話(huà)就比較麻煩。如果有網(wǎng)頁(yè)端免安裝的方案的話(huà)，他們用起來(lái)的話(huà)，用戶(hù)體驗也會(huì )比較好。在線(xiàn)教育除了音視頻，還要求有屏幕共享、白板，因為都是H5的技術(shù)，所以與Web端的SDK集成起來(lái)的話(huà)也會(huì )非常方便。
最后就是視頻會(huì )議，大家在公司里用過(guò)瀏覽器的視頻會(huì )議的話(huà)都會(huì )有體驗，HR發(fā)一個(gè)鏈接，某一個(gè)時(shí)間點(diǎn)你點(diǎn)這個(gè)鏈接，除此之外還有一些說(shuō)明，你要安裝哪些東西，這個(gè)會(huì )比較復雜。現在有了免安裝的WebRTC之后，大家對視頻會(huì )議的體驗也會(huì )上升一個(gè)臺階。這邊列的這幾個(gè)是比較典型的場(chǎng)景，其實(shí)還有遠程醫療、企業(yè)協(xié)作之類(lèi)的。
接下來(lái)從技術(shù)上分析一下，網(wǎng)頁(yè)端的實(shí)時(shí)通信是否已經(jīng)成熟？是否已經(jīng)準備好了？
如果說(shuō)到網(wǎng)頁(yè)端、瀏覽器端的實(shí)時(shí)通信的話(huà)，大家首先會(huì )想到的就是Webex，它的體驗是非常不錯的，也培養了一大群目標用戶(hù)，讓用戶(hù)認知到在瀏覽器上就可以進(jìn)行視頻的溝通，打開(kāi)了一個(gè)市場(chǎng)。但是，它有一個(gè)缺點(diǎn)，就是必須安裝瀏覽器的插件和擴展程序，和GoToMeeting是一樣的，非常不方便。另一種做法是，在PC上安裝一個(gè)應用程序，通過(guò)這個(gè)程序來(lái)代理獲取、處理音視頻的流，網(wǎng)頁(yè)端只是做渲染和展示。
在很長(cháng)一段時(shí)間里，這些網(wǎng)頁(yè)端的用戶(hù)覺(jué)得這個(gè)技術(shù)就是這樣的，體驗就是這樣的，無(wú)法提升了。直到2011年，WebRTC技術(shù)的出現，并且由谷歌做推廣。WebRTC帶來(lái)的體驗是因為免安裝才受到了關(guān)注。現在在差不多6年的發(fā)展時(shí)間里，其實(shí)也有很多的質(zhì)疑聲，比如，Google的項目會(huì )不會(huì )半途而廢，各大瀏覽器廠(chǎng)商會(huì )不會(huì )不支持這種打通瀏覽器生態(tài)的想法。
接下來(lái)我想跟大家從不同的維度來(lái)分析一下WebRTC這個(gè)技術(shù)是否已經(jīng)成熟，是否可以產(chǎn)品化？
首先，來(lái)看一下目前知識WebRTC瀏覽器跟平臺的情況。
最早支持WebRTC的是Firefox和Chrome，之后是Opera，跟隨者chrome支持WebRTC，它們內核是一樣的。微軟前兩年提出了一個(gè)ORTC的協(xié)議，跟WebRTC有些相似。ORTC發(fā)展并不順利，現在在edge中開(kāi)始支持WebRTC。近期蘋(píng)果更新了IOS系統之后，Safari 11也開(kāi)始支持WebRTC了。在安卓平臺上，其實(shí)很早就開(kāi)始支持了WebRTC。
我們看一下這幾個(gè)瀏覽器在市場(chǎng)上的占有情況，不難看出，現在除了占百分之8點(diǎn)幾的IE之外不支持，其他的其實(shí)都已經(jīng)支持了。
我們再從協(xié)議棧的角度來(lái)看一下。WebRTC 1.0 Spec已經(jīng)基本定稿了，除了一些比較細節的問(wèn)題還沒(méi)有最終確認。各個(gè)瀏覽器對標準的支持也越來(lái)越好。雖然谷歌自己也在推廣這個(gè)技術(shù)，但是谷歌自己的瀏覽器Chrome對WebRTC 1.0的支持并不是很好，這是因為谷歌在內部對WebRTC做了很多實(shí)驗性的東西。Chrome團隊對外聲稱(chēng)，會(huì )在今年底，完全跟上WebRTC 1.0的標準。
另外一個(gè)方面，看一下開(kāi)源社區。舉幾個(gè)比較典型的開(kāi)源項目，一個(gè)是Kurento，它是功能比較強大的一個(gè)多媒體處理框架，支持WebRTC協(xié)議棧。它可以作為Media server，后臺有轉碼的能力，并且有OpenCV處理能力。Licode可以作為WebRTC的輕量通信平臺，是純轉發(fā)的服務(wù)器處理模式。Janus可以作為WebRTC通信網(wǎng)關(guān)，比較輕量。值得關(guān)注的是React-Native-WebRTC。現在越來(lái)越多的開(kāi)發(fā)者開(kāi)始轉向前端，JS。這種情況在國外更為普遍。在開(kāi)源社區上出現了這么一個(gè)項目，封裝了一個(gè)WebRTC的模塊，開(kāi)發(fā)者就可以很方便的在手機上來(lái)實(shí)現帶有實(shí)時(shí)通信能力、兼容WebRTC的應用。
最后，看一下生態(tài)圈。在CPaas這一層，有聲網(wǎng)、Twilio、Tokbox這樣的公司在做貢獻。
市場(chǎng)分析對WebRTC非常看好，預計到2022年市場(chǎng)規模將達到64.9億美金。總的來(lái)說(shuō)，WebRTC技術(shù)現在處在一個(gè)最好的時(shí)代。
對于開(kāi)發(fā)者來(lái)說(shuō)，如何用這個(gè)技術(shù)、如何能夠構建起一個(gè)WebRTC的系統？其實(shí)是有一段必經(jīng)之路。
我們知道WebRTC的底層是基于P2P連接，是點(diǎn)對點(diǎn)的通信。很多開(kāi)發(fā)者上手的時(shí)候，都會(huì )去做P2P質(zhì)量的檢驗。比如說(shuō)一個(gè)公司的產(chǎn)品經(jīng)理告訴開(kāi)發(fā)人員說(shuō)“現在WebRTC很火，你給我整一個(gè)WebRTC的系統。”八成的開(kāi)發(fā)人員會(huì )交付這樣一個(gè)網(wǎng)狀結構WebRTC的架構。
那么，完全基于點(diǎn)對點(diǎn)之間通信的架構有什么特點(diǎn)？延時(shí)會(huì )比較小。但是，有一個(gè)很大的缺點(diǎn)。這種點(diǎn)對點(diǎn)音視頻流的傳遞，每一個(gè)用戶(hù)都要給另外一個(gè)用戶(hù)傳自己的視頻流，這樣對它上行帶寬的壓力很大。并且，每一路視頻流都是獨立進(jìn)行采集編碼，這對瀏覽器端編碼壓力的考驗也很大。有人會(huì )問(wèn)，能不能只采集一次編碼，然后就把這個(gè)流發(fā)給不同的終端接收者？很遺憾，這是不行的。因為WebRTC的協(xié)議是做端到端的質(zhì)量策略?xún)?yōu)化，所以它有一些策略調整，都是端對端的RTCP來(lái)實(shí)現，必須要經(jīng)過(guò)多次的編碼，然后分別傳輸給不同的接收者。
右下角的表格列的是一個(gè)權威的行業(yè)機構統計的目前在互聯(lián)網(wǎng)上使用WebRTC的系統架構，純P2P的只占19%。
如果按剛才介紹的這個(gè)架構，開(kāi)發(fā)人員交付給產(chǎn)品的話(huà)，肯定會(huì )打回來(lái)的，因為大家都知道，上行帶寬非常寶貴，也非常受限。為了解決這個(gè)問(wèn)題，開(kāi)發(fā)人員會(huì )做一些深度的研究，發(fā)現領(lǐng)域內的WebRTC架構其實(shí)中間加了一個(gè)點(diǎn)，這個(gè)點(diǎn)就是服務(wù)器，典型的媒體服務(wù)器只做多路流的轉發(fā)，不做后臺的媒體處理和轉碼。
上文提到的Janus和Licode開(kāi)源項目都可以實(shí)現轉發(fā)媒體服務(wù)器的功能。它的特點(diǎn)是，每個(gè)終端用戶(hù)只要上傳一路流到中間服務(wù)器，節省了帶寬。同時(shí)SFU只是做轉發(fā)，所以對延時(shí)的影響相對比較小。弊端是，如果有兩路接收者，下行帶寬的能力不一樣，一個(gè)是500K，一個(gè)是2m，由于源端發(fā)送者只送一路流，所以就很難適配多路的終端。
改成純轉發(fā)的媒體服務(wù)器之后，它還有一些弊端，開(kāi)發(fā)人員又會(huì )想辦法說(shuō)，我在中間這個(gè)節點(diǎn)加上混流的功能。大家也可以從這個(gè)架構當中看出來(lái)，在服務(wù)器端收到不同的兩路視頻流之后，會(huì )分別做解碼、拼接合成、編碼。根據不同接收者的帶寬情況，分別給不同的接收者發(fā)送不同profile的視頻流。這就解決了，如果是多個(gè)接收端的用戶(hù)，無(wú)法做到帶寬的適配。這個(gè)缺點(diǎn)也很明顯，中間做轉碼必然帶來(lái)延時(shí)，其次是轉碼服務(wù)器的成本很高，但是，確實(shí)節省了下行的帶寬，
介紹了幾種典型的WebRTC的系統架構之后，開(kāi)發(fā)人員可以基于剛才說(shuō)的幾個(gè)開(kāi)源項目，可以很方便的搭建出，或者是不用費太多的時(shí)間就可以搭建出這么一個(gè)Demo的系統，是不是故事就到此結束了？其實(shí)還差很遠，這邊還有很多隱藏的坑。
下面再跟大家分享一下，經(jīng)歷過(guò)、探索過(guò)的一些背后的技術(shù)的難點(diǎn)。
上圖是從一個(gè)Demo做成一個(gè)比較穩定的產(chǎn)品，會(huì )遇到的坑。
首先是可用性。WebRTC是基于P2P的，P2P的可用性、連接成功率也是大家一直在詬病的，不止是打洞、穿越這些技術(shù)。
平臺互通：WebRTC出來(lái)的時(shí)間還是有限的，很多領(lǐng)域內的公司都有自己自研的通信協(xié)議，這些協(xié)議一般是用在Native端，手機端、PC端、mac、windows，這也帶來(lái)了一些問(wèn)題，自研的協(xié)議跟WebRTC協(xié)議之間如何可以做到平臺互通？這也有很多的坑在這里面。剛才說(shuō)它是一個(gè)端到端優(yōu)化的傳輸策略，你拆開(kāi)這個(gè)端到端，你的上行是WebRTC，你的發(fā)送者是WebRTC，接收者是自研的端，這里面有很多策略匹配的工作需要去做。
編碼器選擇：音視頻的編碼在實(shí)時(shí)通信中非常重要。WebRTC的視頻，支持VP8/9,H.264。可能有人會(huì )選擇H.264，認為它在移動(dòng)端適應性強。但是H.264在Chrome上不太成熟，所以很多商用產(chǎn)品依然在用VP8，但是涉及到移動(dòng)端的互通，又得考慮編碼器的選擇。
弱網(wǎng)對抗：WebRTC有一套自己的傳輸策略，比如說(shuō)丟包重傳、FEC、帶寬檢測、動(dòng)態(tài)碼率調整。但是，在弱網(wǎng)對抗方面，前面架構圖也提到，我們會(huì )在中間加一個(gè)轉發(fā)節點(diǎn)，就做不到端到端的傳輸鏈路。所以，弱網(wǎng)對抗又是比較頭疼的問(wèn)題。如何在瀏覽器上，和轉發(fā)服務(wù)器上，實(shí)現上行跟下行鏈路的分別優(yōu)化，這里面也有很多難題是需要克服的。
多用戶(hù)場(chǎng)景：就像是典型的小型直播的場(chǎng)景，有很多的接收者，一個(gè)發(fā)送者。如果用純WebRTC的傳輸策略，因為它多個(gè)接收者之間估計出來(lái)的下行帶寬是不一樣的，對發(fā)送端的要求，發(fā)送的碼率調整也不一樣。大家如果有測試經(jīng)驗就會(huì )發(fā)現，WebRTC做多人的場(chǎng)景，如果接收端的人數超過(guò)4個(gè)、5個(gè)的話(huà)，它發(fā)送出來(lái)的碼率就會(huì )非常低，所以看到的畫(huà)面就會(huì )非常的糊。
雖然主流的瀏覽器都開(kāi)始支持WebRTC，但是，其實(shí)所謂的支持WebRTC還是有很多兼容的問(wèn)題。上圖黃色代表的是部分兼容，在這里只有Firefox支持的比較好。目前炒的比較熱的是Safari，在這里可以看到種種的技術(shù)難點(diǎn)，做WebRTC，在Demo產(chǎn)品化的時(shí)候我們就必須要去面對。
智能路由：瀏覽器跟服務(wù)器之間進(jìn)行優(yōu)化傳輸，但是服務(wù)器跟分布式服務(wù)器之間還有一段傳輸。這就要求提供WebRTC服務(wù)的廠(chǎng)商對后臺服務(wù)器之間的傳輸有一個(gè)非常好的智能路由選擇、有一個(gè)傳輸的優(yōu)化，比如說(shuō)跨運營(yíng)商的、跨國的。高可用運維，就不展開(kāi)說(shuō)了，要保證服務(wù)可用，服務(wù)進(jìn)程不可以?huà)斓簟：Ａ康牟l(fā)架構，一般提供WebRTC的廠(chǎng)商，是一種on demand擴容的形式，但是也要求你設計的架構能夠支持海量并發(fā)的擴展。還有全局監控系統，你要對在線(xiàn)上跑的服務(wù)質(zhì)量穩定性的數據可以進(jìn)行監控。還有一個(gè)很重要的問(wèn)題就是調查工具，當你提供WebRTC實(shí)時(shí)通信之后，要有問(wèn)題調查的能力。比如，在通信中發(fā)生了卡頓、延時(shí)，到底是什么原因產(chǎn)生的，哪些因素帶來(lái)了不好的通信體驗，這要有一套很完備的問(wèn)題調查工具。
說(shuō)了這么多，總結兩點(diǎn)，你要從一個(gè)WebRTC開(kāi)發(fā)的Demo到真正成熟的產(chǎn)品服務(wù)的話(huà)，首先，你要有一個(gè)專(zhuān)業(yè)團隊。這個(gè)專(zhuān)業(yè)團隊要覆蓋音視頻的專(zhuān)業(yè)人才、專(zhuān)家，還要有音視頻通信的、視頻傳輸領(lǐng)域的專(zhuān)家，需要很強的行業(yè)經(jīng)驗，高可用運維、實(shí)時(shí)監控、調查工具這些，都需要真正的工程師、專(zhuān)家在日積月累的工作當中積累下來(lái)的經(jīng)驗。
最后向大家介紹一下聲網(wǎng)WebRTC的SDK。也是從幾個(gè)方面來(lái)介紹一下：核心質(zhì)量、集成的簡(jiǎn)易度、功能的靈活擴展、服務(wù)的穩定性跟全局監控的能力。
核心質(zhì)量：聲網(wǎng)有一套大網(wǎng)SD-RTN?，可以保障全球傳輸。Web的SDK用到了分布式網(wǎng)關(guān)的架構，網(wǎng)關(guān)是接在大網(wǎng)的邊緣來(lái)部署，可以提升可用性。
專(zhuān)注互通：正因為聲網(wǎng)有這么一個(gè)分布式網(wǎng)關(guān)的架構，我們就可以接收到不同端上發(fā)來(lái)的適配信息，可以對各個(gè)平臺的策略進(jìn)行靈活的調整。所以，在各個(gè)瀏覽器的監控上，我們也可以做得相對比較好。
靈活配置的傳輸策略：我們把整個(gè)端到端WebRTC的傳輸鏈路改造成端到網(wǎng)關(guān)、網(wǎng)關(guān)到端。在這里面，我們也配置了很多FEC、策略上的一些優(yōu)化。同時(shí)，我們也可以多流發(fā)送。
差異化的編碼器選擇：我們可以選擇不同的編碼器，根據終端的能力進(jìn)行適配，同時(shí)兼顧到端上有沒(méi)有硬件編解碼，和軟件的編解碼。這些點(diǎn)加起來(lái)，保證了我們聲網(wǎng)Web的SDK就可以提升為一個(gè)高質(zhì)量的傳輸服務(wù)。
快速集成：非常方便，只需要四行代碼就可以接入到我們視頻通信的頻道里，很方便，一般4、5分鐘就可以完成一個(gè)音視頻聊天的小程序。同時(shí)，我們也有完備的文檔，非常簡(jiǎn)單易讀的Demo。
功能的靈活擴展：傳統的WebRTC是用來(lái)做通信的場(chǎng)景，我們這個(gè)Web SDK，目前也支持直播的場(chǎng)景，支持旁路推流、服務(wù)器錄制。
全局監控的能力：我們目前提供了Dashboard、服務(wù)質(zhì)量報表，可以看到頻道內的傳輸質(zhì)量、傳輸效果、用戶(hù)接入等各種數據。另外，我們還有全局網(wǎng)絡(luò )的指標，包含丟包、延時(shí)、抖動(dòng)的信息。右邊這個(gè)是問(wèn)題診斷系統的一部分。為什么問(wèn)題診斷系統重要？當用戶(hù)接入實(shí)時(shí)通信，你發(fā)生延時(shí)、抖動(dòng)的時(shí)候，我們就可以知道在什么地方出現了問(wèn)題，綜合這些信息，我們要很清楚的知道線(xiàn)上的某一個(gè)頻道的傳輸渠道出了什么問(wèn)題，在什么地方可以調優(yōu)。
