1. Mesh(P2P)

簡介

Mesh 服務器架構(gòu)其實就是標準 P2P 通訊模式的混用，每一個 P2P 連接有獨立的傳輸策略控制，通訊質(zhì)量有一定的保障。但是，這種架構(gòu)對于客戶端系統(tǒng)是一種浪費，一方面需要分配更多的端口，消耗更多的系統(tǒng)資源;另一方面，由于要向其它三個客戶端發(fā)送本地音視頻數(shù)據(jù)，增加了上行網(wǎng)絡帶寬的消耗，在同等帶寬條件下，支持的多人通話路數(shù)就相對有限，視頻質(zhì)量(碼率)也比較低。這種架構(gòu)比較適合網(wǎng)絡狀況較好，人數(shù)較少，比如一對一的場景中。

缺點

a. 占用大量帶寬。以上圖為例，假設所有上下行媒體流占用帶寬都是 1MB，那么，每個客戶端需要提供 3MB 的上行帶寬和 3MB 的下行帶寬，每個客戶端總體消耗的帶寬是 6MB。如果復用 PeerConnection 通道的話，也需要建立六條鏈路。

b. 占用客戶端資源。如上圖所示，每個客戶端在通訊過程中需要同時編碼三路媒體流，分別發(fā)送給另外三個參會者，而不是共用一路編碼媒體流。因此，會占用比較多的客戶端資源。

優(yōu)點

a. 對服務器資源占用最小。這一點也非常好理解，因為壓根兒就沒有用到流媒體服務器，只需要一個 ICE 穿透服務器就可以滿足 P2P 打洞從而建立連接。

b. 成本最低。不像其他架構(gòu)類型需要對流媒體服務器投入大量的資金和人力成本，節(jié)省了在服務器方面的絕大多數(shù)支出費用。

c. 去中心化。充分利用了客戶端的算力，在邊緣計算的大時代下，可能未來還會迎來新的機遇和挑戰(zhàn)。

2. MCU(Multi-point Control Unit)

簡介

MCU 將接收到的多路流進行轉(zhuǎn)碼和混合，并向每個終端輸出單路流的做法，節(jié)省了終端用戶的下行帶寬，并且還能夠?qū)Σ煌W(wǎng)絡條件的用戶，訂制不同碼率的輸出視頻流，讓多人場景有更好的用戶體驗。典型的應用場景是多人音視頻通話。這種架構(gòu)比較適合客戶端條件較差的場景，比如使用手機進行多人的視頻通話，由服務端來抵消移動端的資源消耗。

缺點

a. 對服務器壓力最大。MCU 服務架構(gòu)需要系統(tǒng)提供一個中心化的 MCU 混流服務器，所有媒體流的解碼、編碼、轉(zhuǎn)碼、混合都在服務器端完成。如上圖所示，四個客戶端需要把自己的媒體流推流到 MCU 服務器，然后 MCU 服務器再對這四路媒體流進行解碼、混流，最后把合并的媒體流發(fā)送給四個參會者。因此，MCU 架構(gòu)的服務器壓力非常大，也是三種服務架構(gòu)中壓力最大的。

b. 自定義布局復雜。一般情況下，MCU 服務器僅混流編碼一路合并之后的媒體流，上圖中的四個參會者接收到的混流媒體流是同一路，看到的視頻畫面也是一致的。如果某個參會者想改變視頻畫面的布局，比如放大某個人的視頻畫面，或者關(guān)閉某個人的視頻畫面，通常是無法滿足的。但是，我們也可以定義單獨的信令邏輯，請求 MCU 服務器單獨編碼一路媒體流發(fā)送給特定需求的參會者。但是，需要限制或者避免所有參會者都有類似的需求，否則 MCU 服務架構(gòu)會退化成 SFU 服務架構(gòu)。

c. 成本最高。如果資金允許的話，還是應該考慮引入高級的 GPU 加速服務器，用來提高流媒體服務器的混流能力。但是，成本也會相應提高。

