視訊RTC通信常采用的幾種架構方式及其應用場景：MCU/SFU、視訊會議、應急指揮、即時通信

我們這裡常說的RTC可以了解為WebRTC技術，因為WebRTC技術是目前使用最廣泛的即時通信技術，雖然在早期我們提到WebRTC、提到視訊通話就會想到P2P的方式，但實際的視訊通話方式背後的邏輯有很多種，p2p并不能解決所有的網絡通信問題，視訊通話會采用多種架構相結合的方式，保障使用者視訊通話的接通率。

WebRTC雖然是一項主要使用p2p的實時通訊技術，本應該是無中心化節點的，但是在一些大型多人通訊場景，如果都使用端對端直連，端上會遇到很帶寬和性能的問題，是以就有了下圖的三種架構。

一、Mesh架構

即：每個端都與其它端互連。以上圖最左側為例，5個浏覽器，二二建立p2p連接配接，每個浏覽器與其它4個建立連接配接，總共需要10個連接配接。如果每條連接配接占用1m帶寬，則每個端上行需要4m，下行帶寬也要4m，總共帶寬消耗20m。而且除了帶寬問題，每個浏覽器上還要有音視訊“編碼/解碼”，cpu使用率也是問題，一般這種架構隻能支援4-6人左右，不過優點也很明顯，沒有中心節點，實作很簡單。

二、MCU (MultiPoint Control Unit)

這是一種傳統的中心化架構(上圖中間部分)，每個浏覽器僅與中心的MCU伺服器連接配接，MCU伺服器負責所有的視訊編碼、轉碼、解碼、混合等複雜邏輯，每個浏覽器隻要1個連接配接，整個應用僅消耗5個連接配接，帶寬占用(包括上行、下行）共10m，浏覽器端的壓力要小很多，可以支援更多的人同時音視訊通訊，比較适合多人視訊會議。但是MCU伺服器的壓力較大，需要較高的配置。

三、SFU(Selective Forwarding Unit)

上圖右側部分，咋一看，跟MCU好象沒什麼差別，但是思路不同，仍然有中心節點伺服器，但是中心節點隻負責轉發，不做太重的處理，是以伺服器的壓力會低很多，配置也不象MUC要求那麼高。但是每個端需要建立一個連接配接用于上傳自己的視訊，同時還要有N-1個連接配接用于下載下傳其它參與方的視訊資訊。是以總連接配接數為5*5，消耗的帶寬也是最大的，如果每個連接配接1M帶寬，總共需要25M帶寬，它的典型場景是1對N的視訊互動。

目前，随着5G技術的推廣，可以預見帶寬越來越不是問題，是以SFU在未來，可能會更有優勢。

建議：如果規模不大(5人以下) Mesh架構就夠用了，畢竟實作簡單；如果50人以下，且帶寬有限，選擇MCU比較适合；如果規模更大，且帶寬良好，SFU相對更适合。

在TSINGSEE視訊裡面，我們也在不斷對MCU、SFU的使用場景進行研究和拓展，在許多的應急指揮場景中，我們不僅需要即時的通信，而且需要事後的回溯，是以MCU的錄像功能是必不可少的，而當我們在人數衆多的叢集排程和大班課教學時，我們又需要對感興趣的視訊源選擇接聽，而對大部分的非相關人員視訊屏蔽，在多方連線場景中，我們需要選擇性看清楚現場情況，放大單路視訊，是以這些情況，MCU和SFU的選擇不是絕對的，而将會是互相結合的；

在WebRTC方面，我們已經逐漸拓展了EasyRTC視訊會議與EasyRTS應急指揮系統，EasyRTC具有MCU和SFU兩個版本，EasyRTS則采用SFU接入與後端視訊處理的方式，完美地解決了視訊即時通信的各種應用場景需求。

視訊相關的解決方案都可以到TSINGSEE視訊檢視一下系統效果：www.tsingsee.com