我們看一下網(wǎng)頁端的實(shí)時通信有什么樣的特點(diǎn)。

　　首先，在瀏覽器端，依賴于瀏覽器獲取音視頻的能力，以及強(qiáng)大的網(wǎng)頁上的渲染能力，所以，就能夠為高清的通信體驗打下基礎(chǔ)。同時，相比移動端來說，屏幕比較大，視窗選擇也比較靈活。

　　第二，跨平臺。大家都了解瀏覽器對各個終端的特殊性，不止PC上有瀏覽器、移動端上有瀏覽器，甚至是一些知名的社交APP也嵌入了瀏覽器。這需要一個跨平臺的體驗，現(xiàn)在支持WebRTC的瀏覽器也越來越多了，這也是網(wǎng)頁實(shí)時通信的一個特點(diǎn)

　　第三，免安裝，方便接入。隨著WebRTC的普及，它不需要安裝任何插件就可以實(shí)現(xiàn)網(wǎng)頁端的實(shí)時通信。

　　再來看一下網(wǎng)頁端實(shí)時通信可以應(yīng)用在什么場景里？

　　首先是直播，直播非常火。直播的主播端會有需求，在網(wǎng)頁端進(jìn)行開播，因為網(wǎng)頁端的屏幕比較大、視頻比較清晰、處理能力比較強(qiáng)。同時，也非常有意思，我們一個客戶也在用我們網(wǎng)頁端的SDK做直播的監(jiān)控。大家也知道，直播開播的房間數(shù)很多，在一個網(wǎng)頁上可以監(jiān)控40-50個房間，來做直播的巡視員，用網(wǎng)頁端的實(shí)時音視頻SDK是比較方便的。

　　另外一個是在線教育，在線教育的老師端一般都在PC上，如果要安裝應(yīng)用程序，有些老師也不是很懂電腦技術(shù)，要去配置的話就比較麻煩。如果有網(wǎng)頁端免安裝的方案的話，他們用起來的話，用戶體驗也會比較好。在線教育除了音視頻，還要求有屏幕共享、白板，因為都是H5的技術(shù)，所以與Web端的SDK集成起來的話也會非常方便。

　　最后就是視頻會議，大家在公司里用過瀏覽器的視頻會議的話都會有體驗，HR發(fā)一個鏈接，某一個時間點(diǎn)你點(diǎn)這個鏈接，除此之外還有一些說明，你要安裝哪些東西，這個會比較復(fù)雜。現(xiàn)在有了免安裝的WebRTC之后，大家對視頻會議的體驗也會上升一個臺階。這邊列的這幾個是比較典型的場景，其實(shí)還有遠(yuǎn)程醫(yī)療、企業(yè)協(xié)作之類的。

　　接下來從技術(shù)上分析一下，網(wǎng)頁端的實(shí)時通信是否已經(jīng)成熟？是否已經(jīng)準(zhǔn)備好了？

　　如果說到網(wǎng)頁端、瀏覽器端的實(shí)時通信的話，大家首先會想到的就是Webex，它的體驗是非常不錯的，也培養(yǎng)了一大群目標(biāo)用戶，讓用戶認(rèn)知到在瀏覽器上就可以進(jìn)行視頻的溝通，打開了一個市場。但是，它有一個缺點(diǎn)，就是必須安裝瀏覽器的插件和擴(kuò)展程序，和GoToMeeting是一樣的，非常不方便。另一種做法是，在PC上安裝一個應(yīng)用程序，通過這個程序來代理獲取、處理音視頻的流，網(wǎng)頁端只是做渲染和展示。

　　在很長一段時間里，這些網(wǎng)頁端的用戶覺得這個技術(shù)就是這樣的，體驗就是這樣的，無法提升了。直到2011年，WebRTC技術(shù)的出現(xiàn)，并且由谷歌做推廣。WebRTC帶來的體驗是因為免安裝才受到了關(guān)注�，F(xiàn)在在差不多6年的發(fā)展時間里，其實(shí)也有很多的質(zhì)疑聲，比如，Google的項目會不會半途而廢，各大瀏覽器廠商會不會不支持這種打通瀏覽器生態(tài)的想法。

