1. Mesh(P2P)

簡介

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

缺點

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

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

優點

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

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

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

2. MCU(Multi-point Control Unit)

簡介

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

缺點

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

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

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

優點

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

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

3. SFU(Selective Forwarding Unit)

簡介

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

缺點

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

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

優點

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

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

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

結論

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

作者介紹

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