WebRTC多人視頻通訊常用的架構Mesh、MCU、SFU

Mesh方案

即多個終端之間兩兩進行連接，形成一個網狀結構。比如 A、B、C 三個終端進行多對多通信，當 A 想要共享媒體（比如音頻、視頻）時，它需要分別向 B 和 C 發送數據。同樣的道理，B 想要共享媒體，就需要分別向 A、C 發送數據，依次類推。這種方案對各終端的帶寬要求比較高。

當某個瀏覽器想要共享它的音視頻流時，它會將共享的媒體流分別發送給其他 3 個瀏覽器，這樣就實現了多人通信。這種結構的優勢有如下：

• 不需要服務器中轉數據，STUN/TUTN 只是負責 NAT 穿越，這樣利用現有 WebRTC 通信模型就可以實現，而不需要開發媒體服務器。
• 充分利用了客戶端的帶寬資源。
• 節省了服務器資源，由於服務器帶寬往往是專線，價格昂貴，這種方案可以很好地控製成本。

劣勢：

• 共享端共享媒體流的時候，需要給每一個參與人都轉發一份媒體流，這樣對上行帶寬的佔用很大。參與人越多，佔用的帶寬就越大。除此之外，對 CPU、Memory 等資源也是極大的考驗。一般來說，客戶端的機器資源、帶寬資源往往是有限的，資源佔用和參與人數是線性相關的。這樣導致多人通信的規模非常有限，通過實踐來看，這種方案在超過 4 個人時，就會有非常大的問題。
• 另一方面，在多人通信時，如果有部分人不能實現 NAT 穿越，但還想讓這些人與其他人互通，就顯得很麻煩，需要做出更多的可靠性設計。

MCU 方案(MultiPoint Control Unit)

MCU 主要的處理邏輯是：接收每個共享端的音視頻流，經過解碼、與其他解碼後的音視頻進行混流、重新編碼，之後再將混好的音視頻流發送給房間裡的所有人。

MCU 技術在視頻會議領域出現得非常早，目前技術也非常成熟，主要用在硬件視頻會議領域。不過我們今天討論的是軟件 MCU，它與硬件 MCU 的模型是一致的，只不過一個是通過硬件實現的，另一個是通過軟件實現的罷了。 MCU 方案的模型是一個星形結構，如下圖所示：

我們來假設一個條件，B1 與B2 同時共享音視頻流，它們首先將流推送給MCU 服務器，MCU 服務器收到兩路流後，分別將兩路流進行解碼，之後將解碼後的兩路流進行混流，然後再編碼，編碼後的流數據再分發給B3 和B4。

對於 B1 來說，因為它是其中的一個共享者，所以 MCU 給它推的是沒有混合它的共享流的媒體流，在這個例子中就是直接推 B2 的流給它。同理，對於 B2 來說 MCU 給它發的是 B1 的共享流。但如果有更多的人共享音視頻流，那情況就更加複雜。

MCU 主要的處理邏輯如下圖所示：

• 接收共享端發送的音視頻流。
• 將接收到的音視頻流進行解碼。
• 對於視頻流，要進行重新佈局，混合處理。
• 對於音頻流，要進行混音、重採樣處理。
• 將混合後的音視頻進行重新編碼。
• 發送給接收客戶端。

優點

• 技術非常成熟，在硬件視頻會議中應用非常廣泛
• 作為音視頻網關，通過解碼、再編碼可以屏蔽不同編解碼設備的差異化，滿足更多客戶的集成需求，提升用戶體驗和產品競爭力。
• 將多路視頻混合成一路，所有參與人看到的是相同的畫面，客戶體驗非常好。

缺點

• 重新解碼、編碼、混流，需要大量的運算，對 CPU 資源的消耗很大。
• 重新解碼、編碼、混流還會帶來延遲。
• MCU服務器的壓力較大，需要較高的配置。

SFU(Selective Forwarding Unit)

SFU 像是一個媒體流路由器，接收終端的音視頻流，根據需要轉發給其他終端。 SFU 在音視頻會議中應用非常廣泛，尤其是 WebRTC 普及以後。支持 WebRTC 多方通信的媒體服務器基本都是 SFU 結構。 SFU 的拓撲機構和功能模型如下圖：

在上圖中，B1、B2、B3、B4 分別代表 4 個瀏覽器，每一個瀏覽器都會共享一路流發給 SFU，SFU 會將每一路流轉發給共享者之外的 3 個瀏覽器。