　　接下來我想跟大家從不同的維度來分析一下WebRTC這個技術(shù)是否已經(jīng)成熟，是否可以產(chǎn)品化？

　　首先，來看一下目前知識WebRTC瀏覽器跟平臺的情況。

　　最早支持WebRTC的是Firefox和Chrome，之后是Opera，跟隨者chrome支持WebRTC，它們內(nèi)核是一樣的。微軟前兩年提出了一個ORTC的協(xié)議，跟WebRTC有些相似。ORTC發(fā)展并不順利，現(xiàn)在在edge中開始支持WebRTC。近期蘋果更新了IOS系統(tǒng)之后，Safari 11也開始支持WebRTC了。在安卓平臺上，其實(shí)很早就開始支持了WebRTC。

　　我們看一下這幾個瀏覽器在市場上的占有情況，不難看出，現(xiàn)在除了占百分之8點(diǎn)幾的IE之外不支持，其他的其實(shí)都已經(jīng)支持了。

　　我們再從協(xié)議棧的角度來看一下。WebRTC 1.0 Spec已經(jīng)基本定稿了，除了一些比較細(xì)節(jié)的問題還沒有最終確認(rèn)。各個瀏覽器對標(biāo)準(zhǔn)的支持也越來越好。雖然谷歌自己也在推廣這個技術(shù)，但是谷歌自己的瀏覽器Chrome對WebRTC 1.0的支持并不是很好，這是因為谷歌在內(nèi)部對WebRTC做了很多實(shí)驗性的東西。Chrome團(tuán)隊對外聲稱，會在今年底，完全跟上WebRTC 1.0的標(biāo)準(zhǔn)。

　　另外一個方面，看一下開源社區(qū)。舉幾個比較典型的開源項目，一個是Kurento，它是功能比較強(qiáng)大的一個多媒體處理框架，支持WebRTC協(xié)議棧。它可以作為Media server，后臺有轉(zhuǎn)碼的能力，并且有OpenCV處理能力。Licode可以作為WebRTC的輕量通信平臺，是純轉(zhuǎn)發(fā)的服務(wù)器處理模式。Janus可以作為WebRTC通信網(wǎng)關(guān)，比較輕量。值得關(guān)注的是React-Native-WebRTC�，F(xiàn)在越來越多的開發(fā)者開始轉(zhuǎn)向前端，JS。這種情況在國外更為普遍。在開源社區(qū)上出現(xiàn)了這么一個項目，封裝了一個WebRTC的模塊，開發(fā)者就可以很方便的在手機(jī)上來實(shí)現(xiàn)帶有實(shí)時通信能力、兼容WebRTC的應(yīng)用。

　　最后，看一下生態(tài)圈。在CPaas這一層，有聲網(wǎng)、Twilio、Tokbox這樣的公司在做貢獻(xiàn)。

　　市場分析對WebRTC非�？春茫�預(yù)計到2022年市場規(guī)模將達(dá)到64.9億美金。總的來說，WebRTC技術(shù)現(xiàn)在處在一個最好的時代。

　　對于開發(fā)者來說，如何用這個技術(shù)、如何能夠構(gòu)建起一個WebRTC的系統(tǒng)？其實(shí)是有一段必經(jīng)之路。

　　我們知道WebRTC的底層是基于P2P連接，是點(diǎn)對點(diǎn)的通信。很多開發(fā)者上手的時候，都會去做P2P質(zhì)量的檢驗。比如說一個公司的產(chǎn)品經(jīng)理告訴開發(fā)人員說“現(xiàn)在WebRTC很火，你給我整一個WebRTC的系統(tǒng)。”八成的開發(fā)人員會交付這樣一個網(wǎng)狀結(jié)構(gòu)WebRTC的架構(gòu)。

