作者介紹：王立飛。PP雲技術工程師，WebRTC領域技術專家，最早的一批WebRTC實踐者，8年以上音視頻解決方案設計和開發經驗。

1. 引言

近年來，直播競答、網路遊戲直播等新的實時音視頻通訊場景不斷推陳出新，並成為引領互聯網娛樂風向的弄潮兒。實時音視頻應用的爆發，也使得WebRTC（Web Real-Time Communication，網頁實時通信技術，）技術成為了人們關注的焦點。如何打造自己的WebRTC 伺服器呢？下面我先來介紹一下WebRTC 伺服器的一些基本內容：

開源的WebRTC 伺服器介紹

WebRTC服務端整體分析

通信優化

WebRTC的未來展望

首先，我們會先來了解下一些開源的伺服器是怎麼做的，我們做事情，在沒有頭緒的基礎上，參考和模仿可能是一種必然流程，畢竟站在巨人的肩膀上，我們的視野才更加開闊。

其次，通過形形色色的開源伺服器介紹和理解，我們初步的去分析一個WebRTC 伺服器究竟包含哪些模塊，又是一個什麼樣的組織架構和層次關係。後面在伺服器搭建後面臨的丟包和多人通話問題又有什麼解決方式。最後就是展望一下整個WebRTC未來發展。

2. 開源的WebRTC 伺服器介紹

我們進入第一部分：WebRTC開源伺服器介紹,這個模塊我選擇了我認為很有代表意義的3種類型的WebRTC 開源伺服器

大而全的Kurento

務實主義的Licode

小而美的Mediasoup

大而全的Kurento

之所以稱Kurento為大而全，是因為Kurento 強大的濾鏡和計算機視覺，我們看這張圖：

Kurento功能圖

通過這張圖我們了解到Kurento不僅僅包含了普通流媒體伺服器的SFU MCU Transcoding Recording等基本功能，還包含了強大的濾鏡和計算機視覺處理功能，而且，在整體的功能上不僅僅包含WebRTC 模塊還有很多其他協議支持，諸如SIP RTMP RTSP 等協議，更準確的說Kurento 更像是一個融合通信平台，而且Kurento,基於插件式編程方式，很容易擴展自己的功能模塊。

Kurento 在應用中有哪些問題，或者說，哪些是優勢，哪些是劣勢呢，我們看下面：

優勢：

文檔齊全無論API使用文檔,還是部署文檔都很齊全

功能強大，強大的路徑和計算機視覺處理

模塊化編程，方便擴展，這是對開發者很友好的地方

使用方便，客戶端服務端都有專門的API 組件 接入系統，而且伺服器端提供了J2EE node.js兩種介面文檔，覆蓋很齊全

劣勢:

代碼太多太龐大，可能需要開發者有足夠的功力才能駕馭這把屠龍刀

還一個重要原因就是性能比較差

小而美的Mediasoup

Mediasoup是一個很新的WebRTC伺服器，專註WebRTC 的相關功能開發，專註做好這一件事，很小確很美。下面這樣圖是Mediasoup 大致的一個基本架構圖：

Mediasoup 架構

Mediasoup

優勢：

性能優秀

支持很多的WebRTC 新特性（PlanB UnifiedPlan simulcast）

同時支持ORTC和WebRTC 的互通

劣勢：

功能比較少

代碼和架構相對來比較晦澀一點

信令模塊只提供node.js 版本

務實主義的Licode

說了兩款極端的WebRTCserver ，我們最後講一個務實主義的Licode ，為什麼稱Licode 為務實主義？Licode 這款伺服器完全是站在一個PAAS 平台，一個業務的角度去思考問題，去構建整個系統，很務實，很實際，我們看Licode架構圖：

Licode 架構圖

架構很清晰:

用戶端:

房間信令模塊

WebRTC媒體模塊

服務端：

開發者方面：

業務接入的API模塊

伺服器內部：

面向開發的API 服務模塊，提供基本的房間和用戶操作

房間伺服器模塊,提供基本的房間信令支持

媒體模塊，完成服務端的WebRTC 媒體功能

整個服務架構內部各個服務模塊通過MQ 消息匯流排進行數據通信，做了一個伺服器要做的基本功能，同時微服務化，很符合現在伺服器開發的方向。

Licode 作為WebRTC 伺服器有很多優勢：

功能齊全擴展方便，鑒權，存儲，融合通信一應俱全

代碼擴展簡單，預留了足夠的擴展介面

部署簡單，一鍵腳本安裝，很方便

缺點：

內部模塊說明比較少

性能一般

服務端只提供的node.js 版本

總結

這麼多伺服器怎麼選擇呢？看自己的業務需求，團隊能力，項目周期。

