WebRTC 開發(fā)實(shí)踐：為什么你需要 SFU 服務(wù)器

當(dāng)你入門 WebRTC 之后，很快就會接觸到一個名詞，叫做：SFU，你可能很容易就在網(wǎng)上尋找到很多 SFU 的開源實(shí)現(xiàn)，并并興致勃勃地開始編譯、部署和測試這些服務(wù)器，但是可曾想過，為啥我們的 WebRTC 應(yīng)用需要 SFU 服務(wù)器 ？

1 WebRTC P2P 通話的網(wǎng)絡(luò)模型

如圖是 WebRTC P2P 模式下的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，ClientA 和 ClientB 如果能夠順利建立 P2P 的連接，則可直接通過 P2P 互相交換數(shù)據(jù)。如果由于某些網(wǎng)絡(luò)環(huán)境原因，無法成功打通 P2P 連接的話，則可以通過一臺 TURN Server 來中轉(zhuǎn)數(shù)據(jù)給對方。

這個 TURN Server 是指支持 TURN 協(xié)議 的服務(wù)器，它扮演著一種網(wǎng)絡(luò)中繼的角色，支持把一個 Client 的數(shù)據(jù)包透明轉(zhuǎn)發(fā)到多個其他的 Client 客戶端。

在這種簡單的 P2P 通話場景下，其實(shí)這種模型基本夠用了，根本不需要架設(shè)什么 SFU 服務(wù)器。

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

如圖所示，多人通話跟單人通話唯一的不同就是每個客戶端都需要跟其他兩個端都分別建立 P2P 連接，我在《WebRTC 開發(fā)實(shí)踐：從一對一通話到多人會議》也介紹過這個場景。與一對一通話一樣，如果兩個端能夠順利建立 P2P 的連接，則直接通過 P2P 互相交換數(shù)據(jù)；如果無法打通，則利用 Turn Server 來中轉(zhuǎn)數(shù)據(jù)。

我們把這種完全使用 P2P 方式的網(wǎng)絡(luò)拓?fù)浣Y(jié)稱之為 Mesh 結(jié)構(gòu)，下面我們談?wù)勊膬?yōu)劣點(diǎn)。

2 WebRTC Mesh 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的優(yōu)劣

優(yōu)點(diǎn)：

• 邏輯簡單，容易實(shí)現(xiàn)

• 服務(wù)端比較 “輕量”，TURN 服務(wù)器比較簡單，一定比例的 P2P 成功率可極大減輕服務(wù)端的壓力

缺點(diǎn)：

• 每新增一個客戶端，所有的客戶端都需要新增一路數(shù)據(jù)上行，客戶端上行帶寬占用太大。因此，通話人數(shù)越多，效果越差

• 無法在服務(wù)端對視頻進(jìn)行額外處理，如：錄制存儲回放、實(shí)時轉(zhuǎn)碼、智能分析、多路合流、轉(zhuǎn)推直播等等

由此可以看到，mesh 結(jié)構(gòu)的缺點(diǎn)影響還是比較大的，真正商業(yè)化的應(yīng)用，是需要具備良好的通話質(zhì)量、服務(wù)穩(wěn)定性和可擴(kuò)展性的，因此，亟需一種新的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，能夠很好的規(guī)避 mesh 結(jié)構(gòu)的這些短板。

3 什么是 SFU ？

SFU 的全稱是：Selective Forwarding Unit，是一種通過服務(wù)器來路由和轉(zhuǎn)發(fā) WebRTC 客戶端音視頻數(shù)據(jù)流的方法。

如圖所示，SFU 服務(wù)器最核心的特點(diǎn)是把自己 “偽裝” 成了一個 WebRTC 的 Peer 客戶端，WebRTC 的其他客戶端其實(shí)并不知道自己通過 P2P 連接過去的是一臺真實(shí)的客戶端還是一臺服務(wù)器，我們通常把這種連接稱之為 P2S，即：Peer to Server。除了 “偽裝” 成一個 WebRTC 的 Peer 客戶端外，SFU 服務(wù)器還有一個最重要的能力就是具備 one-to-many 的能力，即可以將一個 Client 端的數(shù)據(jù)轉(zhuǎn)發(fā)到其他多個 Client 端。

這種網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中，無論多少人同時進(jìn)行視頻通話，每個 WebRTC 的客戶端只需要連接一個 SFU 服務(wù)器，上行一路數(shù)據(jù)即可，極大減少了多人視頻通話場景下 Mesh 模型給客戶端帶來的上行帶寬壓力。

SFU 服務(wù)器跟 TURN 服務(wù)器最大的不同是，TURN 服務(wù)器僅僅是為 WebRTC 客戶端提供的一種輔助的數(shù)據(jù)轉(zhuǎn)發(fā)通道，在 P2P 不通的時候進(jìn)行透明的數(shù)據(jù)轉(zhuǎn)發(fā)。而 SFU 是 “懂業(yè)務(wù)” 的， 它跟 WebRTC 客戶端是平等的關(guān)系，甚至 “接管了” WebRTC 客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)的申請和控制。

4 什么是 MCU ？

從上述 SFU 的定義可以看到，SFU 這種網(wǎng)絡(luò)拓?fù)淠Ｐ?，通過由 SFU Server 來實(shí)現(xiàn) one-to-many ，減輕了多人視頻通話場景下每個客戶端的上行帶寬壓力，但是下行依然是多路流，隨著通話人數(shù)的增大，下行帶寬的壓力依然會成比例的增大，那能否讓下行也只剩一路流呢？—— 可以，通過在服務(wù)器端合流后再下發(fā)即可解決，如下圖所示：

這種網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，被稱之為 MCU，它的特點(diǎn)是，由 MCU Server 將各路客戶端上行的視頻流合成為一路，再轉(zhuǎn)發(fā)給其他客戶端。這種模型相比于 SFU 降低了多人視頻通話場景下客戶端的下行帶寬壓力，但是由于合流需要轉(zhuǎn)碼操作，對服務(wù)器端壓力比較大，而且下發(fā)給客戶端的流是固定的合流畫面，靈活性不是特別好。

5 為啥推薦選擇 SFU ？

綜上所述，純 mesh 方案無法適應(yīng)多人視頻通話，也無法實(shí)現(xiàn)服務(wù)端的各種視頻處理需求，最先排除在商業(yè)應(yīng)用之外。

SFU 相比于 MCU，服務(wù)器的壓力更?。冝D(zhuǎn)發(fā)，無轉(zhuǎn)碼合流），靈活性更好（可選擇性開關(guān)任意一路數(shù)據(jù)的上下行等），受到更廣泛的歡迎和應(yīng)用，常見的開源 SFU 服務(wù)器有：Licode，Janus，Jitsi，mediasoup，Medooze 等等，各有特點(diǎn)，大家可以去項(xiàng)目主頁了解更詳細(xì)的情況。

當(dāng)然，也可以組合使用 SFU + MCU 的混合方案，以靈活應(yīng)對不同場景的應(yīng)用需要。

5 小結(jié)

關(guān)于 WebRTC SFU 相關(guān)知識點(diǎn)就分享到這里了，如有疑問的小伙伴歡迎來信 lujun.hust@gmail.com 交流。另外，也歡迎大家關(guān)注我的新浪微博 @盧_俊 或者 微信公眾號 @Jhuster 獲取最新的文章和資訊。