　　那么，完全基于點(diǎn)對點(diǎn)之間通信的架構(gòu)有什么特點(diǎn)？延時會比較小。但是，有一個很大的缺點(diǎn)。這種點(diǎn)對點(diǎn)音視頻流的傳遞，每一個用戶都要給另外一個用戶傳自己的視頻流，這樣對它上行帶寬的壓力很大。并且，每一路視頻流都是獨(dú)立進(jìn)行采集編碼，這對瀏覽器端編碼壓力的考驗也很大。有人會問，能不能只采集一次編碼，然后就把這個流發(fā)給不同的終端接收者？很遺憾，這是不行的。因為WebRTC的協(xié)議是做端到端的質(zhì)量策略優(yōu)化，所以它有一些策略調(diào)整，都是端對端的RTCP來實(shí)現(xiàn)，必須要經(jīng)過多次的編碼，然后分別傳輸給不同的接收者。

　　右下角的表格列的是一個權(quán)威的行業(yè)機(jī)構(gòu)統(tǒng)計的目前在互聯(lián)網(wǎng)上使用WebRTC的系統(tǒng)架構(gòu)，純P2P的只占19%。

　　如果按剛才介紹的這個架構(gòu)，開發(fā)人員交付給產(chǎn)品的話，肯定會打回來的，因為大家都知道，上行帶寬非常寶貴，也非常受限。為了解決這個問題，開發(fā)人員會做一些深度的研究，發(fā)現(xiàn)領(lǐng)域內(nèi)的WebRTC架構(gòu)其實(shí)中間加了一個點(diǎn)，這個點(diǎn)就是服務(wù)器，典型的媒體服務(wù)器只做多路流的轉(zhuǎn)發(fā)，不做后臺的媒體處理和轉(zhuǎn)碼。

　　上文提到的Janus和Licode開源項目都可以實(shí)現(xiàn)轉(zhuǎn)發(fā)媒體服務(wù)器的功能。它的特點(diǎn)是，每個終端用戶只要上傳一路流到中間服務(wù)器，節(jié)省了帶寬。同時SFU只是做轉(zhuǎn)發(fā)，所以對延時的影響相對比較小。弊端是，如果有兩路接收者，下行帶寬的能力不一樣，一個是500K，一個是2m，由于源端發(fā)送者只送一路流，所以就很難適配多路的終端。

　　改成純轉(zhuǎn)發(fā)的媒體服務(wù)器之后，它還有一些弊端，開發(fā)人員又會想辦法說，我在中間這個節(jié)點(diǎn)加上混流的功能。大家也可以從這個架構(gòu)當(dāng)中看出來，在服務(wù)器端收到不同的兩路視頻流之后，會分別做解碼、拼接合成、編碼。根據(jù)不同接收者的帶寬情況，分別給不同的接收者發(fā)送不同profile的視頻流。這就解決了，如果是多個接收端的用戶，無法做到帶寬的適配。這個缺點(diǎn)也很明顯，中間做轉(zhuǎn)碼必然帶來延時，其次是轉(zhuǎn)碼服務(wù)器的成本很高，但是，確實(shí)節(jié)省了下行的帶寬，

　　介紹了幾種典型的WebRTC的系統(tǒng)架構(gòu)之后，開發(fā)人員可以基于剛才說的幾個開源項目，可以很方便的搭建出，或者是不用費(fèi)太多的時間就可以搭建出這么一個Demo的系統(tǒng)，是不是故事就到此結(jié)束了？其實(shí)還差很遠(yuǎn)，這邊還有很多隱藏的坑。

　　下面再跟大家分享一下，經(jīng)歷過、探索過的一些背后的技術(shù)的難點(diǎn)。

