音視頻通信為什么要選擇WebRTC？

在網上經常看到有人說：“在線教育直播是用WebRTC做的”，“音視頻會議是用WebRTC做的”……；“聲網、騰訊、阿里……都使用的WebRTC”，但你有沒有好奇，這些一線大廠為什么都要使用WebRTC呢？換句話說，WebRTC到底好在哪里呢？

這個問題，對于長期做音視頻實時通信的老手來說是不言而喻的；但對于新手，則是急切想知道，而又很難得到答案的問題，那么本文我將采用對比法，向你詳細闡述一下WebRTC到底好在哪里，

這次我們對比的指標包括：性能、易用性、可維護性、流行性、代碼風格等多個方面，不過，要做這樣的對比并非易事兒，首先要解決的難點是，目前市面上沒有一款與WebRTC接近或有相似功能的開源庫，這真成了無米之炊了！

好在這點困難并難不倒我們，既然沒有與之可比較的開源庫，那我們就自己“造”一個，用自研系統與WebRTC作比較，評估一下自研系統與基于WebRTC開發的音視頻客戶端，哪個成本更低、質量更好，通過這樣的對比，相信能讓你更加了解WebRTC，知道其到底有多優秀了，

自研系統直播客戶端架構

首先我們先來了解一下自研直播客戶端的架構，其如（圖1）所示，這是一個最簡單的音視頻直播客戶端架構，通過這張架構圖，你大體可以知道自研系統都要實作那些模塊了，

（圖1） 由（圖1）你可以知道，一個最簡單的直播客戶端至少應該包括：音視頻采集模塊、音視頻編碼模塊、網路傳輸模塊、音視頻解碼模塊和音視頻渲染模塊五大部分， 音視頻采集模塊：該模塊呼叫系統的API，從麥克風和攝像讀取設備采集到的音視頻資料，音頻采集的是PCM資料，視頻采集的是YUV資料， 音視頻編碼模塊：它負責將音視頻設備上采集的原始資料（PCM、YUV)進行壓縮編碼，網 絡傳輸模塊：該模塊負責將編碼后的資料生成RTP包，并通過網路傳輸給對端；同時，接收對端的RTP資料， 音視頻解碼模塊：它將網路模塊接收到的壓縮資料進行解碼，還原回原始資料（PCM、YUV）， 音視頻渲染渲染：拿到解碼后的資料后，該模塊將音頻輸出到揚聲器，將視頻渲染到顯示幕， 通過前面的介紹，相信你一定覺得，自研一個直播客戶端好像也不是特別難的事兒，但實際上，上面介紹的音視頻直播客戶端架構是極簡化的，甚至都不能稱之為直播客戶端架構，而只能稱它為示意圖，因為要將它變為真實的、可商用的架構還需要做不少的細化作業，

拆分音視頻模塊

接下來，咱們就對上面的直播客戶端架構圖進行逐步細化，細化的第一步就是拆分音視頻模塊，因為在實際開發中，音頻與視頻的處理是完全獨立的，它們有各自的處理方式，如音頻有獨立的采集設備（聲卡），獨立的播放設備（揚聲器）、訪問音頻設備的系統API等，另外，音頻還有多種音頻編解碼器，如Opus、AAC、iLBC等；同樣，視頻也有自己獨立的采集設備（攝像頭）、渲染設備（顯示幕）、各種視頻編碼器，如H264、VP8等，細化后的直播客戶端架構如（圖2）所示，

（圖2） 從（圖2）中你可以看到，細化后的架構中，音頻的采集模塊與視頻的采集模塊是分開的，而音頻編解碼模塊與視頻的編解碼模塊也都是分開的，也就是說，音頻是一條處理流程，視頻是另外一條處理流程，它們之間并不相交，在音視頻處理中，我們一般稱每一路音頻或每一路視頻為一條軌， 除此之外，你還可以知道，自研音視頻直播客戶端要實作的模塊遠不止5個，至少應該包括：音頻采集模塊、視頻采集模塊、音頻編碼/音頻解碼模塊、視頻編碼/視頻解碼模塊、網路傳輸模塊、音頻播放模塊以及視頻渲染７個模塊，

跨平臺

實作音視頻直播客戶端除了要實作上面介紹的7個模塊外，還要考慮跨平臺的問題，只有在各個平臺上都能實作音視頻的互聯互通，才能稱得上是一個合格的音視頻直播客戶端，所以它至少應該實作Windows端、Mac端、Android端以及iOS四個終端，當然如果還能夠支持Linux端和瀏覽器則是再好不過的了，

