聊聊 WebRTC 網關服務器 2：如何選擇 PeerConnection 方案？

《聊聊 WebRTC 網關服務器》系列文章系由 WebRTCon2018 中網易雲信音視頻技術專家的分享內容《從零開始構建音視頻網關服務器》整理而成，該系列文章將和你們分享網易 NRTC 在 WebRTC 網關項目的自研過程當中遇到的一些問題，以及咱們最終的解決方法。
《聊聊WebRTC網關服務器》第二篇文章將和你們分享如何選擇PeerConnection方案。

在會議場景下，網易 NRTC 的 WebRTC 網關使用的是 SFU 方案，如上圖舉例所示，每一個 WebRTC 上行一路媒體數據到 WebRTC 網關服務器，同時還須要從網關接收下行的三路媒體數據，對於一個 WebRTC 客戶端來講就有多路流。對於這種多流的場景，咱們有兩種 PeerConnection 方案可使用：

1. 單個PeerConnection裏有多個 media stream (bundle)；
2. 爲不一樣的 media stream 建立不一樣的 PeerConnection。

那咱們如何選擇 PeerConnection 的方案呢？

首先咱們來看看單 PeerConnection 方案，全部的客戶端和服務器之間只須要創建一個 PeerConnection，這個 PeerConnection 是一個雙向的 PeerConnection，它既能夠發數據，也能夠收數據，這個方案簡單明瞭，實現時候要注意一個問題，就是 Chrome 和 Firefox 在實現單 PeerConnection bundle 時採用的 SDP 方案是不同的。Chrome 是用了Plan B 的方案，Firefox 是用了 Unified Plan 的方案。固然 Chrome 將來即將支持 Unified Plan，而當前要使用單 PeerConnection 方案就必須在 Server 端編寫兼容代碼。PlanB 採用的是一個 m 行，多個 a 行來描述多流，而 Unified Plan 是多個 m 行，描述多流，具體的作法 RFC 草案文檔裏面有詳細描述，我這裏就不贅述了。

那麼單 PeerConnection 有什麼優點呢？

1. Server端媒體處理代碼相對簡單；
2. 服務端性能較好，只須要創建一個PeerConnection鏈接，DTLS握手只須要作一次。

單 PeerConnection 又有什麼劣勢？

1. 服務器須要編寫兼容不一樣瀏覽器的代碼；
2. 不一樣用戶的下行媒體流過多後，SDP 裏面 m 行或 a 不少，致使 SDP 長度過長；特別是當用戶頻繁進出或者媒體狀態發生改變時，SDP 須要進行頻繁 Update， SDP 傳輸耗費的帶寬就會不少；
3. Firefox Unified Plan 在多人場景下，較高的機率下會出現崩潰 Bug，咱們已經向 Firefox 提交了 bug。

而相對單 PeerConnection，多 PeerConnection 的方案就比較便於理解了，如圖 A/B/C/D 四我的的會，對於 A 來講有一個上行的 PeerConnection，以及 3 個下行的 PeerConnection對應 B/C/D。每個用戶的上下行數據都是分開的，這個也是WebRTC比較推薦的方案。
這個方案主要的難點是服務端要去維護每一個用戶的上下行 PeerConnection 對應關係，總體的代碼邏輯較複雜。可是它的兼容性比較好。因此 NRTC 的 WebRTC 網關最終選擇了多 PeerConnection 方案。

在分享完 PeerConnecton 的方案後，下面就進入 Server 的線程方案的選擇和優化。這個也是網關服務器架構設計的核心部分。

《聊聊 WebRTC 網關服務器》第三篇文章將具體爲你們介紹如何優化 Server 的線程方案。

---

隨着音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易 MC 官方博客以及微信公衆號：**

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網

官網微信公衆號：