1. Mesh(P2P)

簡(jiǎn)介

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

缺點(diǎn)

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

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

優(yōu)點(diǎn)

a. 對(duì)服務(wù)器資源占用最小。這一點(diǎn)也非常好理解，因?yàn)閴焊鶅壕蜎](méi)有用到流媒體服務(wù)器，只需要一個(gè) ICE 穿透服務(wù)器就可以滿足 P2P 打洞從而建立連接。

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

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

2. MCU(Multi-point Control Unit)

簡(jiǎn)介

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

缺點(diǎn)

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

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

c. 成本最高。如果資金允許的話，還是應(yīng)該考慮引入高級(jí)的 GPU 加速服務(wù)器，用來(lái)提高流媒體服務(wù)器的混流能力。但是，成本也會(huì)相應(yīng)提高。

優(yōu)點(diǎn)

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

b. 客戶端解碼壓力小。因?yàn)槊總€(gè)參會(huì)的客戶端都只需要解碼一路媒體流，就可以代替分別解碼每個(gè)參會(huì)者媒體流的情況，而另外兩種服務(wù)架構(gòu)都需要單獨(dú)解碼其他參會(huì)者的媒體流。

3. SFU(Selective Forwarding Unit)

簡(jiǎn)介

SFU 是解決服務(wù)器性能問(wèn)題最有吸引力的方法，因?yàn)樗簧婕耙曨l解碼和編碼的計(jì)算費(fèi)用，它以最低的開(kāi)銷(xiāo)來(lái)轉(zhuǎn)發(fā)各路媒體流，典型的應(yīng)用場(chǎng)景是1對(duì)多的直播服務(wù)。這種架構(gòu)適用于大多數(shù)的情況，人數(shù)中等的場(chǎng)景，比如大班課，多人語(yǔ)音通話等。

缺點(diǎn)

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

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

優(yōu)點(diǎn)

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

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

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

結(jié)論

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

作者介紹

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