2017年，蘋果宣布將在iOS 11中支持WebRTC，至此完成了主流PC瀏覽器、移動端的全覆蓋，而其提供了一整套完備的音視頻通信方案，這給開發者帶來了巨大利好。英特爾協同通信解決方案架構師段先德針對WebRTC的能力、優勢與不足、開發要點及未來發展幾方面進行分析。本文是『WebRTC-互聯網音視頻新標準？』系列的第一篇，如果您對WebRTC技術的未來有分析和洞見，歡迎聯系 contribute@livevideostack.com。

文 / 段先德

策劃 / LiveVideoStack

2017年，隨著微軟和蘋果表態在其瀏覽器或系統產品中對WebRTC技術的支持，以及WebRTC 1.0標準的定案，WebRTC的話題越來越多地出現在廣大互聯網行業開發人員的視野中。很多同學對WebRTC的背景、目的、意義以及限制其實并不明白，加上媒體上各種吹捧和質疑的聲音互相摻雜，對WebRTC這項技術的應用前景和開發難度沒有切實的判斷。本文希望通過對WebRTC技術的粗淺梳理，為大家提供參考。

WebRTC是什么？能做什么？

很多人期望WebRTC是一個“拿來即用”的“端到端解決方案”，只需要在web端寫幾行JavaScript調用甚至不需要編程就能實現瀏覽器之間的實時音視頻通信。也有很多人把WebRTC等同于Google在其Chromium工程中的開源實現。其實這都是誤解。WebRTC并不是一個“解決方案”，也不囿于某一種實現的代碼庫。WebRTC是終端的音視頻媒體訪問（輸入輸出）接口在類似web環境下的標準化抽象，以及用于實時通信的會話的建立過程、終端音視頻媒體（或其他數據）編碼格式、傳輸方式和參數的描述和協商規范。既然是一種標準規范，那么無論具體實現方式如何，只要該實現符合該標準規范就應該可以互聯互通、擁有實時通信的能力，這也是WebRTC最本質的意義。

WebRTC雖然冠以“web”之名，但并不受限于傳統互聯網應用或瀏覽器的終端運行環境。實際上無論終端運行環境是瀏覽器、桌面應用、移動設備（Android或iOS）還是IoT設備，只要IP連接可到達且符合WebRTC規范就可以互通。這一點釋放了大量智能終端（或運行在智能終端上的app）的實時通信能力，打開了許多對于實時交互性要求較高的應用場景的想象空間，譬如在線教育、視頻會議、視頻社交、遠程協助、遠程操控等等都是其合適的應用領域。

WebRTC有什么優勢和不足？

很長時間以來，實時通信能力一直是電信類專用設備（如電話、手機）的專有屬性。隨著各種互聯網應用和移動互聯網應用的層出不窮，特別是隨著用戶接入帶寬條件的不斷改善，許多新的應用都對實時通信服務有著切實的需求，希望能夠把實時通信能力集成到應用程序中。其實很多終端設備都具有實時通信的潛力的，但是在WebRTC之前，沒有一個統一的工業標準來描述一個設備的實時通信能力和連接建立過程。在對實時通信能力的需求特別迫切的應用（如微信、WhasApp、FaceTime、Messenger等等）中，大家各做一套，“七國八制”，完全不能互通。

WebRTC最大的優勢就是“標準化”，它解決的問題就是給所有需要進行實時通信的終端提供一套統一的、開放的實時通信能力描述和連接建立標準。只要符合WebRTC的規范，通信終端的形態和運行環境就是透明的（看不見也不關心），大家都可以用同一種“語言”進行“交談”。WebRTC對音視頻的編碼格式（codec）、傳輸方式和協商過程做出了明確的規定，原則上所有支持WebRTC的終端，在互操作性上將不存在障礙。目前各大瀏覽器廠商都積極參與到WebRTC技術的生態中，從web應用開始，WebRTC將成為基于網頁的音視頻實時通信技術規范將。之后，在web應用于移動終端應用的交互需求驅動下，越來越多的移動應用的音視頻服務也將采用WebRTC的技術規范。

