網頁端實時音視頻服務架構與實踐

本文整理自RTC大會，陳功的演講《網頁端實時音視頻服務架構與實踐》。 歡迎訪問 RTC 開發者社區，與更多開發者交流經驗，參與更多技術活動。

陳功
負責網頁端音視頻通訊技術架構。畢業於中國科學技術大學，Ph.D。原英特爾服務器事業部多媒體架構師，主導基於WebRTC的視頻會議解決方案搭建。曾任職Marvell視頻事業部，研究多媒體系統框架，參與Google TV, OTT等項目
複製代碼

網頁端的實時通訊有什麼特色

首先，在瀏覽器端，依賴於瀏覽器獲取音視頻的能力，以及強大的網頁上的渲染能力，因此，就可以爲高清的通訊體驗打下基礎。同時，相比移動端來講，屏幕比較大，視窗選擇也比較靈活。

第二，跨平臺。你們都瞭解瀏覽器對各個終端的特殊性，不止PC上有瀏覽器、移動端上有瀏覽器，甚至是一些知名的社交APP也嵌入了瀏覽器。這須要一個跨平臺的體驗，如今支持WebRTC的瀏覽器也愈來愈多了，這也是網頁實時通訊的一個特色

第三，免安裝，方便接入。隨着WebRTC的普及，它不須要安裝任何插件就能夠實現網頁端的實時通訊。

網頁端實時通訊能夠應用在什麼場景

首先是直播，直播很是火。直播的主播端會有需求，在網頁端進行開播，由於網頁端的屏幕比較大、視頻比較清晰、處理能力比較強。同時，也很是有意思，咱們一個客戶也在用咱們網頁端的SDK作直播的監控。你們也知道，直播開播的房間數不少，在一個網頁上能夠監控40-50個房間，來作直播的巡視員，用網頁端的實時音視頻SDK是比較方便的。

另一個是在線教育，在線教育的老師端通常都在PC上，若是要安裝應用程序，有些老師也不是很懂電腦技術，要去配置的話就比較麻煩。若是有網頁端免安裝的方案的話，他們用起來的話，用戶體驗也會比較好。在線教育除了音視頻，還要求有屏幕共享、白板，由於都是H5的技術，因此與Web端的SDK集成起來的話也會很是方便。

最後就是視頻會議，你們在公司裏用過瀏覽器的視頻會議的話都會有體驗，HR發一個連接，某一個時間點你點這個連接，除此以外還有一些說明，你要安裝哪些東西，這個會比較複雜。如今有了免安裝的WebRTC以後，你們對視頻會議的體驗也會上升一個臺階。這邊列的這幾個是比較典型的場景，其實還有遠程醫療、企業協做之類的。

從技術上看，網頁端的實時通訊是否已經成熟？是否已經準備好了？

若是說到網頁端、瀏覽器端的實時通訊的話，你們首先會想到的就是Webex，它的體驗是很是不錯的，也培養了一大羣目標用戶，讓用戶認知到在瀏覽器上就能夠進行視頻的溝通，打開了一個市場。可是，它有一個缺點，就是必須安裝瀏覽器的插件和擴展程序，和GoToMeeting是同樣的，很是不方便。另外一種作法是，在PC上安裝一個應用程序，經過這個程序來代理獲取、處理音視頻的流，網頁端只是作渲染和展現。

在很長一段時間裏，這些網頁端的用戶以爲這個技術就是這樣的，體驗就是這樣的，沒法提高了。直到2011年，WebRTC技術的出現，而且由谷歌作推廣。WebRTC帶來的體驗是由於免安裝才受到了關注。如今在差很少6年的發展時間裏，其實也有不少的質疑聲，好比，Google的項目會不會半途而廢，各大瀏覽器廠商會不會不支持這種打通瀏覽器生態的想法。

##WebRTC是否已經成熟，是否能夠產品化？

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

