WebRTC 開發實踐：爲何你須要 SFU 服務器

當你入門 WebRTC 以後，很快就會接觸到一個名詞，叫作：SFU，你可能很容易就在網上尋找到不少 SFU 的開源實現，並並興致勃勃地開始編譯、部署和測試這些服務器，可是可曾想過，爲啥咱們的 WebRTC 應用須要 SFU 服務器 ？

1 WebRTC P2P 通話的網絡模型

如圖是 WebRTC P2P 模式下的網絡拓撲結構，ClientA 和 ClientB 若是可以順利創建 P2P 的鏈接，則可直接經過 P2P 互相交換數據。若是因爲某些網絡環境緣由，沒法成功打通 P2P 鏈接的話，則能夠經過一臺 TURN Server 來中轉數據給對方。

這個 TURN Server 是指支持 TURN 協議 的服務器，它扮演着一種網絡中繼的角色，支持把一個 Client 的數據包透明轉發到多個其餘的 Client 客戶端。

在這種簡單的 P2P 通話場景下，其實這種模型基本夠用了，根本不須要架設什麼 SFU 服務器。

下面咱們再近一步，看看多人通話的場景：

如圖所示，多人通話跟單人通話惟一的不一樣就是每一個客戶端都須要跟其餘兩個端都分別創建 P2P 鏈接，我在《WebRTC 開發實踐：從一對一通話到多人會議》也介紹過這個場景。與一對一通話同樣，若是兩個端可以順利創建 P2P 的鏈接，則直接經過 P2P 互相交換數據；若是沒法打通，則利用 Turn Server 來中轉數據。

咱們把這種徹底使用 P2P 方式的網絡拓撲結稱之爲 Mesh 結構，下面咱們談談它的優劣點。

2 WebRTC Mesh 網絡拓撲結構的優劣

優勢：

• 邏輯簡單，容易實現

• 服務端比較 「輕量」，TURN 服務器比較簡單，必定比例的 P2P 成功率可極大減輕服務端的壓力

缺點：

• 每新增一個客戶端，全部的客戶端都須要新增一路數據上行，客戶端上行帶寬佔用太大。所以，通話人數越多，效果越差

• 沒法在服務端對視頻進行額外處理，如：錄製存儲回放、實時轉碼、智能分析、多路合流、轉推直播等等

由此能夠看到，mesh 結構的缺點影響仍是比較大的，真正商業化的應用，是須要具有良好的通話質量、服務穩定性和可擴展性的，所以，亟需一種新的網絡拓撲結構，可以很好的規避 mesh 結構的這些短板。

3 什麼是 SFU ？

SFU 的全稱是：Selective Forwarding Unit，是一種經過服務器來路由和轉發 WebRTC 客戶端音視頻數據流的方法。

如圖所示，SFU 服務器最核心的特色是把本身 「假裝」 成了一個 WebRTC 的 Peer 客戶端，WebRTC 的其餘客戶端其實並不知道本身經過 P2P 鏈接過去的是一臺真實的客戶端仍是一臺服務器，咱們一般把這種鏈接稱之爲 P2S，即：Peer to Server。除了 「假裝」 成一個 WebRTC 的 Peer 客戶端外，SFU 服務器還有一個最重要的能力就是具有 one-to-many 的能力，便可以將一個 Client 端的數據轉發到其餘多個 Client 端。

這種網絡拓撲結構中，不管多少人同時進行視頻通話，每一個 WebRTC 的客戶端只須要鏈接一個 SFU 服務器，上行一路數據便可，極大減小了多人視頻通話場景下 Mesh 模型給客戶端帶來的上行帶寬壓力。

SFU 服務器跟 TURN 服務器最大的不一樣是，TURN 服務器僅僅是爲 WebRTC 客戶端提供的一種輔助的數據轉發通道，在 P2P 不通的時候進行透明的數據轉發。而 SFU 是 「懂業務」 的， 它跟 WebRTC 客戶端是平等的關係，甚至 「接管了」 WebRTC 客戶端的數據轉發的申請和控制。

4 什麼是 MCU ？

從上述 SFU 的定義能夠看到，SFU 這種網絡拓撲模型，經過由 SFU Server 來實現 one-to-many ，減輕了多人視頻通話場景下每一個客戶端的上行帶寬壓力，可是下行依然是多路流，隨着通話人數的增大，下行帶寬的壓力依然會成比例的增大，那可否讓下行也只剩一路流呢？—— 能夠，經過在服務器端合流後再下發便可解決，以下圖所示：

這種網絡拓撲結構，被稱之爲 MCU，它的特色是，由 MCU Server 將各路客戶端上行的視頻流合成爲一路，再轉發給其餘客戶端。這種模型相比於 SFU 下降了多人視頻通話場景下客戶端的下行帶寬壓力，可是因爲合流須要轉碼操做，對服務器端壓力比較大，並且下發給客戶端的流是固定的合流畫面，靈活性不是特別好。

5 爲啥推薦選擇 SFU ？

綜上所述，純 mesh 方案沒法適應多人視頻通話，也沒法實現服務端的各類視頻處理需求，最早排除在商業應用以外。

SFU 相比於 MCU，服務器的壓力更小（純轉發，無轉碼合流），靈活性更好（可選擇性開關任意一路數據的上下行等），受到更普遍的歡迎和應用，常見的開源 SFU 服務器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等，各有特色，你們能夠去項目主頁瞭解更詳細的狀況。

固然，也能夠組合使用 SFU + MCU 的混合方案，以靈活應對不一樣場景的應用須要。

5 小結

關於 WebRTC SFU 相關知識點就分享到這裏了，若有疑問的小夥伴歡迎來信 lujun.hust@gmail.com 交流。另外，也歡迎你們關注個人新浪微博 @盧_俊 或者 微信公衆號 @Jhuster 獲取最新的文章和資訊。