如何打造自己的WebRTC 服务器
1、引言
近年來，直播競答、網絡游戲直播等新的實時音視頻通訊場景不斷推陳出新，并成為引領互聯網娛樂風向的弄潮兒。實時音視頻應用的爆發，也使得WebRTC（Web Real-Time Communication，網頁實時通信技術，）技術成為了人們關注的焦點。如何打造自己的WebRTC 服務器呢？下面我先來介紹一下WebRTC 服務器的一些基本內容：
開源的WebRTC 服務器介紹
WebRTC服務端整體分析
通信優化
WebRTC的未來展望
首先，我們會先來了解下一些開源的服務器是怎么做的，我們做事情，在沒有頭緒的基礎上，參考和模仿可能是一種必然流程，畢竟站在巨人的肩膀上，我們的視野才更加開闊。
其次，通過形形色色的開源服務器介紹和理解，我們初步的去分析一個WebRTC 服務器究竟包含哪些模塊，又是一個什么樣的組織架構和層次關系。后面在服務器搭建后面臨的丟包和多人通話問題又有什么解決方式。最后就是展望一下整個WebRTC未來發展。
2、開源的WebRTC 服務器介紹
我們進入第一部分：WebRTC開源服務器介紹,這個模塊我選擇了我認為很有代表意義的3種類型的WebRTC 開源服務器
大而全的Kurento
務實主義的Licode
小而美的Mediasoup
2.1大而全的Kurento
之所以稱Kurento為大而全，是因為Kurento 強大的濾鏡和計算機視覺，我們看這張圖：
Kurento功能圖
通過這張圖我們了解到Kurento不僅僅包含了普通流媒體服務器的SFU MCU Transcoding Recording等基本功能，還包含了強大的濾鏡和計算機視覺處理功能，而且，在整體的功能上不僅僅包含WebRTC 模塊還有很多其他協議支持，諸如SIP RTMP RTSP 等協議，更準確的說Kurento 更像是一個融合通信平臺，而且Kurento,基于插件式編程方式，很容易擴展自己的功能模塊。
Kurento 在應用中有哪些問題，或者說，哪些是優勢，哪些是劣勢呢，我們看下面：
優勢：
文檔齊全無論API使用文檔,還是部署文檔都很齊全
功能強大，強大的路徑和計算機視覺處理
模塊化編程，方便擴展，這是對開發者很友好的地方
使用方便，客戶端服務端都有專門的API 組件 接入系統，而且服務器端提供了J2EE node.js兩種接口文檔，覆蓋很齊全
劣勢:
代碼太多太龐大，可能需要開發者有足夠的功力才能駕馭這把屠龍刀
還一個重要原因就是性能比較差
2.2小而美的Mediasoup
Mediasoup是一個很新的WebRTC服務器，專注WebRTC 的相關功能開發，專注做好這一件事，很小確很美。下面這樣圖是Mediasoup 大致的一個基本架構圖：
Mediasoup 架構
Mediasoup
優勢：
性能優秀
支持很多的WebRTC 新特性（PlanB UnifiedPlan simulcast）
同時支持ORTC和WebRTC 的互通
劣勢：
功能比較少
代碼和架構相對來比較晦澀一點
信令模塊只提供node.js 版本
2.3務實主義的Licode
說了兩款極端的WebRTCserver ，我們最后講一個務實主義的Licode ，為什么稱Licode 為務實主義？Licode 這款服務器完全是站在一個PAAS 平臺，一個業務的角度去思考問題，去構建整個系統，很務實，很實際，我們看Licode架構圖：
Licode 架構圖
架構很清晰:
用戶端:
房間信令模塊
WebRTC媒體模塊
服務端：
開發者方面：
業務接入的API模塊
服務器內部：
面向開發的API 服務模塊，提供基本的房間和用戶操作
房間服務器模塊,提供基本的房間信令支持
媒體模塊，完成服務端的WebRTC 媒體功能
整個服務架構內部各個服務模塊通過MQ 消息總線進行數據通信，做了一個服務器要做的基本功能，同時微服務化，很符合現在服務器開發的方向。
Licode 作為WebRTC 服務器有很多優勢：
功能齊全擴展方便，鑒權，存儲，融合通信一應俱全
代碼擴展簡單，預留了足夠的擴展接口
部署簡單，一鍵腳本安裝，很方便
缺點：
內部模塊說明比較少
性能一般
服務端只提供的node.js 版本
2.4總結
這么多服務器怎么選擇呢？看自己的業務需求，團隊能力，項目周期。
有能力的團隊可以嘗試選Kurento，講求平衡快速選擇Licode，追求極致Mediasoup 很符合選擇。
3、WebRTC 服務端分析
到底WebRTC 是個什么東西，又包含哪些模塊呢，我們從下面幾個方面逐一分析：
基本組件
層次架構
3.1基本組件
基本模塊
圖中我列出了基本的組件：
Rtp/Rtcp媒體打包協議
Dtls加密協議
ICEP2P 傳輸協議
SDP系統控制協議，控制整個系統的運行行為
Rtp/Rtcp Dtls ICE是基本組件相對實現比較容易，這個我們不做過多介紹，我們著重介紹下SDP 這個協議
3.2SDP 演進
SDP 伴隨著WebRTC 的發展，經歷了很多變化，我把這個過程歸納為兩個階段：
PlanA單流時代
PlanB/UnifiedPlan多流時代
3.3PlanA
每個stream 對應一個peer 多個stream 對應多個peer,整體運行圖如下：
PlanA
下面是PlanA 的SDP 結構：
沒什么新奇的地方，大家都應該比較熟悉了，我們不做介紹了。
3.4PlanB 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
減少端口占用，加強系統安全
3.5WebRTC 層次架構
說完基本組件，我們開始介紹WebRTC 服務端，分3個層面：
3.5.1接口層
接口層主要為PeerConnectionInterface接口實現，主要提供諸如一下內容：
3.5.2控制層
控制層也就是我們所說的SDP 模塊，控制整個系統的運行表現，包括編解碼參數，流控方式，Dtls 加解密參數以及ICE穿透用的地址候選。
3.5.3傳輸層
先看圖：
傳輸層分為3個層次，媒體打包（RTP/RTCP）,數據安全（DtlsTransport）,Ice P2P 傳輸模塊（IceTransport）。
了，這里我們了解全部系統組件，將系統組件疊加,我們就得到了，下面是一個完整的WebRTC 組件的一個層次結構：
分為3層：接口層，提供基本的peer 接口功能，控制層，主要是SDP 的解析和生成工作，最后傳輸層，提供媒體打包，傳輸，流控，安全，ICE 等功能。
4、通信優化
分兩個層面去講：
對抗丟包
多人通話
4.1對抗丟包
NACK
使用場景 low RTT 或者延時不敏感場景
FEC
冗余換取實時性和丟包。增強帶寬搶占能力，這才是FEC 最主要的用途。
兩種方式各有優缺點，NACK代價是延時，FEC的代價是帶寬，顯然在高清會議中不適用FEC 方式。比較可取的方式是FEC+NACK, 低延時環境下，盡量采用重傳，高延時生成適度的FEC數據包，對數據進行選擇性重傳。4.2多人通信
多人通信是一個令人的頭疼的問題，因為面臨以下幾個問題：
不同的用戶網絡帶寬
不同的運營商
4.3不同用戶網絡帶寬
先看第一個，我們都知道在通信中，用戶的帶寬往往是不對等的，怎么樣做到按需供給，總體來說我們有一下幾種方式：
轉碼
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 的對應關系，進而完成傳輸。
4.4不同運營商
中國運營商主要有電信 移動和聯通，另外包括很多小運營上和結構運營商，運營商很多，而且由于運營商之間的網絡寬口問題，跨網通信延遲大，網絡不穩定，針對這種情況，我們基于DNS重定向，分配給用戶運行商相同的服務器，這里說一句，運營商分類的判斷，需要很久的運維經驗和數據作為支撐，這也是我們的PP云的優勢所在，我們PP云有十幾年的運營數據作為支撐，這些數據不僅幫我們構建更加快速的服務器網絡，而且還可以幫我們為用戶定位到最優的服務器，進而解決最后一英里的網絡傳輸問題。
5、WebRTC 未來展望
5.1為AI 賦能
AI 的發展，賦予了WebRTC更多的應用空間，比如基于人臉和語音識別的網站和APP 登錄系統，前端通過WebRTC 進行視頻數據的采集和傳輸，后臺通過AI智能分析比對結果，進而完成登錄，簡單，方便。
5.2安防領域
我們知道安防領域比較多的協議包括ONVIF,GB28181 RTSP，這幾個協議在網頁端無法直接觀看，智能借助于插件，插件面臨兼容和安全問題，體驗很差，有的攝像頭支持RTMP觀看，但是很遺憾，2020年flash 將退出歷史舞臺，HLS延時大，而無插件，極速都是WebRTC 的優勢所在，我相信不救的將來WebRTC 在安防領域會占據一席之地。
6、結語：
WebRTC1.0 已經定稿，這為WebRTC的未來發展提供了方向，并且WebRTC 無論是應用還是社區都處于高速發展狀態，并且Google也在不斷地提供和完善WebRTC 的相關功能，我相信WebRTC 的未來無可限量。
原文https://www.toutiao.com/article/7049339761479189006/?channel=&source=search_tab
★文末名片可以免費領取音視頻開發學習資料，內容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音視頻學習路線圖等等。
見下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
總結
以上是生活随笔為你收集整理的如何打造自己的WebRTC 服务器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： matlab 调幅频谱ifft,通原抑制
- 下一篇： 认识JSX语法