最先支持WebRTC的是Firefox和Chrome，以後是Opera，跟隨者chrome支持WebRTC，它們內核是同樣的。微軟前兩年提出了一個ORTC的協議，跟WebRTC有些類似。ORTC發展並不順利，如今在edge中開始支持WebRTC。近期蘋果更新了IOS系統以後，Safari 11也開始支持WebRTC了。在安卓平臺上，其實很早就開始支持了WebRTC。

咱們看一下這幾個瀏覽器在市場上的佔有狀況，不難看出，如今除了佔百分之8點幾的IE以外不支持，其餘的其實都已經支持了。

咱們再從協議棧的角度來看一下。WebRTC 1.0 Spec已經基本定稿了，除了一些比較細節的問題尚未最終確認。各個瀏覽器對標準的支持也愈來愈好。雖然谷歌本身也在推廣這個技術，可是谷歌本身的瀏覽器Chrome對WebRTC 1.0的支持並非很好，這是由於谷歌在內部對WebRTC作了不少實驗性的東西。Chrome團隊對外聲稱，會在今年末，徹底跟上WebRTC 1.0的標準。

另一個方面，看一下開源社區。舉幾個比較典型的開源項目，一個是Kurento，它是功能比較強大的一個多媒體處理框架，支持WebRTC協議棧。它能夠做爲Media server，後臺有轉碼的能力，而且有OpenCV處理能力。Licode能夠做爲WebRTC的輕量通訊平臺，是純轉發的服務器處理模式。Janus能夠做爲WebRTC通訊網關，比較輕量。值得關注的是React-Native-WebRTC。如今愈來愈多的開發者開始轉向前端，JS。這種狀況在國外更爲廣泛。在開源社區上出現了這麼一個項目，封裝了一個WebRTC的模塊，開發者就能夠很方便的在手機上來實現帶有實時通訊能力、兼容WebRTC的應用。

最後，看一下生態圈。在CPaas這一層，有聲網、Twilio、Tokbox這樣的公司在作貢獻。

市場分析對WebRTC很是看好，預計到2022年市場規模將達到64.9億美金。總的來講，WebRTC技術如今處在一個最好的時代。

對於開發者來講，如何用這個技術、如何可以構建起一個WebRTC的系統？實際上是有一段必經之路。

咱們知道WebRTC的底層是基於P2P鏈接，是點對點的通訊。不少開發者上手的時候，都會去作P2P質量的檢驗。好比說一個公司的產品經理告訴開發人員說「如今WebRTC很火，你給我整一個WebRTC的系統。」八成的開發人員會交付這樣一個網狀結構WebRTC的架構。

那麼，徹底基於點對點之間通訊的架構有什麼特色？延時會比較小。可是，有一個很大的缺點。這種點對點音視頻流的傳遞，每個用戶都要給另一個用戶傳本身的視頻流，這樣對它上行帶寬的壓力很大。而且，每一路視頻流都是獨立進行採集編碼，這對瀏覽器端編碼壓力的考驗也很大。有人會問，能不能只採集一次編碼，而後就把這個流發給不一樣的終端接收者？很遺憾，這是不行的。由於WebRTC的協議是作端到端的質量策略優化，因此它有一些策略調整，都是端對端的RTCP來實現，必需要通過屢次的編碼，而後分別傳輸給不一樣的接收者。

右下角的表格列的是一個權威的行業機構統計的目前在互聯網上使用WebRTC的系統架構，純P2P的只佔19%。

若是按剛纔介紹的這個架構，開發人員交付給產品的話，確定會打回來的，由於你們都知道，上行帶寬很是寶貴，也很是受限。爲了解決這個問題，開發人員會作一些深度的研究，發現領域內的WebRTC架構其實中間加了一個點，這個點就是服務器，典型的媒體服務器只作多路流的轉發，不作後臺的媒體處理和轉碼。

