問題：為什么要搞這么多架構？

WebRTC 雖然是一項主要使用 P2P 的實時通訊技術，本應該是無中心化節點的，但是在一些大型多人通訊場景，如果都使用端對端直連，端上會遇到很帶寬和性能的問題，所以就有了下圖的三種架構。

一、Mesh

每個端都與其它端互連。

以上圖最左側為例，5個瀏覽器，二二建立 P2P 連接，每個瀏覽器與其它 4 個建立連接，總共需要10個連接。如果每條連接占用1M帶寬，則每個端上行需要4M，下行帶寬也要4M，總共帶寬消耗20M。而且除了帶寬問題，每個瀏覽器上還要有音視頻“編碼/解碼”，CPU使用率也是問題，一般這種架構只能支持4~6人左右，不過優點也很明顯，沒有中心節點，實現很簡單。

二、MCU (MultiPoint Control Unit)

這是一種傳統的中心化架構(上圖中間部分)，每個瀏覽器僅與中心的MCU服務器連接，MCU服務器負責所有的視頻編碼、轉碼、解碼、混合等復雜邏輯，每個瀏覽器只要1個連接，整個應用僅消耗5個連接，帶寬占用(包括上行、下行）共10M，瀏覽器端的壓力要小很多，可以支持更多的人同時音視頻通訊，比較適合多人視頻會議。但是MCU服務器的壓力較大，需要較高的配置。

三、SFU(Selective Forwarding Unit)

上圖右側部分，咋一看，跟MCU好象沒什么區別，但是思路不同，仍然有中心節點服務器，但是中心節點只負責轉發，不做太重的處理，所以服務器的壓力會低很多，配置也不像MCU要求那么高。但是每個端需要建立一個連接用于上傳自己的視頻，同時還要有N-1個連接用于下載其它參與方的視頻信息。所以總連接數為5*5，消耗的帶寬也是最大的，如果每個連接1M帶寬，總共需要25M帶寬，它的典型場景是1對N的視頻互動。

目前，隨著5G技術的推廣，可以預見帶寬越來越不是問題，所以SFU在未來，可能會更有優勢。

建議：如果規模不大(5人以下) Mesh框架就夠用了，畢竟實現簡單；如果50人以下，且帶寬有限，選擇MCU比較適合；如果規模更大，且帶寬良好，SFU相對更適合。

四、拓展

附上幾個github上比較火的webrtc MCU/SFU server項目：

https://github.com/Kurento/kurento-media-server? (kurento官網的文檔和示例很齊全，對于開發者來說，非常友好)。

https://github.com/lynckia/licode?(官網文檔很少，學習曲線略陡峭)。

https://github.com/jitsi/jitsi?(據說性能不錯，而且還提供了一個視頻會話的子項目jitsi-meet，但是文檔仍然不多，得生啃代碼）。

https://github.com/pion/webrtc/?(github上star很高，go語言開發，但目前好象尚不太成熟，文檔也不是太全，未來看好)

?

（SAW：Game Over！）

總結

以上是生活随笔為你收集整理的WebRTC / Jitsi / 多人视频通讯常用架构 Mesh / MCU / SFU的全部內容，希望文章能夠幫你解決所遇到的問題。

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