基于 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 / VP9、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 。支援多種應用場景，包括一對一、一對多和多對多等應用場景。

• 傳統的 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直播到互動直播，看直播協定的選擇