乾貨好文帶你認識WebRTC伺服器的常見架構
導讀 | WebRTC 在構建瀏覽器視訊會話的時候,肯定少不了伺服器的支援。目前,WebRTC 主要有三種網路架構:Mesh、MCU、SFU。今天就來分別介紹一下三者,帶大家認識一下它們的優點和缺點。 |
Mesh 伺服器架構其實就是標準 P2P 通訊模式的混用,每一個 P2P 連線有獨立的傳輸策略控制,通訊質量有一定的保障。但是,這種架構對於客戶端系統是一種浪費,一方面需要分配更多的埠,消耗更多的系統資源;另一方面,由於要向其它三個客戶端傳送本地音視訊資料,增加了上行網路頻寬的消耗,在同等頻寬條件下,支援的多人通話路數就相對有限,視訊質量(位元速率)也比較低。這種架構比較適合網路狀況較好,人數較少,比如一對一的場景中。
a. 佔用大量頻寬。以上圖為例,假設所有上下行媒體流佔用頻寬都是 1MB,那麼,每個客戶端需要提供 3MB 的上行頻寬和 3MB 的下行頻寬,每個客戶端總體消耗的頻寬是 6MB。如果複用 PeerConnection 通道的話,也需要建立六條鏈路。
b. 佔用客戶端資源。如上圖所示,每個客戶端在通訊過程中需要同時編碼三路媒體流,分別傳送給另外三個參會者,而不是共用一路編碼媒體流。因此,會佔用比較多的客戶端資源。
優點
a. 對伺服器資源佔用最小。這一點也非常好理解,因為壓根兒就沒有用到流媒體伺服器,只需要一個 ICE 穿透伺服器就可以滿足 P2P 打洞從而建立連線。
b. 成本最低。不像其他架構型別需要對流媒體伺服器投入大量的資金和人力成本,節省了在伺服器方面的絕大多數支出費用。
c. 去中心化。充分利用了客戶端的算力,在邊緣計算的大時代下,可能未來還會迎來新的機遇和挑戰。
MCU 將接收到的多路流進行轉碼和混合,並向每個終端輸出單路流的做法,節省了終端使用者的下行頻寬,並且還能夠對不同網路條件的使用者,訂製不同位元速率的輸出視訊流,讓多人場景有更好的使用者體驗。典型的應用場景是多人音視訊通話。這種架構比較適合客戶端條件較差的場景,比如使用手機進行多人的視訊通話,由服務端來抵消移動端的資源消耗。
a. 對伺服器壓力最大。MCU 服務架構需要系統提供一箇中心化的 MCU 混流伺服器,所有媒體流的解碼、編碼、轉碼、混合都在伺服器端完成。如上圖所示,四個客戶端需要把自己的媒體流推流到 MCU 伺服器,然後 MCU 伺服器再對這四路媒體流進行解碼、混流,最後把合併的媒體流傳送給四個參會者。因此,MCU 架構的伺服器壓力非常大,也是三種服務架構中壓力最大的。
b. 自定義佈局複雜。一般情況下,MCU 伺服器僅混流編碼一路合併之後的媒體流,上圖中的四個參會者接收到的混流媒體流是同一路,看到的視訊畫面也是一致的。如果某個參會者想改變視訊畫面的佈局,比如放大某個人的視訊畫面,或者關閉某個人的視訊畫面,通常是無法滿足的。但是,我們也可以定義單獨的信令邏輯,請求 MCU 伺服器單獨編碼一路媒體流傳送給特定需求的參會者。但是,需要限制或者避免所有參會者都有類似的需求,否則 MCU 服務架構會退化成 SFU 服務架構。
c. 成本最高。如果資金允許的話,還是應該考慮引入高階的 GPU 加速伺服器,用來提高流媒體伺服器的混流能力。但是,成本也會相應提高。
a. 頻寬佔用最小。還以上圖為例,假設每路媒體流所佔頻寬大小為 1MB,每個客戶端總體消耗的頻寬是 2MB。如果複用 PeerConnection 通道的話,只需要建立四條鏈路。
b. 客戶端解碼壓力小。因為每個參會的客戶端都只需要解碼一路媒體流,就可以代替分別解碼每個參會者媒體流的情況,而另外兩種服務架構都需要單獨解碼其他參會者的媒體流。
SFU 是解決伺服器效能問題最有吸引力的方法,因為它不涉及視訊解碼和編碼的計算費用,它以最低的開銷來轉發各路媒體流,典型的應用場景是1對多的直播服務。這種架構適用於大多數的情況,人數中等的場景,比如大班課,多人語音通話等。
a. 客戶端解碼壓力大。這一點和 Mesh 服務架構相似,每個客戶端需要解碼 n-1 路媒體流。如上圖所示,每個客戶端需要編碼一路媒體流同時解碼三路媒體流。
b. 伺服器成本也相對較高。其實,一般情況下,SFU 架構的伺服器成本介於 Mesh 架構和 MCU 架構之間。但是,這也取決 SFU 服務架構的規模和複雜程度。
優點
a. 伺服器壓力適中。儘管都需要部署流媒體伺服器,但是 SFU 架構和 MCU 架構不一樣,它不需要對媒體流解碼再混流。SFU 的伺服器只負責媒體流的轉發或者儲存,不做編碼、解碼、轉碼、混合等算力要求比較高的任務。所以,伺服器端的壓力比 MCU 要低很多。
b. 頻寬佔用適中。以上圖為例,依然假設每路媒體流所佔頻寬為 1MB,那麼每個客戶端的上行頻寬為 1MB,下行頻寬為 3MB,每個客戶端總體消耗的頻寬是 4MB。很明顯,佔用頻寬(4MB)介於 Mesh 架構(6MB)和 MCU 架構(2MB)之間。
c. 佈局控制靈活。因為每個參會者都拉取了其他參會者的媒體流,所以,每個使用者都可以動態改變自己本地的畫面佈局,比如放大、縮小等。如果不希望觀看某個人的視訊畫面,還可以不訂閱這個人的媒體流。
本文介紹了 Mesh、MCU、SFU 三種 WebRTC 服務架構的基本情況,也論述了它們各自的優缺點。儘管它們都有各種不足,但是它們對 WebRTC 實時音視訊通訊技術的發展都起到了一定的推動作用。Mesh、MCU、SFU 三種服務架構有非常多值得我們學習和借鑑的地方。現在很多先進的伺服器方案不是單單使用某一種服務架構,更多的是搭配使用。比如我們自己的 WebRTC 流媒體伺服器就是使用了 MCU+SFU 的混合模式。所以說,在技術選型時沒有絕對的,我們需要根據自己具體的業務場景和技術儲備情況挑選最合適的方案。
原文來自:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2893359/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 乾貨好文帶你理解C語言中的連結串列C語言
- 科普乾貨IT知識,Java的常見異常有哪些?Java
- 帶你認識網際網路架構的演變過程架構
- 大語言模型底層架構丨帶你認識Transformer模型架構ORM
- 一文帶你搞懂 Kafka 的系統架構(深度好文,值得收藏)Kafka架構
- 常見的網站伺服器架構有哪些?網站伺服器架構
- “百變”Redis帶你見識不同場景下的產品技術架構Redis架構
- Java常見知識點彙總(⑮)——Jvm架構JavaJVM架構
- 乾貨好文 | 初探MySQL遷移到ClickHouseMySql
- [乾貨分享]1000篇乾貨好文!量子技術——進階篇
- [乾貨分享]1000篇乾貨好文!量子技術——資訊篇
- 帶你真正認識ViewView
- 【乾貨】MySQL底層架構設計,你瞭解多少?MySql架構
- 乾貨:軟體架構詳解架構
- 【乾貨】驗證碼的常見型別總結型別
- 常見的五種軟體架構架構
- [乾貨分享]1000篇乾貨好文!量子技術——專家觀點篇
- 經典乾貨:Docker 常見故障排查處理Docker
- 【學員乾貨】App常見效能測試點APP
- 軟體體系架構的認識架構
- 乾貨:軟體架構分析詳解架構
- 乾貨帖 | TDSQL-A核心架構揭秘SQL架構
- 乾貨 | 廣告系統架構解密架構解密
- 10種常見的軟體架構模式架構模式
- 7.帶你認識Dart中的MapDart
- 一文帶你認識DockerDocker
- 純乾貨:21天帶你玩轉容器
- 乾貨 | 攜程圖片服務架構架構
- 【知識分享】 伺服器的架構伺服器架構
- 技術乾貨 | WebRTC ADM 原始碼流程分析Web原始碼
- 乾貨 | 4步帶你完成私有云盤搭建
- 【虹科乾貨】設計微服務架構的原則微服務架構
- 乾貨:阿里大牛淺談MySQL架構體系阿里MySql架構
- 認識物聯網平臺架構架構
- 重新認識Java微服務架構-認證服務Java微服務架構
- 技術乾貨 | WebRTC 技術解析之 Android VDMWebAndroid
- 乾貨:從『價值角度』來重新認識社群運營
- 帶你認識,19個學習Python的小技巧!Python