目錄：
媲美zoom的視頻會議app
WebRTC的行業地位
RTC架構
動態分辨率調整
媲美zoom的視頻會議app
上一期《WebRTC安全問題：私有IP與mDNS》中介紹了私有IP地址泄露的問題，關於私有IP泄露問題可以搜索關鍵詞WebRTC+IP+leakage，或者查看Mozilla的bug報告：https://bugzilla.mozilla.org/show_bug.cgi?id=959893。
由於WebRTC的安全考慮，有時候WebRTC並沒有權限獲取本機的網卡IP地址，取而代之的是一個mDNS域名，但是由於mDNS尚未普及，設備不一定支持。所以不依賴WebRTC的“host candidate”，需要主動維護所有app設備的IP地址，通過心跳連接讓中心的web端主動匯聚所有app的IP地址，並交換。一句話概括：手機的IP讓web端來找，別自己找。
本文是WebRTC系列教程第四篇，仍然圍繞理論基礎，扯點有的沒的。事實上，WebRTC的性能絲毫不弱於風靡全世界，行業領先的zoom，一般想要實現這樣一個能提供高清畫質的app，需要部署以下幾個子系統：
WebRTC音視頻編解碼技術
信令服務，用於網絡層打洞（園區內網可能不需要）
房間控制/認證（WebSocket，同上）
RTC架構：全互聯mesh/中心化SFU
WebRTC的行業地位
如果按照時間性能和空間性能（數據量）這2個維度對所有網絡通訊應用進行分類，大致可以分爲3類：常規通訊、即時（消息）通訊、即時音視頻通訊，共三種不同性能要求的通訊場景。
| 類型 | 時間要求 | 數據量 | 場景 | |
|---|---|---|---|---|
| 1 | 通訊 | 低 | 小 | HTTP網頁、文件傳輸、電子郵件 |
| 2 | 即時通訊 | 高 | 小 | 聊天室、電話、網絡遊戲 |
| 3 | 即時音視頻通訊 | 高 | 大 | 視頻通訊、遠程桌面、3D像素流 |
這3類app對性能的要求遞增，很顯然WebRTC是爲了解決第3類應用場景。此類通訊的難度最大，單位時間內傳遞的數據量巨大，同時要求低延遲。遍歷整個互聯網，找不到比即時音視頻通訊更難的需求，WebRTC技術本身就橫跨多個基礎學科，包括圖論、信息論、控制論等，其行業地位可想而知。
RTC架構
如果只有2個人，自然p2p通訊是最佳方案；如果有3到5人的通訊，採用兩兩相連的全互聯結構（full mesh）也是可以接受；如果人數增長至5以上，至少要考慮2點性能優化方案：
複用媒體流：可以利用中心節點（如SFU）將重複的媒體流匯聚至上行鏈路（uplink）。
有損壓縮：用戶不一定需要每個peer都傳入100%分辨率的媒體流，比如視頻會議中的縮略頭像。
其實，如果打算開發一個不到10人的視頻會議，mesh結構沒得問題，mesh（網格）架構是最簡單的全互聯架構。全互聯是圖論的一個術語，代表所有節點兩兩相連，邏輯網絡如下圖：
注意，這張圖只是邏輯上的網線，並非物理網線，根據組合數公式，全互聯網絡有C(n, 2)=n(n-1)/2個連接。這是一個二次多項式的複雜度，當n大於10以後是很恐怖的，真實物理鏈路利用中心的交換機將鏈路數量降至線性增長，不然太恐怖了。
動態分辨率調整
有時候，我們並不需要看到每個人的高清畫質。
WebRTC接收的媒體流對象可以設置各種限制（constraints），包括空間上的分辨率和時間上的幀率（fps），這些限制可以節省流量。現代手機攝像頭的分辨率大多是1080p（30fps），但是每個用戶只接受2種分辨率，一種是類似監控中心的縮略版，一種是聚焦到某個用戶時的完整圖像。所以需要通在app中按需限流，除此之外，WebRTC也會根據網絡環境對分辨率和幀率進行微調。
<完>
往期回顧：
本文分享自微信公衆號 - WebHub（myWebHub）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。