Webrtc音視訊會議之Mesh/MCU/SFU三種架構

總覽

基于Webrtc的音視訊會議方案中最常用和最基礎的架構模式是Mesh，MCU，SFU；目前市面上的各種音視訊會議都脫離不開這三種模式，當然有的是基于這三種模式的變種，又或者是這三種模式按照一定的政策進行組合，但是根基還是Mesh/MCU/SFU三種架構；

是以我們有必要詳細了解下這三種架構的思想，首先我們來看看Mesh/MCU/SFU三種架構的基礎架構圖；當然完整的生産架構肯定包含信令伺服器等等，但我們在這裡關注Webrtc音視視訊會議架構本身；列出這三種架構的優缺點，通過這種對比讓我們在音視訊會議架構設計的時候能選擇更合适的架構模式；并且讓我們對這三種架構有一個更準确的認識同時為後續為什麼我選擇SFU架構的Janus項目來研究做準備

Mesh,MCU,SFU基本架構圖：

Mesh架構

Mesh架構流量或帶寬要求比較大，Mesh架構是利用Webrtc對等連接配接，在參與會議的各方之間開辟UDP通道，也就是兩兩進行P2P連接配接，把媒體流發給參與會議的各方，同時從參與會議的其它方擷取媒體流，如上圖四個參與方，總共8個連接配接，如果每個通道占用1M帶寬，那每個端需要把自己的流發給其它三個端，也就是上行是3M帶寬，同時從其它3個端擷取流，也就是下行3M帶寬，這樣每個端上下行總共6M帶寬；

Mesh架構對端的能力要求也是比較高，畢竟參與會議的各方的媒體流的編解碼都是在端上面來處理的，圖上面的4個參與會議方，那每個端的處理量就是4；結合上面可以看出Mesh一個端能承受的同時開視訊的人員更少

Mesh架構不利于媒體的集中處理；例如媒體的錄制，你如果不覺得帶寬或者流量是問題，再從端上傳一份媒體到存儲伺服器那又另當别論；又或者小哥哥小姐姐直播了一些不該直播的無法進行識别或處理了；再者內建我大訊飛的翻譯咋辦？不能沒有我大訊飛的翻譯啊，當然端上做也是可以的，但是畢竟端上算力是有限的；

但是Mesh實作起來技術難度是最小的，實作起來最簡單；Mesh架構對伺服器資源占用是最小的，隻需要一個ICE伺服器用來實作P2P穿越就行了，Mesh架構是真正的去中心化，對伺服器資源占用是最小的，還有可以充分的利用了端上的算力，邊緣計算的時代已經來了，節省不少成本；

MCU架構(MultiPoint Control Unit)

MCU架構對伺服器端壓力比較大，MCU架構需要一個中心化的MCU伺服器，編碼、轉碼、解碼、混合都在伺服器端做；

如上圖MCU架構下的參會的4個端把自己的媒體流上繳到MCU伺服器，然後MCU伺服器對4個媒體流解碼後進行合并，4個流合并成一個媒體流，再發給4個參會人員；是以伺服器的壓力特别大；是以單台伺服器能承受的參會人員特别少，當然一些财大氣粗的企業可以加伺服器，加進階的GPU

MCU端上各種控制更加複雜 ，現在我和漂亮小姐姐聊天，小姐姐是我日思夜想的，我現在想把她的畫面調大，這個實作起來就很麻煩了，因為下發的媒體流是合并的，也就是一個視訊流；當然不是不可實作，通過信令伺服器下發一個重新合屏的信令我們還是可以看到清晰的小姐姐的畫面的；隻是相對來講實作更麻煩；

又比如我希望參會的小姐姐們看到群裡最靓的我，那我對我自己上濾鏡美白那可就麻煩了

MCU架構占用帶寬最小，從前面的描述和從上圖中我們可以看到4個參會人員每個人上交一份媒體流如果還是按照1M來算，那上行每個端1M，同時從伺服器端擷取一份混合過的媒體流還是按照1M算，那每個端上下行總共就是2M；結合上面所述MCU架構

一個端同時能承受更多的人開啟視訊

SFU架構(Selective Forwarding Unit)

SFU架構服務端壓力相對較小，SFU架構看似和MCU一樣都有一個中心化的伺服器，但是SFU的伺服器隻負責轉發媒體或者存儲媒體；不直接做編碼、轉碼、解碼、混合這些算力要求較高的工作；SFU伺服器接到RTP包後直接轉發；

SFU架構占用帶寬适中，例如上圖，SUF架構參與會議的4個端每個端首先要把自己的流發給伺服器，是以每個端上行1M帶寬，同時從伺服器擷取轉發過來的其它3個參會人員的媒體流也就是下行3M，這樣每個端上下行加一起就是4M；是以它占用端上的帶寬在Mesh架構和SFU之間；這種适中的帶寬占用在即将到來的5G時代你可以想象！！！！

SFU架構對端和媒體流的控制更簡單，還是上面的場景，我想仔細端詳日思夜想的小姐姐将她的畫面調大，隻需要在端上直接放大就行了；另外整個會議中隻讓我成為最靓的仔，進行美顔啥的實作起來也不算是啥問題了，雖然對端的要求高，但是現在手機或者電腦算力過剩啊，邊緣計算發揮到極緻，哈哈……，為企業省錢；

總結

網際網路時代要求更個性化的體驗（美顔，更個性化的控制等等），更大的容積率（也就是更多的使用者同時線上）；總的來說SFU架構更适合網際網路時代；ZOOM會議和騰訊會議這兩個比較出名的網際網路會議系統都是SFU架構；是以跟風一波後續深入的研究SFU架構；

雖然SUF架構對端的算力要求比較高，更多的計算放到了端上，不過在視訊會議或者直播的場景下面，跟多的是一個大畫面，其它若幹個小畫面，而且通過互動控制，例如：同時隻顯示若幹個小畫面，滾動的時候動态的再擷取其它的參會人員的視訊生成小畫面；

SFU隻負責轉發流，是以更高的并發，同時它邏輯簡單，更容易的建構高負載架構

引用文章請标明出處，否則可以保留一切追究責任的權利

技術交流：

qq：408365330

微信：egojit