有能力的團隊可以嘗試選Kurento，講求平衡快速選擇Licode，追求極致Mediasoup 很符合選擇。

3 WebRTC 服務端分析

前面我們講了很多開源WebRTC伺服器，到底WebRTC 是個什麼東西，又包含哪些模塊呢，我們從下面幾個方面逐一分析：

基本組件

層次架構

基本組件

基本模塊

圖中我列出了基本的組件：

Rtp/Rtcp媒體打包協議

Dtls加密協議

ICEP2P 傳輸協議

SDP系統控制協議，控制整個系統的運行行為

Rtp/Rtcp Dtls ICE是基本組件相對實現比較容易，這個我們不做過多介紹，我們著重介紹下SDP 這個協議

SDP 演進

SDP 伴隨著WebRTC 的發展，經歷了很多變化，我把這個過程歸納為兩個階段：

PlanA單流時代

PlanB/UnifiedPlan多流時代

PlanA

每個stream 對應一個peer 多個stream 對應多個peer,整體運行圖如下：

PlanA

下面是PlanA 的SDP 結構：

沒什麼新奇的地方，大家都應該比較熟悉了，我們不做介紹了。

PlanB UnifiedPlan:

one peer multi stream， 單個peer 可以擁有多個steam ，整體運行圖如下：

PlanB UnifiedPlan

其中PlanB 是chrome SDP 多流方案，而UnifiedPlan是Firefox 的多流標準同時也是JSEP的標準多流方案，所以UnifiedPlan是我們關注的重點。

我們先來看看PlanB 的多流SDP 大致內容：

PlanB SDP

PlanB 和 PlanA 相比，基本組織形式是相同的。我們看標紅的地方，PlanB 組織多流的方式是通過msid來完成，每個msid 對應一條媒體流. 每個msid下面是自己的傳輸信息，所以在PlanB 方案下，我們可以通過msid來標記用戶。

我們再來看看UnifiedPlan,下面是一個UnifiedPlan 部分SDP:

UnifiedPlan

UnifiedPlan通過加多個m 標籤，來組織多流，每條流分配一個m 標籤，後面跟著自己的attribute 描述，另外group 行業進行了修改，以每個track 進行描述。當然UnifiedPlan 裡面也是msid 可以用來標記用戶。

相比 PlanB,UnifiedPlan SDP更加清晰，自然，當然問題是數據量比計較大，因為有很多冗餘欄位，當然作為JSEP 的標準，我們必須更加關注UnifiedPlan 方案。另外Firefox 裡面mid 長度不能超過16位，在大家的伺服器上產生UnifiedPlan 格式的SDP時注意一下。

PlanBUnifiedPlan 方案優勢：

客戶端single peer， 減少開發難度，無論 MCU 模式還是SFU 模式，客戶端只需要創建一個peer

減少埠佔用，加強系統安全

WebRTC 層次架構

說完基本組件，我們開始介紹WebRTC 服務端，分3個層面：

介面層

介面層主要為PeerConnectionInterface介面實現，主要提供諸如一下內容：

控制層

控制層也就是我們所說的SDP 模塊，控制整個系統的運行表現，包括編解碼參數，流控方式，Dtls 加解密參數以及ICE穿透用的地址候選。

傳輸層

先看圖：

傳輸層分為3個層次，媒體打包（RTP/RTCP）,數據安全（DtlsTransport）,Ice P2P 傳輸模塊（IceTransport）。

了，這裡我們了解全部系統組件，將系統組件疊加,我們就得到了，下面是一個完整的WebRTC 組件的一個層次結構：

分為3層：介面層，提供基本的peer 介面功能，控制層，主要是SDP 的解析和生成工作，最後傳輸層，提供媒體打包，傳輸，流控，安全，ICE 等功能。

4. 通信優化

分兩個層面去講：

對抗丟包

多人通話

對抗丟包

NACK

使用場景 low RTT 或者延時不敏感場景

FEC

冗餘換取實時性和丟包。增強帶寬搶佔能力，這才是FEC 最主要的用途。

兩種方式各有優缺點，NACK代價是延時，FEC的代價是帶寬，顯然在高清會議中不適用FEC 方式。比較可取的方式是FEC+NACK, 低延時環境下，盡量採用重傳，高延時生成適度的FEC數據包，對數據進行選擇性重傳。

多人通信

多人通信是一個令人的頭疼的問題，因為面臨以下幾個問題：

不同的用戶網路帶寬

不同的運營商

不同用戶網路帶寬

先看第一個，我們都知道在通信中，用戶的帶寬往往是不對等的，怎麼樣做到按需供給，總體來說我們有一下幾種方式：

