[TOC] 參考：[https://blog.csdn.net/qlshouyu/article/details/106733653](https://blog.csdn.net/qlshouyu/article/details/106733653) ## 圖解  ## 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只負責轉發流，所以更高的并發，同時它邏輯簡單，更容易的構建高負載架構