你要知道的是，如果不借助WebRTC，想在瀏覽器上實作音視頻實時互通，難度是非常大的，這是自研系統的一大缺陷，除了與瀏覽器互通外，其它幾個終端實作互通倒是相對較容易的事兒，

增加跨平臺后，音視頻直播客戶端的架構要較之前復雜得多了，其如（圖3）所示，從這張圖中你可以看到，要實作跨平臺，難度最大、首當其沖的，是訪問硬體設備的模塊，如音頻采集模塊、音頻播放模塊、視頻采集模塊以及視頻播放模塊等，它們在架構中的變化是最大的，

（圖3）
以音頻采集為例，在不同的平臺上，采集音頻資料時使用的API是完全不一樣的，PC端使用的是CoreAudio系列的API；巧合的是，Mac端用于采集音頻的系統API也稱為CoreAudio，不過具體的函式名肯定是不同的；在Android端，它為采集音視頻提供的API稱之為AudioRecord；iOS端，使用AudioUnit來采集音頻資料；而Linux端，則使用PulseAudio采集音頻資料，
總之，每個終端都有各自采集音視頻資料的API，由于不同的系統，其API設計的架構也不同，所以在使用這些API時，呼叫的方式和使用的邏輯也千差萬別，因此，在開發這部分模塊時，其作業量是巨大的，

插件化管理

對于音視頻直播客戶端來說，我們不但希望它可以處理音頻資料、視頻資料，而且還希望它可以分享螢屏、播放多媒體檔案、共享白板……此外，既使是處理音視頻，我們也希望它可以支持多種編解碼格式，如音頻除了可以支持Opus、AAC外，還可以支持G.711/G.722、iLBC、speex等；視頻除了可能支持H264外，還可以支持H265、VP8、VP9、AV1等，這樣它才能應用的更廣泛，

實際上，這些音視頻編解碼器都有各自的優缺點，也有各自適用的范圍，比如G.711/G.722主要用于電話系統，音視頻直播客戶端要想與電話系統對接，就要支持這種編解碼格式；Opus主要用于實時通話；AAC主要應用于音樂類的應用，如鋼琴教學等，所以，我們希望直播客戶端能夠支持盡可能多的編解碼器，這樣的直播客戶端才足夠強大，

如何才能做到這一點呢?最好的設計方案就是實作插件化管理，當你需要支持某個功能時，直接撰寫一個插件放上去即可；當不需要的時候，可以隨時將插件拿下來，這樣的設計方案靈活、安全、可靠，

（圖4） 為了讓直播客戶端支持插件化管理，我對之前的架構圖又做了調整，如（圖4）所示，從中你可以看到，為了支持插件化管理，我將原來架構圖中的音視頻編解碼器換成音視頻編解碼插件管理器，而各種音視頻編解碼器（Opus、AAC、iLBC......）都可以作為一個插件注冊到其中，當你想使用某種型別的編碼器時，可以通過引數進行控制，這樣從音視頻采集模塊采集到的資料就會被送往對應的編碼器進行編碼；當接收接收到RTP格式的音視頻資料時，又可以根據RTP頭中的Payload Type來區分，將資料交由對應的解碼器進行解碼，經這樣處理后，咱們的音視頻直播客戶端的功能就更強大了，應用范圍也更廣了， 這里我以音頻編解碼器為例，簡要的向你介紹一下直播客戶端增加插件管理前后的區別，客戶端在增加插件管理之前，它只能使用一種音頻編解碼器，如Opus，因此，在一場直播活動中，所有參與直播的終端都只能使用同一種音頻的編解碼器（Opus），這樣看起來貌似也不會產生什么問題，是吧？不過，假如此時，我們想將一路電話語音接入到這場直播中（電話語音使用的編解碼器為G.711/G.722），它就無能為力了；而有了插件管理情況就不同了，各終端可以根據接收到的音頻資料型別呼叫不同的音頻解碼器進行解碼，從而實作不同編解碼器在同一場直播中互通的場景，這就是插件化管理給我們帶來的好處，

服務質量

除了上面我介紹的幾點外，要實作一個功能強大的、性能優越的、應用廣泛的音視頻直播客戶端還有很多的作業要做，尤其將服務質量是大家特別關心的，如果直播客戶端不能提供好的服務質量，那它就失去了商業價值，