　　上圖是從一個Demo做成一個比較穩(wěn)定的產(chǎn)品，會遇到的坑。

　　首先是可用性。WebRTC是基于P2P的，P2P的可用性、連接成功率也是大家一直在詬病的，不止是打洞、穿越這些技術(shù)。

　　平臺互通：WebRTC出來的時間還是有限的，很多領(lǐng)域內(nèi)的公司都有自己自研的通信協(xié)議，這些協(xié)議一般是用在Native端，手機(jī)端、PC端、mac、windows，這也帶來了一些問題，自研的協(xié)議跟WebRTC協(xié)議之間如何可以做到平臺互通？這也有很多的坑在這里面。剛才說它是一個端到端優(yōu)化的傳輸策略，你拆開這個端到端，你的上行是WebRTC，你的發(fā)送者是WebRTC，接收者是自研的端，這里面有很多策略匹配的工作需要去做。

　　編碼器選擇：音視頻的編碼在實(shí)時通信中非常重要。WebRTC的視頻，支持VP8/9,H.264。可能有人會選擇H.264，認(rèn)為它在移動端適應(yīng)性強(qiáng)。但是H.264在Chrome上不太成熟，所以很多商用產(chǎn)品依然在用VP8，但是涉及到移動端的互通，又得考慮編碼器的選擇。

　　弱網(wǎng)對抗：WebRTC有一套自己的傳輸策略，比如說丟包重傳、FEC、帶寬檢測、動態(tài)碼率調(diào)整。但是，在弱網(wǎng)對抗方面，前面架構(gòu)圖也提到，我們會在中間加一個轉(zhuǎn)發(fā)節(jié)點(diǎn)，就做不到端到端的傳輸鏈路。所以，弱網(wǎng)對抗又是比較頭疼的問題。如何在瀏覽器上，和轉(zhuǎn)發(fā)服務(wù)器上，實(shí)現(xiàn)上行跟下行鏈路的分別優(yōu)化，這里面也有很多難題是需要克服的。

　　多用戶場景：就像是典型的小型直播的場景，有很多的接收者，一個發(fā)送者。如果用純WebRTC的傳輸策略，因為它多個接收者之間估計出來的下行帶寬是不一樣的，對發(fā)送端的要求，發(fā)送的碼率調(diào)整也不一樣。大家如果有測試經(jīng)驗就會發(fā)現(xiàn)，WebRTC做多人的場景，如果接收端的人數(shù)超過4個、5個的話，它發(fā)送出來的碼率就會非常低，所以看到的畫面就會非常的糊。

　　雖然主流的瀏覽器都開始支持WebRTC，但是，其實(shí)所謂的支持WebRTC還是有很多兼容的問題。上圖黃色代表的是部分兼容，在這里只有Firefox支持的比較好。目前炒的比較熱的是Safari，在這里可以看到種種的技術(shù)難點(diǎn)，做WebRTC，在Demo產(chǎn)品化的時候我們就必須要去面對。

　　智能路由：瀏覽器跟服務(wù)器之間進(jìn)行優(yōu)化傳輸，但是服務(wù)器跟分布式服務(wù)器之間還有一段傳輸。這就要求提供WebRTC服務(wù)的廠商對后臺服務(wù)器之間的傳輸有一個非常好的智能路由選擇、有一個傳輸?shù)膬?yōu)化，比如說跨運(yùn)營商的、跨國的。高可用運(yùn)維，就不展開說了，要保證服務(wù)可用，服務(wù)進(jìn)程不可以掛掉。海量的并發(fā)架構(gòu)，一般提供WebRTC的廠商，是一種on demand擴(kuò)容的形式，但是也要求你設(shè)計的架構(gòu)能夠支持海量并發(fā)的擴(kuò)展。還有全局監(jiān)控系統(tǒng)，你要對在線上跑的服務(wù)質(zhì)量穩(wěn)定性的數(shù)據(jù)可以進(jìn)行監(jiān)控。還有一個很重要的問題就是調(diào)查工具，當(dāng)你提供WebRTC實(shí)時通信之后，要有問題調(diào)查的能力。比如，在通信中發(fā)生了卡頓、延時，到底是什么原因產(chǎn)生的，哪些因素帶來了不好的通信體驗，這要有一套很完備的問題調(diào)查工具。

