聊聊WebRTC網關伺服器2：如何選擇PeerConnection方案？
《聊聊WebRTC網關伺服器》系列文章系由WebRTCon2018中網易雲信音視頻技術專家的分享內容《從零開始構建音視頻網關伺服器》整理而成，該系列文章將和大家分享網易NRTC在WebRTC網關項目的自研過程中遇到的一些問題，以及我們最終的解決方法。
《聊聊WebRTC網關伺服器》第二篇文章將和大家分享如何選擇PeerConnection方案。
在會議場景下，網易NRTC的WebRTC網關使用的是SFU方案，如上圖舉例所示，每個WebRTC上行一路媒體數據到WebRTC網關伺服器，同時還需要從網關接收下行的三路媒體數據，對於一個WebRTC客戶端來說就有多路流。對於這種多流的場景，我們有兩種PeerConnection方案可以使用：
- 單個PeerConnection里有多個media stream（bundle）；
- 為不同的media stream創建不同的PeerConnection。
那麼我們如何選擇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有什麼優勢呢？
- Server端媒體處理代碼相對簡單；
- 服務端性能較好，只需要建立一個PeerConnection連接，DTLS握手只需要做一次。
單PeerConnection又有什麼劣勢？
- 伺服器需要編寫兼容不同瀏覽器的代碼；
- 不同用戶的下行媒體流過多後，SDP裡面m行或a很多，導致SDP長度過長；特別是當用戶頻繁進出或者媒體狀態發生改變時，SDP需要進行頻繁Update， SDP傳輸耗費的帶寬就會很多；
- Firefox Unified Plan在多人場景下，較高的概率下會出現崩潰Bug，我們已經向Firefox提交了bug。
多PeerConnection方案
而相對單PeerConnection，多PeerConnection的方案就比較便於理解了，如圖A/B/C/D四個人的會，對於A來說有一個上行的PeerConnection，以及3個下行的 PeerConnection對應B/C/D。每一個用戶的上下行數據都是分開的，這個也是WebRTC比較推薦的方案。
這個方案主要的難點是服務端要去維護每個用戶的上下行PeerConnection對應關係，整體的代碼邏輯較複雜。但是它的兼容性比較好。所以NRTC的WebRTC網關最終選擇了多PeerConnection方案。
在分享完PeerConnecton的方案後，下面就進入Server的線程方案的選擇和優化。這個也是網關伺服器架構設計的核心部分。《聊聊WebRTC網關伺服器》第三篇文章將具體為大家介紹如何優化Server的線程方案。
推薦閱讀：