WebRTC 實戰 (9) —— 多人通訊架構：Mesh, MCU 與 SFU
到目前為止，我們討論的都是一對一通訊。多人房間不能只看「能否連線」，還要同時計算每位使用者的上傳、下載、編碼負載，以及伺服器的 CPU 與出口流量。
一、 三大架構圖解
1. Mesh (P2P 全連接)
每個人都與所有人連線。
- 優點：成本最低，延遲最低。
- 缺點：每位使用者要上傳約
N - 1份媒體，還可能同時執行多次編碼。可承受人數取決於解析度、裝置與網路，不能用固定人數一刀切。
2. MCU (多點控制單元)
伺服器將所有人畫面「混成一張大圖」再發送。
- 優點：使用者壓力最小（一傳一收）。
- 缺點：伺服器需要解碼、混合再編碼，CPU 成本高。接收端通常只能取得混合後畫面，個別調整參與者版面與音量的彈性較低。
3. SFU (選擇性轉發單元)
伺服器只負責轉發封包，不解碼。
- 優點：伺服器主要選擇並轉發 RTP，不必混合所有媒體。搭配 Simulcast 或 SVC，可依接收端頻寬選擇不同品質層。
- 缺點：每位使用者仍需下載多條媒體，伺服器出口流量、訂閱管理與壅塞控制更複雜。
二、 三種架構大比拼
| 特性 | Mesh (P2P) | MCU | SFU (主流) |
|---|---|---|---|
| 伺服器媒體成本 | 無或 TURN | 高 CPU | 高出口流量 |
| 使用者上傳 | 約 N - 1 份 | 1 份 | 通常 1 組 Simulcast/SVC |
| 使用者下載 | 約 N - 1 份 | 1 份混合流 | 依訂閱數量而定 |
| 版面彈性 | 高 | 低 | 高 |
| 典型場景 | 小型通話、區域網路 | 固定合成、傳統設備整合 | 視訊會議、互動直播 |
三、 SFU 為何需要 Simulcast 或 SVC
如果所有人只上傳一條 1080p 串流，SFU 無法憑空替低頻寬接收者產生 180p 版本。常見做法有：
- Simulcast：瀏覽器同時編碼多個解析度或碼率層，SFU 選擇其中一層轉發。
- SVC：單一編碼串流包含空間層或時間層，SFU 依能力選擇可轉發的層。
兩者都會增加發送端或伺服器的工程複雜度，但它們是多人會議適應不同網路品質的關鍵。
四、 不要用固定人數選架構
「四人以下一定用 Mesh」只能作為非常粗略的起點。還要評估：
- 是否需要伺服器錄影、轉錄、審核或直播分發。
- 行動裝置是否能承受多路編碼與解碼。
- 企業網路是否經常需要 TURN。
- 是否需要快速切換發言者、畫質層或訂閱策略。
- 是否需要統一觀測、故障轉移與容量控制。
總結
Mesh 適合需求單純、參與者少且裝置能力可控的場景；MCU 適合需要固定合成輸出的系統；SFU 則是現代多人互動影音最常見的架構。最終選擇仍應由容量測試與產品需求決定。
下一章，我們將正式邁向 SFU 的核心：探索業界頂尖框架 Mediasoup 與 Janus。
進階挑戰
為什麼現在的會議軟體（如 Google Meet）即使在只有 2 個人的時候，有時也會強迫你經過 SFU 伺服器而不使用 Mesh？（提示：想想看錄影、穩定性與切換網路的流暢度。）
延伸閱讀與資源
- mediasoup Guide: Scalability
- WebRTC.org: Connectivity Topologies