　　說了這么多，總結(jié)兩點(diǎn)，你要從一個WebRTC開發(fā)的Demo到真正成熟的產(chǎn)品服務(wù)的話，首先，你要有一個專業(yè)團(tuán)隊。這個專業(yè)團(tuán)隊要覆蓋音視頻的專業(yè)人才、專家，還要有音視頻通信的、視頻傳輸領(lǐng)域的專家，需要很強(qiáng)的行業(yè)經(jīng)驗，高可用運(yùn)維、實(shí)時監(jiān)控、調(diào)查工具這些，都需要真正的工程師、專家在日積月累的工作當(dāng)中積累下來的經(jīng)驗。

　　最后向大家介紹一下聲網(wǎng)WebRTC的SDK。也是從幾個方面來介紹一下：核心質(zhì)量、集成的簡易度、功能的靈活擴(kuò)展、服務(wù)的穩(wěn)定性跟全局監(jiān)控的能力。

　　核心質(zhì)量：聲網(wǎng)有一套大網(wǎng)SD-RTN?，可以保障全球傳輸。Web的SDK用到了分布式網(wǎng)關(guān)的架構(gòu)，網(wǎng)關(guān)是接在大網(wǎng)的邊緣來部署，可以提升可用性。

　　專注互通：正因為聲網(wǎng)有這么一個分布式網(wǎng)關(guān)的架構(gòu)，我們就可以接收到不同端上發(fā)來的適配信息，可以對各個平臺的策略進(jìn)行靈活的調(diào)整。所以，在各個瀏覽器的監(jiān)控上，我們也可以做得相對比較好。

　　靈活配置的傳輸策略：我們把整個端到端WebRTC的傳輸鏈路改造成端到網(wǎng)關(guān)、網(wǎng)關(guān)到端。在這里面，我們也配置了很多FEC、策略上的一些優(yōu)化。同時，我們也可以多流發(fā)送。

　　差異化的編碼器選擇：我們可以選擇不同的編碼器，根據(jù)終端的能力進(jìn)行適配，同時兼顧到端上有沒有硬件編解碼，和軟件的編解碼。這些點(diǎn)加起來，保證了我們聲網(wǎng)Web的SDK就可以提升為一個高質(zhì)量的傳輸服務(wù)。

　　快速集成：非常方便，只需要四行代碼就可以接入到我們視頻通信的頻道里，很方便，一般4、5分鐘就可以完成一個音視頻聊天的小程序。同時，我們也有完備的文檔，非常簡單易讀的Demo。

　　功能的靈活擴(kuò)展：傳統(tǒng)的WebRTC是用來做通信的場景，我們這個Web SDK，目前也支持直播的場景，支持旁路推流、服務(wù)器錄制。

　　全局監(jiān)控的能力：我們目前提供了Dashboard、服務(wù)質(zhì)量報表，可以看到頻道內(nèi)的傳輸質(zhì)量、傳輸效果、用戶接入等各種數(shù)據(jù)。另外，我們還有全局網(wǎng)絡(luò)的指標(biāo)，包含丟包、延時、抖動的信息。右邊這個是問題診斷系統(tǒng)的一部分。為什么問題診斷系統(tǒng)重要？當(dāng)用戶接入實(shí)時通信，你發(fā)生延時、抖動的時候，我們就可以知道在什么地方出現(xiàn)了問題，綜合這些信息，我們要很清楚的知道線上的某一個頻道的傳輸渠道出了什么問題，在什么地方可以調(diào)優(yōu)。