WebRTC 實戰 (10) —— 邁向 SFU：Mediasoup 與 Janus 的探索
第九篇介紹了多人通訊拓撲。當產品需要 SFU 時，真正的工作不只是「架一台媒體伺服器」，還包含信令、房間狀態、認證、TURN、容量分配、監控與故障轉移。本篇以 mediasoup 與 Janus 兩種不同設計取向作為選型範例。
一、 Mediasoup：Node.js 開發者的首選
mediasoup 不是具備完整產品功能的獨立會議伺服器，而是可嵌入 Node.js 應用的低階媒體函式庫。JavaScript 層管理業務物件，C++ Worker 子行程處理 ICE、DTLS、RTP 與 RTCP。
核心優點
- 可組合的媒體物件：以
Worker、Router、Transport、Producer與Consumer組成應用。 - Simulcast / SVC：可依 Consumer 與網路狀態選擇空間層、時間層。
- 高客製彈性：房間、權限與信令都由應用決定。
- 責任也更多：應用必須管理物件生命週期、Worker 分配與跨節點擴展。
二、 Janus：成熟穩定的萬能插件機
Janus 是由 Meetecho 開發的開源伺服器，採用 C 語言編寫，以「插件化 (Plugin-based)」聞名。
核心優點
- 成熟插件：VideoRoom 提供 SFU 形式的 Publish/Subscribe 房間；Streaming 等插件處理其他媒體場景。
- 獨立服務：應用透過 Janus API 與插件訊息控制媒體會話。
- 既有協議整合：可搭配 RTP、RTSP 等來源，實際能力取決於插件與編譯設定。
- 較明確的功能模型：適合需求能對應既有插件，或需要與既有媒體系統整合的團隊。
三、 選型比較
| 問題 | mediasoup | Janus |
|---|---|---|
| 使用方式 | Node.js 應用內的低階函式庫 | 獨立伺服器加插件 |
| 房間與信令 | 幾乎完全自行設計 | 依插件 API 建立 |
| 客製彈性 | 高 | 中高，受插件模型影響 |
| 上手成本 | 需要理解媒體物件與生命週期 | 需要理解 Janus Session、Handle 與插件訊息 |
| 適合團隊 | 想掌控產品與媒體流程 | 偏好成熟插件或協議整合 |
這不是效能排行榜。兩者都需要根據房間模型、Codec、Simulcast/SVC、單機網卡、CPU 與目標區域實際壓測。
四、 一個可上線的 SFU 系統還缺什麼
至少還要補齊：
- 節點與房間排程：決定新房間進入哪個 Worker 或主機。
- 容量保護：依 CPU、出口頻寬、Producer 與 Consumer 數量拒絕或搬移負載。
- TURN 與區域路由：讓使用者連到合適的媒體區域，並處理嚴格網路環境。
- 可觀測性：收集連線成功率、加入時間、丟包、RTT、碼率與品質限制原因。
- 生命週期清理：客戶端斷線、Worker 異常或節點消失時釋放相關資源。
- 錄影與媒體處理：明確規劃 RTP 匯出、合成、儲存與隱私政策。
系列完結感言：從協議到工程
從第一篇的 getUserMedia() 到 SFU，我們已經建立一張從瀏覽器媒體、協商、ICE 到多人架構的地圖。這套系列提供的是可繼續實作的基礎，而不是讀完即可直接承載大量併發的完整方案。下一步應把範例做成可部署專案，並用真實裝置與網路進行容量和故障測試。
接下來的學習方向
- 深入 Codec 與分層編碼：研究 H.264、VP8、VP9、AV1、Simulcast 與 SVC。
- 完成可部署專案：加入短效 TURN 憑證、Perfect Negotiation、監控與自動化測試。
- 壓力與故障測試：驗證 Worker 容量、網路出口、節點中斷與重新加入流程。
- 媒體處理：研究錄影、字幕、語音轉文字與端到端加密的取捨。
延伸閱讀與資源
- Mediasoup Official: mediasoup.org
- Janus Gateway: janus.conf.meetecho.com