問題：為什么要搞這么多架構(gòu)？

WebRTC 雖然是一項(xiàng)主要使用 P2P 的實(shí)時(shí)通訊技術(shù)，本應(yīng)該是無中心化節(jié)點(diǎn)的，但是在一些大型多人通訊場(chǎng)景，如果都使用端對(duì)端直連，端上會(huì)遇到很帶寬和性能的問題，所以就有了下圖的三種架構(gòu)。

一、Mesh

每個(gè)端都與其它端互連。

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

二、MCU (MultiPoint Control Unit)

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

三、SFU(Selective Forwarding Unit)

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

目前，隨著5G技術(shù)的推廣，可以預(yù)見帶寬越來越不是問題，所以SFU在未來，可能會(huì)更有優(yōu)勢(shì)。

建議：如果規(guī)模不大(5人以下) Mesh框架就夠用了，畢竟實(shí)現(xiàn)簡(jiǎn)單；如果50人以下，且?guī)捰邢?#xff0c;選擇MCU比較適合；如果規(guī)模更大，且?guī)捔己?#xff0c;SFU相對(duì)更適合。

四、拓展

附上幾個(gè)github上比較火的webrtc MCU/SFU server項(xiàng)目：

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

https://github.com/lynckia/licode?(官網(wǎng)文檔很少，學(xué)習(xí)曲線略陡峭)。

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

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

?

（SAW：Game Over！）

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。