《聊聊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在實現單PeerConnectionbundle時采用的SDP方案是不一樣的。Chrome是用了Plan B的方案，Firefox是用了UnifiedPlan的方案。當然Chrome未來即將支持UnifiedPlan，而當前要使用單PeerConnection方案就必須在Server端編寫兼容代碼。PlanB采用的是一個m行，多個a行來描述多流，而UnifiedPlan是多個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的線程方案。

——推薦閱讀——

聊聊WebRTC網關服務器1：如何選擇服務端端口方案？

Wireshark抓包分析——TCP/IP協議

Wireshark對HTTPS數據的解密

網易云信IM小程序上線？我們是這么做的！>>

全面復盤！深度剖析直播答題產品架構的難點與坑>>

如何快速設計短信驗證碼>>

如何做好Android 端音視頻測試>>

總結

以上是生活随笔為你收集整理的聊聊WebRTC网关服务器2：如何选择PeerConnection方案？的全部內容，希望文章能夠幫你解決所遇到的問題。

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