實時通信中的服務質量指的是什么呢？它主要包括三個方面，一是通信時延小；二是同等網路條件下視頻更清晰、流暢；三是同等網路條件下語音失真小，如何才能保障通信時延小、視頻清晰、語音不失真呢？

這里的關鍵是網路，如果直播客戶端可以保障用戶有一條非常好的網路線路，在這條線路上傳輸的時延最小、不丟包、不亂序，那我們的音視頻服務質量自然就上去了，對吧！

但我們都知道，網路的問題是最難解決的，出現丟包、抖動、亂序更是家常便飯，有的同學可以會說 TCP 不是已經解決了丟包、亂序這些問題嗎？確實是，但它是以犧牲時延為代價的，當我們的網路比較優質時，TCP/UDP都可以用于實時傳輸，但大多數情況下，我們首選UDP，原因是在弱網環境下使用TCP會產生極大的延時，

要想弄清楚TCP為什么在弱網環境下會產生極大的延時，就要介紹一點TCP的機制的了，TCP為了保證不丟包，不亂序，采用了發送、確認、丟包、重傳的機制，正常情況下，資料從一端傳輸到另一端是沒有任何問題的，但當出現丟包時就會有較大的麻煩，如圖所示，

（圖5） 圖中顯示了多次丟包時的延遲情況：從客戶端向服務端發送資料包，服務端需要回傳ACK訊息進行確認; 客戶端收到確認訊息后, 才能繼續發送后面的資料（有滑窗時也是類似的），每次客戶端發完資料后，都會啟動一個定時器，定時器的最短超時時間是200ms，如果因某種原因，在200毫秒客戶端沒有收到回傳的ACK包，客戶端會重發上一個包，由于TCP有退避機制，以防止頻繁發送丟失的包，因此會將重發包的超時時間延長到400ms，如果重發包依然沒有收到確認訊息，則下一次重發的超時時間會延長到800ms，我們可以看到，連續幾次丟包后，就會產生非常大的延遲，這就是TCP在弱網環境下不能使用的根本原因， 根據實時通信指標，超過 500ms 就不能稱為實時通信了，因此在弱網情況下，絕對不能使用TCP協議，實時通信的指標如（圖6）所示，

（圖6） 通過（圖6）中的表格可以看到，如果端到端延遲在200ms以內，說明整個通話是優質的，通話效果就像大家在同一個房間里聊天一樣；300ms以內，大多數人很滿意，400ms以內，有小部分人可以感覺到延遲，但互動基本不受影響；500ms以上時，延遲會明顯影響互動，大部分人都不滿意，所以最關鍵的一點是500ms，只有延遲低于500ms，才可以說是合格的實時互動系統， 通過上面的描述我們可以知道，如果我們想在自己的直播客戶端中實作好的服務質量，任務還是非常艱巨的，當然，除了上面要實作的功能外，還有其它很多需要處理的細節，

其它

音視頻不同步問題，音視頻資料經網路傳輸后，由于網路抖動和延遲等問題，很可能造成音視頻不同步，因此，你在實作音視頻直播客戶端時，需要增加音視頻同步模塊以保障音視頻的同步，

回音問題，回音問題指的是，自己與其它人進行實時互動時，可以聽到自己的回聲，在實時音視頻通信中，不光有回音問題，還有噪音、聲音過小等問題，我們將它們統稱為3A問題，這些問題都是非常棘手的，目前開源的專案中，只有WebRTC和Speex有開源的回音消除演算法，而且WebRTC的回音消除演算法還是目前世界上最頂級的，

音視頻的實時性問題，要進行實時通信，網路質量尤為關鍵，但你應該也清楚，網路的物理層是很難保障網路服務質量的，必須在軟體層加以控制才行，雖然大家常用的TCP協議有一套完整的保障網路質量的方案，但它在實時性方面表現不佳，換句話說，TCP是以犧牲實時性來保障網路服務質量的，而實時性又是音視頻實時通信的命脈，這就導致TCP協議不能作為音視頻實時傳輸的最佳選擇了，因此，為了保證實時性，一般情況下實時直播應該首選UDP協議，但這樣一來，我們就必須自己撰寫網路控制演算法以保證網路質量了，

此外，還有網路擁塞、丟包、延時、抖動、混音……不勝列舉，可以說，要實作一個實時的音視頻直播客戶端有許許多多的問題要解決，這里我就不一一列舉了，總之，通過上面的描述，我想你已經清楚要自己研發一套音視頻直播客戶端到底有多難了，

