WEBRTC三種類型（Mesh、MCU 和 SFU）的多方通信架構
WebRTC 本身提供的是 1 對 1 的通信模型，在 STUN/TURN 的輔助下，如果能實現 NAT 穿越，那麼兩個瀏覽器是可以直接進行媒體數據交換的；如果不能實現 NAT 穿越，那麼只能通過 TURN 服務器進行數據轉發的方式實現通信。目前來看，Google 開源的用於學習和研究的項目基本都是基於 STUN/TURN 的 1 對 1 通信。
如果你想要通過 WebRTC 實現多對多通信，該如何做呢？
其實，基於 WebRTC 的多對多實時通信的開源項目也有很多，綜合來看，多方通信架構無外乎以下三種方案。
- Mesh 方案，即多個終端之間兩兩進行連接，形成一個網狀結構。比如 A、B、C 三個終端進行多對多通信，當 A 想要共享媒體（比如音頻、視頻）時，它需要分別向 B 和 C 發送數據。同樣的道理，B 想要共享媒體，就需要分別向 A、C 發送數據，依次類推。這種方案對各終端的帶寬要求比較高。
- MCU（Multipoint Conferencing Unit）方案，該方案由一個服務器和多個終端組成一個星形結構。各終端將自己要共享的音視頻流發送給服務器，服務器端會將在同一個房間中的所有終端的音視頻流進行混合，最終生成一個混合後的音視頻流再發給各個終端，這樣各終端就可以看到 / 聽到其他終端的音視頻了。實際上服務器端就是一個音視頻混合器，這種方案服務器的壓力會非常大。
- SFU（Selective Forwarding Unit）方案，該方案也是由一個服務器和多個終端組成，但與 MCU 不同的是，SFU 不對音視頻進行混流，收到某個終端共享的音視頻流後，就直接將該音視頻流轉發給房間內的其他終端。它實際上就是一個音視頻路由轉發器。
瞭解了上面幾種通信架構後，接下來，我們分別論述一下這幾種架構。
1 對 1 通信
在多對多架構模型之前，咱們得先回顧一下 WebRTC 1 對 1 通信的模型，因爲只有在 1 對 1 通信模型非常清楚的情況下，我們才能知道多對多通信模型的複雜度到底體現在哪兒。
在 1 對 1 通信中，WebRTC 首先嚐試兩個終端之間是否可以通過 P2P 直接進行通信，如果無法直接通信的話，則會通過 STUN/TURN 服務器進行中轉，如下圖：
WebRTC 1 對 1 音視頻實時通話示意圖
目前咱對上圖已經非常熟悉了。實際上，1 對 1 通信模型設計的主要目標是儘量讓兩個終端進行直聯，這樣即可以節省服務器的資源，又可以提高音視頻的服務質量。
如果端與端之間可以直接通信，那麼上圖中的 STUN/TURN 服務器的作用就只是用於各終端收集 reflx 類型的 Candidate 。而如果端與端之間無法直接進行通信的話，那麼 STUN/TURN 服務器就變成了中繼服務器，可以利用它進行端與端之間數據的中轉。
Mesh 方案
1 對 1 通信模型下，兩個終端可以互相連接，那麼我們是否可以讓多個終端互相連接起來，從而實現多人通信呢？
理論上這是完全可行的。Mesh 方案的結構如下圖所示：
Mesh 方案架構圖
在上圖中，B1、B2、B3、B4 分別表示 4 個瀏覽器，它們之間兩兩相連，同時還分別與 STUN/TURN 服務器進行連接（此時的 STUN/TURN 服務器不能進行數據中轉，否則情況會變得非常複雜），這樣就形成了一個網格拓撲結構。
當某個瀏覽器想要共享它的音視頻流時，它會將共享的媒體流分別發送給其他 3 個瀏覽器，這樣就實現了多人通信。
這種結構的優勢有：
- 不需要服務器中轉數據，STUN/TUTN 只是負責 NAT 穿越，這樣利用現有 WebRTC 通信模型就可以實現，而不需要開發媒體服務器。
- 充分利用了客戶端的帶寬資源。
- 節省了服務器資源，因爲服務器帶寬往往是專線，價格昂貴，所以這種方案可以很好地控制成本。
當然，有優勢自然也有不足之處，主要表現在：
- 共享端共享媒體流的時候，需要給每一個參與人都轉發一份媒體流，這樣對上行帶寬的佔用很大。參與人越多，佔用的帶寬就越大。除此之外，對 CPU、Memory 等資源也是極大的考驗。一般來說，客戶端的機器資源、帶寬資源往往是有限的，資源佔用和參與人數是線性相關的。這樣導致多人通信的規模非常有限，通過實踐來看，這種方案在超過 4 個人時，就會有非常大的問題。
- 另一方面，在多人通信時，如果有部分人不能實現 NAT 穿越，但還想讓這些人與其他人互通，就顯得很麻煩，需要做出更多的可靠性設計。
MCU 方案
MCU 主要的處理邏輯是：接收每個共享端的音視頻流，經過解碼、與其他解碼後的音視頻進行混流、重新編碼，之後再將混好的音視頻流發送給房間裏的所有人。
MCU 技術在視頻會議領域出現得非常早，目前技術也非常成熟，主要用在硬件視頻會議領域。不過我們今天討論的是軟件 MCU，它與硬件 MCU 的模型是一致的，只不過一個是通過硬件實現的，另一個是通過軟件實現的罷了。MCU 方案的模型是一個星形結構，如下圖所示：
MCU 方案架構圖
我們來假設一個條件，B1 與 B2 同時共享音視頻流，它們首先將流推送給 MCU 服務器，MCU 服務器收到兩路流後，分別將兩路流進行解碼，之後將解碼後的兩路流進行混流，然後再編碼，編碼後的流數據再分發給 B3 和 B4。
對於 B1 來說，因爲它是其中的一個共享者，所以 MCU 給它推的是沒有混合它的共享流的媒體流，在這個例子中就是直接推 B2 的流給它。同理，對於 B2 來說 MCU 給它發的是 B1 的共享流。但如果有更多的人共享音視頻流，那情況就更加複雜。
MCU 主要的處理邏輯如下：
那 MCU 的優勢有哪些呢？大致可總結爲如下幾點：
- 技術非常成熟，在硬件視頻會議中應用非常廣泛。
- 作爲音視頻網關，通過解碼、再編碼可以屏蔽不同編解碼設備的差異化，滿足更多客戶的集成需求，提升用戶體驗和產品競爭力。
- 將多路視頻混合成一路，所有參與人看到的是相同的畫面，客戶體驗非常好。
同樣，MCU 也有一些不足，主要表現爲：
- 重新解碼、編碼、混流，需要大量的運算，對 CPU 資源的消耗很大。
- 重新解碼、編碼、混流還會帶來延遲。
- 由於機器資源耗費很大，所以 MCU 所提供的容量有限，一般十幾路視頻就是上限了。
SFU 方案
SFU 像是一個媒體流路由器，接收終端的音視頻流，根據需要轉發給其他終端。SFU 在音視頻會議中應用非常廣泛，尤其是 WebRTC 普及以後。支持 WebRTC 多方通信的媒體服務器基本都是 SFU 結構。SFU 的拓撲機構和功能模型如下圖：
SFU 方案架構圖
在這個圖中，B1、B2、B3、B4 分別代表 4 個瀏覽器，每一個瀏覽器都會共享一路流發給 SFU，SFU 會將每一路流轉發給共享者之外的 3 個瀏覽器。
下面這張圖是從 SFU 服務器的角度展示的功能示意圖：
SFU 功能示意圖
相比 MCU，SFU 在結構上顯得簡單很多，只是接收流然後轉發給其他人。然而，這個簡單結構也給音視頻傳輸帶來了很多便利。比如，SFU 可以根據終端下行網絡狀況做一些流控，可以根據當前帶寬情況、網絡延時情況，選擇性地丟棄一些媒體數據，保證通信的連續性。
目前許多 SFU 實現都支持 SVC 模式和 Simulcast 模式，用於適配 WiFi、4G 等不同網絡狀況，以及 Phone、Pad、PC 等不同終端設備。
SFU 的優勢有哪些呢？：
- 首先 由於是數據包直接轉發，不需要編碼、解碼，對 CPU 資源消耗很小。
- 其次是 直接轉發也極大地降低了延遲，提高了實時性。
- 最後 帶來了很大的靈活性，能夠更好地適應不同的網絡狀況和終端類型。
同樣，SFU 有優勢，也有不足，主要表現是：
由於是數據包直接轉發，參與人觀看多路視頻的時候可能會出現不同步；相同的視頻流，不同的參與人看到的畫面也可能不一致。
參與人同時觀看多路視頻，在多路視頻窗口顯示、渲染等會帶來很多麻煩，尤其對多人實時通信進行錄製，多路流也會帶來很多回放的困難。總之，整體在通用性、一致性方面比較差。
通過上面的分析和比較，綜合它們各自的優劣情況，我們可以得出 ，SFU 是三種架構方案中優勢最明顯而劣勢又相對較少的一種架構方案。
無論是從靈活性上，還是音視頻的服務質量、負載情況等方面上，相較其他兩種方案，SFU 都有明顯的優勢，因此這種方案也被大多數廠商廣泛採用。
另外，在上面介紹 SFU 方案時，我們還提到了視頻的 Simulcast 模式和 SVC 模式，他們是什麼呢，又對 SFU 架構來說都帶來了哪些好處呢。
1. Simulcast 模式
所謂 Simulcast 模式就是指視頻的共享者可以同時向 SFU 發送多路不同分辨率的視頻流（一般爲三路，如 1080P、720P、360P）。而 SFU 可以將接收到的三路流根據各終端的情況而選擇其中某一路發送出去。例如，由於 PC 端網絡特別好，給 PC 端發送 1080P 分辨率的視頻；而移動網絡較差，就給 Phone 發送 360P 分辨率的視頻。
Simulcast 模式對移動端的終端類型非常有用，它可以靈活而又智能地適應不同的網絡環境。下圖就是 Simulcast 模式的示意圖：
Simulcast 模式示意圖
2. SVC 模式
SVC 是可伸縮的視頻編碼模式。與 Simulcast 模式的同時傳多路流不同，SVC 模式是在視頻編碼時做“手腳”。
它在視頻編碼時將視頻分成多層——核心層、中間層和擴展層。上層依賴於底層，而且越上層越清晰，越底層越模糊。在帶寬不好的情況下，可以只傳輸底層，即核心層，在帶寬充足的情況下，可以將三層全部傳輸過去。
如下圖所示，PC1 共享的是一路視頻流，編碼使用 SVC 分爲三層發送給 SFU。SFU 根據接收端的情況，發現 PC2 網絡狀況不錯，於是將 0、1、2 三層都發給 PC2；發現 Phone 網絡不好，則只將 0 層發給 Phone。這樣就可以適應不同的網絡環境和終端類型了。
SVC 模式示意圖
小結
以上我主要和大家分享了三種多方通信的架構，分別是 Mesh、MCU 和 SFU。
整體來看，由於各方面限制，Mesh 架構在真實的應用場景中幾乎沒有人使用，一般剛學習 WebRTC 會考慮使用這種架構來實現多方通信。
MCU 架構是非常成熟的技術，在硬件視頻會議中應用非常廣泛。像很多做音視頻會議的公司之前都會購買一套 MCU 設備，這樣一套設備價格不菲，最低都要 50 萬，但隨着互聯網的發展以及音視頻技術越來越成熟，硬件 MCU 已經逐步被淘汰。
當然現在也還有公司在使用軟 MCU，比較有名的項目是 FreeSWITCH，但正如我們前面所分析的那樣，由於 MCU 要進行解碼、混流、重新編碼的操作，這些操作對 CPU 消耗是巨大的。如果用硬件 MCU 還好，但軟 MCU 這個劣勢就很明顯了，所以真正使用軟 MCU 架構方案的公司也不多。
SFU 是最近幾年流行的新架構，目前 WebRTC 多方通信媒體服務器都是 SFU 架構。從上面的介紹中你也可以瞭解到 SFU 這種架構非常靈活，性能也非常高，再配上視頻的 Simulcast 模式或 SVC 模式，則使它更加如虎添翼，因此各個公司目前基本上都使用該方案。
然後我們目前的階段性目標就是先實現Mesh方案，再逐步深入。
內容來源：https://note.youdao.com/ynoteshare1/index.html?id=6f4db3ceb82d84006567f5008542e694&type=note