本文整理自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就可以提升為一個高質量的傳輸服務。
-
快速整合：非常方便，只需要四行程式碼就可以接入到我們視訊通訊的頻道里，很方便，一般4、5分鐘就可以完成一個音視訊聊天的小程式。同時，我們也有完備的文件，非常簡單易讀的Demo。 功能的靈活擴充套件：傳統的WebRTC是用來做通訊的場景，我們這個Web SDK，目前也支援直播的場景，支援旁路推流、伺服器錄製。
- 全域性監控的能力：我們目前提供了Dashboard、服務質量報表，可以看到頻道內的傳輸質量、傳輸效果、使用者接入等各種資料。另外，我們還有全域性網路的指標，包含丟包、延時、抖動的資訊。右邊這個是問題診斷系統的一部分。為什麼問題診斷系統重要？當使用者接入實時通訊，你發生延時、抖動的時候，我們就可以知道在什麼地方出現了問題，綜合這些資訊，我們要很清楚的知道線上的某一個頻道的傳輸渠道出了什麼問題，在什麼地方可以調優。
課程預告：《從0搭建網頁端實時視訊通話》
-
時間：11月29日（週三） 16:00-17:00
-
內容：
- 通訊和直播的必要背景知識
- Agora SDK API呼叫邏輯
- 開發環境
- demo原始碼解讀。demo功能包括：建立頻道、加入頻道、離開頻道、開關攝像頭、靜音、如何測試。
- 如何測試。視訊通話、直播需要進行哪些測試，如何進行簡單的測試。
-
參與方式
本次課程形式為線上直播課。
- 首先，訪問以下連結或點選閱讀原文報名，等待課程開始。
- 在 11月29日 下午3點45分，訪問以下連結進入課程即可
-
報名連結