上文提到的Janus和Licode開源項目均可以實現轉發媒體服務器的功能。它的特色是，每一個終端用戶只要上傳一路流到中間服務器，節省了帶寬。同時SFU只是作轉發，因此對延時的影響相對比較小。弊端是，若是有兩路接收者，下行帶寬的能力不同，一個是500K，一個是2m，因爲源端發送者只送一路流，因此就很難適配多路的終端。

改爲純轉發的媒體服務器以後，它還有一些弊端，開發人員又會想辦法說，我在中間這個節點加上混流的功能。你們也能夠從這個架構當中看出來，在服務器端收到不一樣的兩路視頻流以後，會分別作解碼、拼接合成、編碼。根據不一樣接收者的帶寬狀況，分別給不一樣的接收者發送不一樣profile的視頻流。這就解決了，若是是多個接收端的用戶，沒法作到帶寬的適配。這個缺點也很明顯，中間作轉碼必然帶來延時，其次是轉碼服務器的成本很高，可是，確實節省了下行的帶寬，

介紹了幾種典型的WebRTC的系統架構以後，開發人員能夠基於剛纔說的幾個開源項目，能夠很方便的搭建出，或者是不用費太多的時間就能夠搭建出這麼一個Demo的系統，是否是故事就到此結束了？其實還差很遠，這邊還有不少隱藏的坑。

背後的技術的難點

上圖是從一個Demo作成一個比較穩定的產品，會遇到的坑。

首先是可用性。WebRTC是基於P2P的，P2P的可用性、鏈接成功率也是你們一直在詬病的，不止是打洞、穿越這些技術。

平臺互通：WebRTC出來的時間仍是有限的，不少領域內的公司都有本身自研的通訊協議，這些協議通常是用在Native端，手機端、PC端、mac、windows，這也帶來了一些問題，自研的協議跟WebRTC協議之間如何能夠作到平臺互通？這也有不少的坑在這裏面。剛纔說它是一個端到端優化的傳輸策略，你拆開這個端到端，你的上行是WebRTC，你的發送者是WebRTC，接收者是自研的端，這裏面有不少策略匹配的工做須要去作。

編碼器選擇：音視頻的編碼在實時通訊中很是重要。WebRTC的視頻，支持VP8/9,H.264。可能有人會選擇H.264，認爲它在移動端適應性強。可是H.264在Chrome上不太成熟，因此不少商用產品依然在用VP8，可是涉及到移動端的互通，又得考慮編碼器的選擇。

弱網對抗：WebRTC有一套本身的傳輸策略，好比說丟包重傳、FEC、帶寬檢測、動態碼率調整。可是，在弱網對抗方面，前面架構圖也提到，咱們會在中間加一個轉發節點，就作不到端到端的傳輸鏈路。因此，弱網對抗又是比較頭疼的問題。如何在瀏覽器上，和轉發服務器上，實現上行跟下行鏈路的分別優化，這裏面也有不少難題是須要克服的。

多用戶場景：就像是典型的小型直播的場景，有不少的接收者，一個發送者。若是用純WebRTC的傳輸策略，由於它多個接收者之間估計出來的下行帶寬是不同的，對發送端的要求，發送的碼率調整也不同。你們若是有測試經驗就會發現，WebRTC作多人的場景，若是接收端的人數超過4個、5個的話，它發送出來的碼率就會很是低，因此看到的畫面就會很是的糊。

雖然主流的瀏覽器都開始支持WebRTC，可是，其實所謂的支持WebRTC仍是有不少兼容的問題。上圖黃色表明的是部分兼容，在這裏只有Firefox支持的比較好。目前炒的比較熱的是Safari，在這裏能夠看到種種的技術難點，作WebRTC，在Demo產品化的時候咱們就必需要去面對。