轉碼

SVC 分層編碼

Simulcast(多流方案)

先轉碼方案：

服務端對用戶發來的數據進行二次編碼，服務端根據用戶的網路情況，提供給用戶不同質量的碼流，這種方式服務壓力大，延遲大，硬體成本高，比較適合小規模視頻會議，或者發言人較少的場景。

SVC方案：

編碼器產生的碼流包含一個或多個可以單獨解碼的子碼流，子碼流可以具有不同的碼率，幀率和空間解析度。

分級的類型：

時域可分級（Temporalscalability）：可以從碼流中提出具有不同幀頻的碼流。

空間可分級（Spatialscalability）：可以從碼流中提出具有不同圖像尺寸的碼流。

質量可分級（Qualityscalability）：可以從碼流中提出具有不同圖像質量的碼流。

分層結構圖

SVC可以組合提供不同質量的碼流，伺服器可以根據用戶網路情況選擇一路進行轉發，

SVC 應該是最好的對抗丟包的方式，可惜WebRTC 不能用，這裡我們不做深入研究，H264SVC RTP打包情況可以參考rtc6190

Simulcast（多流） 方案：

如圖：

客戶端同時發送多種碼率到服務端，然後服務端進行選擇性轉發，這種方案，發送端上傳壓力大，而且編碼壓力也大，但是，這是唯一一種WebRTC 支持的針對多人通話的技術。

下面我們看看如何開啟這種技術：

Chrome 端 包括js 和 native 源碼端：

Chrome並沒有提供直接的介面用於開啟多流方案，我們在Chrome 系列中只能通過修改的本段的SDP 來開啟多流方案，如圖：

通過修改SDP 加入SIM 標誌開啟多流，開啟幾條，就多加入幾條ssrc 信息

Firefox 端：

Firefox 提供了直接的介面用於開啟多流方案，如下圖：

Firefox直接通過RtpSender 的 SetParameters 介面開啟多流，簡單方便，這也是Firefox 相比較Chrome更好的地方，更加遵從WebRTC標準。

另外在Rtp的傳輸上Chrome和Firefox 是不同的：

>>>Chrome:

通過ssrc 對應多流方案，每個ssrc對應一種多流

a=ssrc-group:SIM2098403539（low） 2098403540(medium) 2098403541(high)

>>>Firefox:

通過urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idRtp協議頭的擴展來完成多流和ssrc 的對應關係，進而完成傳輸。

不同運營商

中國運營商主要有電信 移動和聯通，另外包括很多小運營上和結構運營商，運營商很多，而且由於運營商之間的網路寬口問題，跨網通信延遲大，網路不穩定，針對這種情況，我們基於DNS重定向，分配給用戶運行商相同的伺服器，這裡說一句，運營商分類的判斷，需要很久的運維經驗和數據作為支撐，這也是我們的PP雲的優勢所在，我們PP雲有十幾年的運營數據作為支撐，這些數據不僅幫我們構建更加快速的伺服器網路，而且還可以幫我們為用戶定位到最優的伺服器，進而解決最後一英里的網路傳輸問題。

5 WebRTC 未來展望

為AI 賦能

AI 的發展，賦予了WebRTC更多的應用空間，比如基於人臉和語音識別的網站和APP 登錄系統，前端通過WebRTC 進行視頻數據的採集和傳輸，後台通過AI智能分析比對結果，進而完成登錄，簡單，方便。

安防領域

我們知道安防領域比較多的協議包括ONVIF,GB28181 RTSP，這幾個協議在網頁端無法直接觀看，智能藉助於插件，插件面臨兼容和安全問題，體驗很差，有的攝像頭支持RTMP觀看，但是很遺憾，2020年flash 將退出歷史舞台，HLS延時大，而無插件，極速都是WebRTC 的優勢所在，我相信不救的將來WebRTC 在安防領域會佔據一席之地。

6. 結語：

WebRTC1.0 已經定稿，這為WebRTC的未來發展提供了方向，並且WebRTC 無論是應用還是社區都處於高速發展狀態，並且Google也在不斷地提供和完善WebRTC 的相關功能，我相信WebRTC 的未來無可限量,分享結束，謝謝大家。

蘇寧旗下子品牌PP雲已累計服務客戶超過2000個；PP雲憑藉PPTV 十年媒體技術和服務經驗，融合流媒體技術、P2P、CDN 分發、海量存儲、安全策略等構建的專註視頻領域的一站式SaaS 服務平台。PP雲集視頻雲直播、雲點播、雲上傳、雲轉碼、雲存儲、雲統計等功能於一體，多平台全方位支持客戶各種視頻場景的業務需求。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！