要說不足之處，一個就是目前WebRTC標準剛剛塵埃落定，在2018年以及今后的一段時間內，還存在各家瀏覽器廠商的現有WebRTC實現與規范不完全相符的情況，會多少存在某些應用場景下互聯互通的問題，亟待各家瀏覽器廠商將持續完善現有實現以向標準看齊。另一個很大的不足（遺憾）可能是Android和iOS系統原生支持WebRTC標準的愿景目前還不明確，需要通過在app中集成客戶端SDK來實現。不過向來技術標準的發展和與工業界的應用普及是相互激勵的，我們也可以說這是WebRTC標準發展的一個巨大空間。

怎么做基于WebRTC的應用開發？

首先當然要讓終端具備WebRTC能力。如果終端運行環境是瀏覽器，目前絕大部分瀏覽器都已經實現了對WebRTC的支持（其中Safari和Edge的支持還在持續完善中），雖然彼此有一些差異，但是可以借助adapter.js等適配層屏蔽掉這些差異。如果終端運行環境不是瀏覽器，則可以采用其他的開源SDK或商業SDK，將其集成在終端應用程序中。當然也可以基于Google的開源WebRTC實現的Native代碼進行裁剪或移植。值得一提的是Google的開源WebRTC代碼庫中有大量的終端多媒體問題和傳輸問題的應對方案的實現，包括音視頻的編解碼、同步、帶寬預測、QoS，AEC等，都是做終端（特別是IoT設備或桌面環境應用）開發時很好的參考。

終端實現了WebRTC只是表示它具備了實時通信的能力，但各個終端任然是孤立的，需要將各個終端的SDP進行交換才能讓它們完成媒體和傳輸的協商才能讓各個終端之間真正通起來。WebRTC并未就各個實現之間交換SDP的傳輸方式以及終端的“尋址”方式做出規定，這跟具體應用場景和其實現方式高度相關。因此要實現基于WebRTC的應用還需要一些“額外”的工作，通過一個各個終端都“認識”并能“找到”的“中間人”來進行SDP交換。譬如最簡單的“1對1”呼叫的場景，這個“中間人”就是信令服務器，這種WebRTC的信令服務器可以基于任何消息系統構建，有很多開源實現可以利用或參考，自研開發也并不復雜。

如果要基于WebRTC做“1對多”或者“多對多”的實時通信應用，則情況要復雜一些，具體的做法也會因實際應用場景而不同，根據通信終端之間的媒體流拓撲結構，大體上可以分為Peer2Peer（終端點對點連接）模式、SFU（Selective Forwarding Unit，服務器選擇性轉發）模式和MCU（MultipointControl Unit，服務器混音混流）模式。

Peer2Peer模式（所有參與方均需與其他所有參與方通信的情景又叫Mesh模式）的特征是呼叫中每兩個需要進行通信的參與者之間都建立起點對點的媒體連接（PeerConnection），所有的媒體連接都是終端之間的（有可能通過TURN服務器進行NAT穿越，但不影響本質流拓撲），服務器側不參與。Peer2Peer模式的優點是媒體拓撲去中心化，服務器側實現簡單，只需要將各個終端之間的信令交換送達即可；缺點是終端需要受理多路媒體流的收發，隨著呼叫中參與方數的增加，媒體連接數會階乘函數式增長，無論對終端的編解碼計算力還是帶寬資源都會帶來巨大的壓力。如果一個呼叫中參數方數很少（譬如大多數時間2方偶爾3方），則可以考慮選用Peer2Peer模式的服務器側實現方案。

SFU模式的特征是呼叫中所有的參與者都與服務器側的媒體服務器建立媒體連接，把媒體流發送到媒體服務器，媒體服務器把媒體流（根據需要）選擇性轉發給需要接收該媒體流的所有參與者。SFU模式的優點是終端編碼運算和上行網絡帶寬消耗大大減少，并且媒體服務器可以根據要求將媒體流（需支持SVC）的不同分層選擇性地發送給接收者，適當減少接收者側下行網絡帶寬的消耗并提供一定的“可定制性”用戶體驗。缺點（或“代價”）是媒體服務器需要受理所有媒體連接請求，接收所有參與者發布的流并轉發給所有訂閱者，產生服務器側運營壓力。

