基於 WebRTC 技術的實時通訊服務開發實踐

隨着直播的發展，直播實時互動性變得日益重要。又拍雲在 WebRTC 的基礎上，憑藉多年的開發經驗，結合當下實際狀況，開發 UPRTC 系統，解決了網絡延時、併發量大、客戶端解碼能力差等問題。

WebRTC 的前世此生

什麼是 WebRTC

2010年5月，Google 花費6820萬美圓收購擁有編解碼、回聲消除等技術的 GIPS 公司。以後谷歌開源了 GIPS 的技術，與相關機構 IETF 和 W3C 制定行業標準，組成了現有的 WebRTC 項目。

WebRTC 全稱 Web Real-Time Communication。它並非單一的協議， 包含了媒體、加密、傳輸層等在內的多個協議標準以及一套基於 JavaScript 的 API。經過簡單易用的 JavaScript API ，在不安裝任何插件的狀況下，讓瀏覽器擁有了 P2P音視頻和數據分享的能力。

同時WebRTC 並非一個孤立的協議，它擁有靈活的信令，能夠便捷的對接現有的SIP 和電話網絡的系統。

WebRTC 具備的優點

成立UPRTC項目前，又拍雲通過多重調研和考慮，選擇了 WebRTC，主要有三個緣由：

1. WebRTC 是開源、 免專利費的項目， 大大節省了開發時間和成本；

2. WebRTC 由 Google 主導, 技術很是先進；

3. Safari 等瀏覽器以及其餘終端逐漸增強對 WebRTC 技術的支持。

WebRTC 的核心組件

• 音視頻引擎：OPUS、VP8 / VP九、H264
• 傳輸層協議：底層傳輸協議爲 UDP
• 媒體協議：SRTP / SRTCP
• 數據協議：DTLS / SCTP
• P2P 內網穿透：STUN / TURN / ICE / Trickle ICE
• 信令與 SDP 協商：HTTP / WebSocket / SIP、 Offer Answer 模型

 

圖1爲 WebRTC 內部結構簡化圖，最底層是硬件設備，上面是音頻捕獲模塊和視頻捕獲模塊。

中間部分爲音視頻引擎。音頻引擎負責音頻採集和傳輸，具備降噪、回聲消除等功能。視頻引擎負責網絡抖動優化，互聯網傳輸編解碼優化。

在音視頻引擎之上是 一套 C++ API，在 C++ 的 API 之上是提供給瀏覽器的Javascript API。

△ 圖1：WebRTC內部結構

 

圖2是 WebRTC 涉及到的協議棧，WebRTC 核心的協議都是在右側基於 UDP 基礎上搭建起來的。

其中，ICE、STUN、TURN 用於內網穿透, 解決了獲取與綁定外網映射地址，以及 keep alive 機制。

DTLS 用於對傳輸內容進行加密，能夠看作是 UDP 版的 TLS。因爲 WebRTC 對安全比較重視，這一層是必須的。

SRTP 與 SRTCP 是對媒體數據的封裝與傳輸控制協議。

SCTP 是流控制傳輸協議，提供相似 TCP 的特性，SCTP 能夠基於 UDP 上構建，在 WebRTC 裏是在 DTLS 協議之上。

RTCPeerConnection 用來創建和維護端到端鏈接，並提供高效的音視頻流傳輸。

RTCDataChannel 用來支持端到端的任意二進制數據傳輸。

△ 圖2：WebRTC 協議棧

基於 WebRTC 的 UPRTC

爲了使 WebRTC 協議更適用於實時互動直播，又拍雲在 WebRTC 協議的基礎上進行改造優化，搭建了又拍雲 UPRTC 。支持多種應用場景，包括一對1、一對多和多對多等應用場景。

• 傳統的 WebRTC 應用模式是 P2P 的， UPRTC 則是服務器中轉模式。

由於又拍雲擁有性能優異的 CDN 資源，將 WebRTC 改形成服務器中轉模式以後，採用徹底分佈式系統，部署到全國全部邊緣節點，經過內部加速網絡 UTUN 加速，將轉發、併發壓力轉移到服務端，保證 UPRTC 終端能夠承受更多路併發。

• 加入網絡擁塞自適應控制，較強的弱網適應能力。

以移動設備從 WIFI 網絡切換到 4G 網絡爲例，又拍雲服務器能夠察覺到帶寬變化，統計丟包和延時，進行動態碼率調整，保證在弱網環境下也能進行正常通話。

• 對底層開源組件優化改造，支持高併發業務場景。

又拍雲設計了一套靈活高效的業務信令，用於敏感信令鑑權。

 

圖3爲 UPRTC 技術組成：

1. 媒體通道、數據通道，信令通道；
2. 數據加密模塊；
3. 碼率自適應控制模塊；
4. 又拍雲加速網絡；
5. P2P打洞服務；
6. 房間應用業務；
7. 機器人（自動管理功能和互動功能）。

△ 圖3：UPRTC技術組成

總結

雖然 WebRTC 源代碼相對成熟，可是在實際應用中依舊須要解決如下問題：

1.音頻處理過程當中消耗 CPU 太高；

2.音視頻不一樣步的BUG；

3.安卓端 WebRTC 源碼對H.264支持並不全面，僅默認支持高通的芯片；

4.服務端架構過程當中須要加入碼率自適應算法，動態控制總碼率帶寬在 2M 之內。

 

推薦參考文檔：

W3C API 相關文檔: https://github.com/w3c

IETF 協議相關文檔: https://datatracker.ietf.org

 

相關閱讀：

實時音視頻互動系列（下）：基於 WebRTC 技術的實戰解析

WebSocket+MSE——HTML5 直播技術解析

從Html5直播到互動直播，看直播協議的選擇