智能路由：瀏覽器跟服務器之間進行優化傳輸，可是服務器跟分佈式服務器之間還有一段傳輸。這就要求提供WebRTC服務的廠商對後臺服務器之間的傳輸有一個很是好的智能路由選擇、有一個傳輸的優化，好比說跨運營商的、跨國的。高可用運維，就不展開說了，要保證服務可用，服務進程不能夠掛掉。海量的併發架構，通常提供WebRTC的廠商，是一種on demand擴容的形式，可是也要求你設計的架構可以支持海量併發的擴展。還有全局監控系統，你要對在線上跑的服務質量穩定性的數據能夠進行監控。還有一個很重要的問題就是調查工具，當你提供WebRTC實時通訊以後，要有問題調查的能力。好比，在通訊中發生了卡頓、延時，究竟是什麼緣由產生的，哪些因素帶來了很差的通訊體驗，這要有一套很完備的問題調查工具。

說了這麼多，總結兩點，要從一個WebRTC開發的Demo到真正成熟的產品服務的話，首先要有一個專業團隊。這個專業團隊要覆蓋音視頻的專業人才、專家，還要有音視頻通訊的、視頻傳輸領域的專家，須要很強的行業經驗，高可用運維、實時監控、調查工具這些，都須要真正的工程師、專家在日積月累的工做當中積累下來的經驗。

最後介紹一下聲網WebRTC的SDK。也是從幾個方面來介紹一下：核心質量、集成的簡易度、功能的靈活擴展、服務的穩定性跟全局監控的能力。

• 核心質量：聲網有一套大網SD-RTN™，能夠保障全球傳輸。Web的SDK用到了分佈式網關的架構，網關是接在大網的邊緣來部署，能夠提高可用性。

• 專一互通：正由於聲網有這麼一個分佈式網關的架構，咱們就能夠接收到不一樣端上發來的適配信息，能夠對各個平臺的策略進行靈活的調整。因此，在各個瀏覽器的監控上，咱們也能夠作得相對比較好。

• 靈活配置的傳輸策略：咱們把整個端到端WebRTC的傳輸鏈路改形成端到網關、網關到端。在這裏面，咱們也配置了不少FEC、策略上的一些優化。同時，咱們也能夠多流發送。 差別化的編碼器選擇：咱們能夠選擇不一樣的編碼器，根據終端的能力進行適配，同時兼顧到端上有沒有硬件編解碼，和軟件的編解碼。這些點加起來，保證了咱們聲網Web的SDK就能夠提高爲一個高質量的傳輸服務。

• 快速集成：很是方便，只須要四行代碼就能夠接入到咱們視頻通訊的頻道里，很方便，通常四、5分鐘就能夠完成一個音視頻聊天的小程序。同時，咱們也有完備的文檔，很是簡單易讀的Demo。 功能的靈活擴展：傳統的WebRTC是用來作通訊的場景，咱們這個Web SDK，目前也支持直播的場景，支持旁路推流、服務器錄製。

• 全局監控的能力：咱們目前提供了Dashboard、服務質量報表，能夠看到頻道內的傳輸質量、傳輸效果、用戶接入等各類數據。另外，咱們還有全局網絡的指標，包含丟包、延時、抖動的信息。右邊這個是問題診斷系統的一部分。爲何問題診斷系統重要？當用戶接入實時通訊，你發生延時、抖動的時候，咱們就能夠知道在什麼地方出現了問題，綜合這些信息，咱們要很清楚的知道線上的某一個頻道的傳輸渠道出了什麼問題，在什麼地方能夠調優。

課程預告：《從0搭建網頁端實時視頻通話》

• 時間：11月29日（週三） 16:00-17:00

• 內容：

  • 通訊和直播的必要背景知識
  • Agora SDK API調用邏輯
  • 開發環境
  • demo源代碼解讀。demo功能包括：建立頻道、加入頻道、離開頻道、開關攝像頭、靜音、如何測試。
  • 如何測試。視頻通話、直播須要進行哪些測試，如何進行簡單的測試。

• 參與方式

  本次課程形式爲線上直播課。

  • 首先，訪問如下連接或點擊閱讀原文報名，等待課程開始。
  • 在 11月29日 下午3點45分，訪問如下連接進入課程便可

• 報名連接

www.itdks.com/liveevent/d…