下面這張圖是從 SFU 服務器的角度展示的功能示意圖：

相比 MCU，SFU 在結構上顯得簡單很多，只是接收流然後轉發給其他人。然而，這個簡單結構也給音視頻傳輸帶來了很多便利。比如，SFU 可以根據終端下行網絡狀況做一些流控，可以根據當前帶寬情況、網絡延時情況，選擇性地丟棄一些媒體數據，保證通信的連續性。

目前許多 SFU 實現都支持 SVC 模式和 Simulcast 模式，用於適配 WiFi、4G 等不同網絡狀況，以及 Phone、Pad、PC 等不同終端設備。

優點

• 由於是數據包直接轉發，不需要編碼、解碼，對 CPU 資源消耗很小
• 直接轉發也極大地降低了延遲，提高了實時性。
• 帶來了很大的靈活性，能夠更好地適應不同的網絡狀況和終端類型。

缺點

• 由於是數據包直接轉發，參與人觀看多路視頻的時候可能會出現不同步；相同的視頻流，不同的參與人看到的畫面也可能不一致。
• 參與人同時觀看多路視頻，在多路視頻窗口顯示、渲染等會帶來很多麻煩，尤其對多人實時通信進行錄製，多路流也會帶來很多回放的困難。總之，整體在通用性、一致性方面比較差。
• 每個端需要建立一個連接用於上傳自己的視頻，同時還要有N-1個連接用於下載其它參與方的視頻信息，消耗的帶寬也是最大的(帶寬比較燒錢)

通過上面的分析和比較，相信你已經有了一個大概的認知。如何選擇架構方案還需要根據業務場景來判斷，沒有最好的是只有最適合的。

1.Simulcast 模式

所謂 Simulcast 模式就是指視頻的共享者可以同時向 SFU 發送多路不同分辨率的視頻流（一般為三路，如 1080P、720P、360P）。而 SFU 可以將接收到的三路流根據各終端的情況而選擇其中某一路發送出去。例如，由於 PC 端網絡特別好，給 PC 端發送 1080P 分辨率的視頻；而移動網絡較差，就給 Phone 發送 360P 分辨率的視頻。

Simulcast 模式對移動端的終端類型非常有用，它可以靈活而又智能地適應不同的網絡環境。下圖就是 Simulcast 模式的示意圖：

2. SVC 模式

SVC 是可伸縮的視頻編碼模式。與 Simulcast 模式的同時傳多路流不同，SVC 模式是在視頻編碼時做“手腳”。

它在視頻編碼時將視頻分成多層——核心層、中間層和擴展層。上層依賴於底層，而且越上層越清晰，越底層越模糊。在帶寬不好的情況下，可以只傳輸底層，即核心層，在帶寬充足的情況下，可以將三層全部傳輸過去。

同一路流，分成了多具層，核心層，護展層和邊緣層，當帶寬不足時，由上層逐漸丟棄！

如下圖所示，PC1 共享的是一路視頻流，編碼使用 SVC 分為三層發送給 SFU。 SFU 根據接收端的情況，發現 PC2 網絡狀況不錯，於是將 0、1、2 三層都發給 PC2；發現 Phone 網絡不好，則只將 0 層發給 Phone。這樣就可以適應不同的網絡環境和終端類型了。

總結

• 由於各方面限制，Mesh 架構在真實的應用場景中幾乎沒有人使用，一般剛學習 WebRTC 的才會考慮使用這種架構來實現多方通信。 （可以簡單了解下）
• MCU 架構是非常成熟的技術，在硬件視頻會議中應用非常廣泛。像很多做音視頻會議的公司之前都會購買一套MCU 設備，這樣一套設備價格不菲，最低都要50 萬，但隨著互聯網的發展以及音視頻技術越來越成熟，硬件MCU 已經逐步被淘汰，當然現在也還有公司在使用軟MCU，比較有名的開源項目是FreeSWITCH。
• SFU 是最近幾年流行的新架構，目前 WebRTC 多方通信媒體服務器都是 SFU 架構。從上面的介紹中你也可以了解到 SFU 這種架構非常靈活，性能也非常高，再配上視頻的 Simulcast 模式或 SVC 模式，則使它更加如虎添翼，因此SFU模式已經漸漸成為主流了。
• 目前的實際應用中，使用Simulcast比使用SVC多，webRTC對兩種都支持