優(yōu)點

a. 帶寬占用最小。還以上圖為例，假設每路媒體流所占帶寬大小為 1MB，每個客戶端總體消耗的帶寬是 2MB。如果復用 PeerConnection 通道的話，只需要建立四條鏈路。

b. 客戶端解碼壓力小。因為每個參會的客戶端都只需要解碼一路媒體流，就可以代替分別解碼每個參會者媒體流的情況，而另外兩種服務架構(gòu)都需要單獨解碼其他參會者的媒體流。

3. SFU(Selective Forwarding Unit)

簡介

SFU 是解決服務器性能問題最有吸引力的方法，因為它不涉及視頻解碼和編碼的計算費用，它以最低的開銷來轉(zhuǎn)發(fā)各路媒體流，典型的應用場景是1對多的直播服務。這種架構(gòu)適用于大多數(shù)的情況，人數(shù)中等的場景，比如大班課，多人語音通話等。

缺點

a. 客戶端解碼壓力大。這一點和 Mesh 服務架構(gòu)相似，每個客戶端需要解碼 n-1 路媒體流。如上圖所示，每個客戶端需要編碼一路媒體流同時解碼三路媒體流。

b. 服務器成本也相對較高。其實，一般情況下，SFU 架構(gòu)的服務器成本介于 Mesh 架構(gòu)和 MCU 架構(gòu)之間。但是，這也取決 SFU 服務架構(gòu)的規(guī)模和復雜程度。

優(yōu)點

a. 服務器壓力適中。盡管都需要部署流媒體服務器，但是 SFU 架構(gòu)和 MCU 架構(gòu)不一樣，它不需要對媒體流解碼再混流。SFU 的服務器只負責媒體流的轉(zhuǎn)發(fā)或者存儲，不做編碼、解碼、轉(zhuǎn)碼、混合等算力要求比較高的任務。所以，服務器端的壓力比 MCU 要低很多。

b. 帶寬占用適中。以上圖為例，依然假設每路媒體流所占帶寬為 1MB，那么每個客戶端的上行帶寬為 1MB，下行帶寬為 3MB，每個客戶端總體消耗的帶寬是 4MB。很明顯，占用帶寬(4MB)介于 Mesh 架構(gòu)(6MB)和 MCU 架構(gòu)(2MB)之間。

c. 布局控制靈活。因為每個參會者都拉取了其他參會者的媒體流，所以，每個用戶都可以動態(tài)改變自己本地的畫面布局，比如放大、縮小等。如果不希望觀看某個人的視頻畫面，還可以不訂閱這個人的媒體流。

結(jié)論

本文介紹了 Mesh、MCU、SFU 三種 WebRTC 服務架構(gòu)的基本情況，也論述了它們各自的優(yōu)缺點。盡管它們都有各種不足，但是它們對 WebRTC 實時音視頻通訊技術(shù)的發(fā)展都起到了一定的推動作用。Mesh、MCU、SFU 三種服務架構(gòu)有非常多值得我們學習和借鑒的地方?，F(xiàn)在很多先進的服務器方案不是單單使用某一種服務架構(gòu)，更多的是搭配使用。比如我們自己的 WebRTC 流媒體服務器就是使用了 MCU+SFU 的混合模式。所以說，在技術(shù)選型時沒有絕對的，我們需要根據(jù)自己具體的業(yè)務場景和技術(shù)儲備情況挑選最合適的方案。

作者介紹

劉振，51CTO社區(qū)編輯，百家云集團流媒體高級研發(fā)工程師，是一位典型的音視頻技術(shù)愛好者，前后就職于廣電巨頭和音視頻互聯(lián)網(wǎng)公司，具有豐富的音視頻直播和點播相關(guān)經(jīng)驗，對 WebRTC、FFmpeg 和 Electron 有非常深入的了解。