近年來，直播競答、網絡遊戲直播等新的實時音視頻通訊場景不斷推陳出新，并成為引領互聯網娛樂風向的弄潮兒。實時音視頻應用的爆發，也使得WebRTC（Web Real-Time Communication，網頁實時通信技術，）技術成為了人們關注的焦點。如何打造自己的WebRTC 服務器呢？下面我先來介紹一下WebRTC 服務器的一些基本内容：
首先，我們會先來了解下一些開源的服務器是怎麼做的，我們做事情，在沒有頭緒的基礎上，參考和模仿可能是一種必然流程，畢竟站在巨人的肩膀上，我們的視野才更加開闊。
其次，通過形形色色的開源服務器介紹和理解，我們初步的去分析一個WebRTC 服務器究竟包含哪些模塊，又是一個什麼樣的組織架構和層次關系。後面在服務器搭建後面臨的丢包和多人通話問題又有什麼解決方式。最後就是展望一下整個WebRTC未來發展。
2. 開源的WebRTC 服務器介紹我們進入第一部分：WebRTC開源服務器介紹,這個模塊我選擇了我認為很有代表意義的3種類型的WebRTC 開源服務器
之所以稱Kurento為大而全，是因為Kurento 強大的濾鏡和計算機視覺，我們看這張圖：
Kurento功能圖
通過這張圖我們了解到Kurento不僅僅包含了普通流媒體服務器的SFU MCU Transcoding Recording等基本功能，還包含了強大的濾鏡和計算機視覺處理功能，而且，在整體的功能上不僅僅包含WebRTC 模塊還有很多其他協議支持，諸如SIP RTMP RTSP 等協議，更準确的說Kurento 更像是一個融合通信平台，而且Kurento,基于插件式編程方式，很容易擴展自己的功能模塊。
Kurento 在應用中有哪些問題，或者說，哪些是優勢，哪些是劣勢呢，我們看下面：
優勢：
劣勢:
Mediasoup是一個很新的WebRTC服務器，專注WebRTC 的相關功能開發，專注做好這一件事，很小确很美。下面這樣圖是Mediasoup 大緻的一個基本架構圖：
Mediasoup 架構
Mediasoup
優勢：
劣勢：
說了兩款極端的WebRTCserver ，我們最後講一個務實主義的Licode ，為什麼稱Licode 為務實主義？Licode 這款服務器完全是站在一個PAAS 平台，一個業務的角度去思考問題，去構建整個系統，很務實，很實際，我們看Licode架構圖：
Licode 架構圖
架構很清晰:
用戶端:
服務端：
開發者方面：
業務接入的API模塊
服務器内部：
整個服務架構内部各個服務模塊通過MQ 消息總線進行數據通信，做了一個服務器要做的基本功能，同時微服務化，很符合現在服務器開發的方向。
Licode 作為WebRTC 服務器有很多優勢：
缺點：
這麼多服務器怎麼選擇呢？看自己的業務需求，團隊能力，項目周期。
有能力的團隊可以嘗試選Kurento，講求平衡快速選擇Licode，追求極緻Mediasoup 很符合選擇。
相關視頻推薦：
C/C 程序員進入互聯網公司的捷徑-WebRTC開發_哔哩哔哩_bilibili
手把手實現WebRTC音視頻通話|WebRTC音視頻通話邏輯剖析、如何通過代碼實現音視頻通話_哔哩哔哩_bilibili
學習地址：【免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發-學習視頻教程-騰訊課堂
需要更多ffmpeg/webrtc..音視頻流媒體開發學習資料加群812855908領取
到底WebRTC 是個什麼東西，又包含哪些模塊呢，我們從下面幾個方面逐一分析：
基本模塊
圖中我列出了基本的組件：
Rtp/Rtcp Dtls ICE是基本組件相對實現比較容易，這個我們不做過多介紹，我們着重介紹下SDP 這個協議
SDP 演進SDP 伴随着WebRTC 的發展，經曆了很多變化，我把這個過程歸納為兩個階段：
每個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 方案優勢：
說完基本組件，我們開始介紹WebRTC 服務端，分3個層面：
接口層接口層主要為PeerConnectionInterface接口實現，主要提供諸如一下内容：
控制層也就是我們所說的SDP 模塊，控制整個系統的運行表現，包括編解碼參數，流控方式，Dtls 加解密參數以及ICE穿透用的地址候選。
先看圖：
傳輸層分為3個層次，媒體打包（RTP/RTCP）,數據安全（DtlsTransport）,Ice P2P 傳輸模塊（IceTransport）。
了，這裡我們了解全部系統組件，将系統組件疊加,我們就得到了，下面是一個完整的WebRTC 組件的一個層次結構：
分為3層：接口層，提供基本的peer 接口功能，控制層，主要是SDP 的解析和生成工作，最後傳輸層，提供媒體打包，傳輸，流控，安全，ICE 等功能。
4. 通信優化分兩個層面去講：
使用場景 low RTT 或者延時不敏感場景
冗餘換取實時性和丢包。增強帶寬搶占能力，這才是FEC 最主要的用途。
兩種方式各有優缺點，NACK代價是延時，FEC的代價是帶寬，顯然在高清會議中不适用FEC 方式。比較可取的方式是FEC NACK, 低延時環境下，盡量采用重傳，高延時生成适度的FEC數據包，對數據進行選擇性重傳。
多人通信多人通信是一個令人的頭疼的問題，因為面臨以下幾個問題：
先看第一個，我們都知道在通信中，用戶的帶寬往往是不對等的，怎麼樣做到按需供給，總體來說我們有一下幾種方式：
先轉碼方案：
服務端對用戶發來的數據進行二次編碼，服務端根據用戶的網絡情況，提供給用戶不同質量的碼流，這種方式服務壓力大，延遲大，硬件成本高，比較适合小規模視頻會議，或者發言人較少的場景。
SVC方案：
編碼器産生的碼流包含一個或多個可以單獨解碼的子碼流，子碼流可以具有不同的碼率，幀率和空間分辨率。
分級的類型：
時域可分級（Temporalscalability）：可以從碼流中提出具有不同幀頻的碼流。
空間可分級（Spatialscalability）：可以從碼流中提出具有不同圖像尺寸的碼流。
質量可分級（Qualityscalability）：可以從碼流中提出具有不同圖像質量的碼流。
分層結構圖
SVC可以組合提供不同質量的碼流，服務器可以根據用戶網絡情況選擇一路進行轉發，
SVC 應該是最好的對抗丢包的方式，可惜WebRTC 不能用，這裡我們不做深入研究，H264SVC RTP打包情況可以參考rtc6190
Simulcast（多流） 方案：
如圖：
客戶端同時發送多種碼率到服務端，然後服務端進行選擇性轉發，這種方案，發送端上傳壓力大，而且編碼壓力也大，但是，這是唯一一種WebRTC 支持的針對多人通話的技術。
下面我們看看如何開啟這種技術：
Chrome并沒有提供直接的接口用于開啟多流方案，我們在Chrome 系列中隻能通過修改的本段的SDP 來開啟多流方案，如圖：
通過修改SDP 加入SIM 标志開啟多流，開啟幾條，就多加入幾條ssrc 信息
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 的未來無可限量。
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
