問題：為什么要搞這么多架構？
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相對更適合。
附上幾個github上比較火的webrtc MCU/SFU server項目：
https://github.com/Kurento/kurento-media-server (kurento官網的文檔和示例很齊全，對於開發者來說，非常友好)
https://github.com/lynckia/licode (官網文檔很少，學習曲線略陡峭)
https://github.com/jitsi/jitsi (據說性能不錯，而且還提供了一個視頻會話的子項目jitsi-meet，但是文檔仍然不多，得生啃代碼）
https://github.com/pion/webrtc/ (github上star很高，go語言開發，但目前好象尚不太成熟，文檔也不是太全，未來看好)
參考文章：
https://webrtcglossary.com/mcu/
https://antmedia.io/webrtc-servers/
https://www.html5rocks.com/en/tutorials/webrtc/basics/
https://webrtcglossary.com/sfu/
https://www.jianshu.com/p/ac307371def4 (寫得不錯的一篇關於webrtc的架構文章)