WebRTC客戶端架構

實際上，在直播客戶端架構一節我講的所有功能，WebRTC都已經實作了，下面讓我們看一下WebRTC架構圖吧，如（圖7）所示，

（圖7） 從WebRTC架構圖中你可以了解到，它大體上可以分成四層：即介面層、Session層、核心引擎層和設備層，下面我就向你簡要的介紹一下每一層的作用， 介面層包括兩部分，一是Web層介面；二是Native層介面，也就是說，你既可以使用瀏覽器開發音視頻直播客戶端，也可以使用Native(C++、Android、OC等)開發音視頻直播客戶端，

Session層的主要作用是控制業務邏輯，如媒體協商、收集Candidate等，這些操作都是在Session層處理的；

核心引擎層包括的內容就比較多了，從大的方面說，它包括音頻引擎、視頻引擎和網路傳輸層，音頻引擎層包括NetEQ、音頻編解碼器（如OPUS、iLBC)、3A等，視頻引擎包括JitterBuffer、視頻編解碼器（VP8/VP9/H264)等，網路傳輸層包括SRTP、網路I/O多路復用、P2P等，以上這些內容中，本書重點介紹了網路相關的內容，它們分布在第三章音視頻實時通信的本質、第六章WebRTC中的ICE實作、第九章RTP/RTCP協議詳解、第十章WebRTC擁塞控制等幾個章節中，由于篇幅的原因，其它內容我會陸續發布在我的個人主站https://avdancedu.com上，

設備層主要與硬體打交道，它涉及的內容包括：在各終端設備上進行音頻的采集與播放、視頻的采集以及網路層等，這部分內容會在本書的最后一章 \textbf{WebRTC原始碼分析}中做詳細介紹，

從上面的描述中你可以看到，在WebRTC架構的四層中，最復雜、最核心的是第三層，即引擎層，因此，這里我再對引擎層內部的關系做下簡要介紹，引擎層包括三部分內容，分別是：音頻引擎、視頻引擎以及網路傳輸，其中音視引擎和視頻引擎是相對比較獨立的，不過，它們都需要與網路傳輸層（transport）打交道，也就是說，它們都需要將自己產生的資料通過網路傳輸層發送出去；同時，也需要通過網路傳輸層接收其它端發過來的資料，此外，音頻引擎與視頻引擎由于要進行音視頻同步的原因，所以它們之間也存在著關聯關系，

（圖8） 最后，我們再次以音頻為例（如圖8所示），來看一下WebRTC中的資料流是如何流轉的吧，當WebRTC作為發送端時，它通過音頻設備采集到音頻資料后，先要進行3A處理，處理后的資料交由音頻編碼器編碼，編碼后由網路傳輸層將資料發送出去；另一方面，當網路傳輸層收到資料后，它要判斷資料的型別是什么，如果是音頻，它會將資料交給音頻引擎模塊處理，資料首先被放入到NetEQ模塊做平滑處理及音頻補償處理，之后進行音頻解碼，最終將解碼后的資料通過揚聲器播放出來，視頻的處理流程與音頻的處理流程是類似的，這里我就不再贅述了，

小結

通過上面對自研音視頻客戶端架構的描述以及WebRTC客戶端架構的描述，相信在你心中，對WebRTC的優勢已經非常清楚了，下面我再從性能、跨平臺、音視頻服務質量、穩定性等幾個方面對兩者做一下總結，如（圖9）所示：

（圖9） （圖9）告訴我們，WebRTC在實時音視頻直播方面的優勢是不言而喻的，又有Google的強大支持，這就是為什么大家都選擇WebRTC的真正原因了，

我的視頻課

WebRTC實時互動直播技術入門與實戰 5G時代必備技能
百萬級高并發WebRTC流媒體服務器設計與開發
編程必備基礎-音視頻小白系統入門課
OpenCV入門到進階：實戰三大典型專案
經典再升級-FFmpeg音視頻核心技術全面精講+實戰

我的新書

WebRTC音視頻實時互動技術–原理、實戰與原始碼分析

★本書深入淺出地對WebRTC技術進行了系統講解，既有原理又有實戰，從WebRTC是如何實作實時音視頻通信的，到如何應用WebRTC庫實作音視頻通信，再到WebRTC原始碼的剖析，逐步展開講解，此外，對WebRTC的傳輸系統進行了重點分析，相信讀者通過本書可以一窺WebRTC傳輸的奧秘，