MCU模式的特征是呼叫中所有的參與者都與服務器側的媒體服務器建立媒體連接并把媒體流發送到媒體服務器，媒體服務器把所有收到的媒體流進行混流混音后發送給所有需要接收的參與者。MCU模式相對SFU模式的優點是終端解碼運算和下行網絡帶寬消耗進一步減少，并且天然具有轉碼能力，可以放寬終端采用音視頻編解碼格式的限制，使終端可以選擇對自身最友好的編解碼格式，大大提高終端生存能力。并且由于將所有終端的媒體混合在一起，可以實現服務器側所見即所得的錄制和向外部流媒體服務器推流。MCU的缺點（或“代價”）是媒體服務器需要實時將所有接收的媒體流解碼混合再編碼，會帶來更大的計算力開銷。

在基于WebRTC的應用的實際開發中，大多數時候服務集成商并不需要從頭自研一套SFU或MCU系統，而是在市面上可用的開源或商業方案中進行選擇。在進行方案選擇時需要考慮的是，如果：

希望客戶端側擁有更多的顯示布局的靈活性且下行帶寬夠大夠穩定；

呼叫中發布媒體流的參與方數較少（譬如不多于6方）；

無異種終端接入需求也不需要轉碼，則可以選擇SFU模式。

否則，如果：

客戶端對下行數據量有苛刻的要求而對聚合畫面布局沒有差異化要求；

所有參與方（或很多參與方）都有發布媒體流的需求（視頻會議的情景）；

有異種終端（譬如SIP終端、IPCamera）的接入需求或轉碼需求；

有服務器側（云端）錄制和推流到CDN的需求，則或許MCU模式更適合。除去所述這些情況以外的應用場景，則需要在各種需求的矛盾中權衡輕重得失以做出選擇了。

不過其實SFU模式和MCU模式并不是絕對互斥的，有的解決方案（例如Intel CS for WebRTC及其商業化版本）是將這兩種模式集成在一起的，服務集成商可以根據具體的應用場景進行靈活配置。

WebRTC發展前景如何？

作為終端技術規范，雖然WebRTC只是實時通信解決方案中的一部分，但是是最貼近用戶的一部分，也許也是最重要的一部分。終端技術規范的標準化，是一個很好的開始。連一向以封閉的技術生態聞名的Apple都擁抱WebRTC了，將促進WebRTC技術的發展和普及，會有越來越多的互聯網（和移動互聯網）應用基于WebRTC構建其實時通信服務。

進入2018年，在互聯網快速發展的當下和將來，WebRTC將極大激活人與人、人與物、物與物（IoT）之間的信息紐帶，移除掉通信終端之間的時間（實時）和空間（基于互聯網）的障礙，成為應用場景創新的一道強大的技術保障。同時，類似VR、AR、自動駕駛等新的應用場景的出現也會給WebRTC技術帶來新的需求和動力，應用場景的商業化成功也將給技術發展持續注入活力和物質資源。譬如近年來直播連麥、網上課堂、遠程控制（抓娃娃機）等基于互聯網的視頻應用的猛烈發展和火熱，一次次催動著基于互聯網的的實時音視頻通信技術的發展，呼喚著WebRTC這樣的統一、開放、透明的標準規范成熟和落地。

想象一下，在基于WebRTC構建的世界里，所有通信終端的媒體描述和連接建立過程都是一致的，只要終端之間開放媒體協商的通道，就可以建立起實時通信，“微信”與“WhatsApp”能建立視頻通話，就像你在中國用手機跟美國的朋友家中的座機打電話一樣。那多美好！推動這一天的早日到來難道不也是我們互聯網音視頻通信工作者們的歷史責任嗎？

總結

以上是生活随笔為你收集整理的展望2018：WebRTC技术现状、应用开发与前景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。