本文來自即構內部音視訊框架設計的開發同學在 2020 年關於《WebRTC 服務端工程實踐和優化探索》的技術分享；

希望本次分享能給大家在 WebRTC 服務端實現或者專案選型時帶來一些思考。

接下來進入主題，今天的分享主要分為三個部分：

WebRTC 伺服器架構介紹及設計思路；

開發 WebRTC 伺服器所需的技術和麵臨的難點；

QoS 服務質量的實現及優化。

WebRTC 伺服器架構介紹和設計思路

我們首先要想一下，為什麼需要 WebRTC 伺服器？WebRTC 伺服器它的作用是什麼？

在大家的認知裡面，WebRTC 是谷歌開源的一個協議，是現在大家比較熟悉的一個點對點通訊方案。點對點通訊方案是指雙方瀏覽器之間是直接互聯的，如果在多方會議或多方通話的情況下，每個通話者之間都是直連的，沒有經過第三方。

下面來看一下它的優劣勢：

優勢

第一，簡單。這個模型非常簡單，點對點，沒有經過中間的一些伺服器。

第二，延遲小。既然是直連的，我們可能理所當然地認為中間除了這些路由節點之外，就沒有其他地方會增加延時了。但是我後面加了一個問號，也就是說未必是這樣的。

熟悉我們國內運營商網路情況的都知道，聯通，移動，電信之間的通訊可能是不對稱的，如果我是聯通，你是移動，咱們直連的話，延遲未必是小的，這個就是我加了一個問號的原因。

第三，端對端頻寬適應。這個指的是 WebRTC 可以根據會話者之間的網路情況、頻寬情況進行適應。比如當你的接收頻寬不夠時，我可以降低上行編碼位元速率來適應你，從而達到一個更好的通話效果。

劣勢

第一，連通效能差。點對點之間，由於所有的網路不是在一個防火牆後，我們可能需要打洞，甚至有一些防火牆非常嚴格的話，我們連打洞都沒辦法完成，這會極大的影響服務的連通性。

我們首先要發現對方，然後要打洞，如果打洞不成功，還需要通過中轉伺服器來進行媒體的傳輸，這個過程可能會快則幾秒鐘，慢則幾分鐘。也就是說我們從會話開始到雙方建立通訊，整個過程是非常複雜、耗費非常長的時間。

第二，頻寬佔用高。所有的與會者是直連的，帶來的一個問題是，如果我要看到其他所有人的視訊，那麼每個人都需要推一路流給我。同樣的，其他人也是需要接收除他以外的所有流，這時候我的上行頻寬佔用是非常高的。在視訊會議場景下，少則十幾多則二十幾個人，現在幾百個人的會議也是很常見的。按照我們現行的頻寬，是達不到的。

第三，編解碼壓力大。既然每個人的流要單獨傳送給其他與會者，那麼也要單獨編解碼，要傳送 N 路就要編 N 路，並且編解碼壓力是非常大的，不僅我們的移動端沒辦法承受，甚至我們的 PC 端也是沒辦法承受的，這是它很大的一個劣勢。

在我們實際的應用場景上，如果沒有伺服器，那麼我們也沒辦法進行錄製，無法實現視訊回播、鑑黃以及 CDN 分發等功能。綜合考慮，我們就會發現點對點方案可能並沒有很好的滿足我們當前實際的應用需求。

所以這裡就要引入一個伺服器方案的架構，根據剛才提到的點對點三大劣勢，我們來重點看看新方案是如何解決的。

連通性

通常我們的伺服器都會架構在公網上，所以各個會話者是直接跟我們在公網上的伺服器建立連線，省掉了打洞，直接一步到位。

網路頻寬佔用高

假設當前我們這個會議有四方會話，那我的與會者有三路，我只需發一路到伺服器上，通過伺服器把我這一路轉發給其他三路的與會者就可以了，不需要再去多發兩路，這樣我的上行頻寬就從原本的三路變成了一路了；而接收端，引入 MCU 的概念，為了節省下行頻寬，我們可以將這三路混流，再轉發給我，那麼我的下行也只有一路。

編解碼壓力小

通過優化架構頻寬，編解碼從原來的 N 路變成一路，也同步緩解了編解碼壓力。

既然伺服器能更好的滿足我們的實際應用，那麼 WebRTC 伺服器應該怎麼進行架構設計呢？開發 WebRTC 伺服器需要哪些技術以及可能會面臨哪些難點？以及 WebRTC 服務端 QoS（服務質量）的實現及優化有哪些重點要注意的？

篇幅關係，關於《WebRTC 服務端工程實踐和優化探索》的完整內容，大家可以通過我們的活動資料包獲取，資料包中還有視訊回放、演講 PPT 等資料。