音視頻流媒體開(kāi)發(fā)-目錄
iOS知識(shí)點(diǎn)-目錄
Android-目錄
Flutter-目錄
數(shù)據(jù)結(jié)構(gòu)與算法-目錄
uni-pp-目錄
1 WebRTC入門(mén)
1.1 什么是WebRTC
WebRTC（Web Real-Time Communication）是 Google于2010以6829萬(wàn)美元從 Global IP Solutions 公司購(gòu)買捉兴，并于2011年將其開(kāi)源蝎困，旨在建立一個(gè)互聯(lián)網(wǎng)瀏覽器間的實(shí)時(shí)通信的平臺(tái)，讓 WebRTC技術(shù)成為 H5標(biāo)準(zhǔn)之一倍啥。我們看官網(wǎng)的介紹
從官網(wǎng)上的描述我們可以知道禾乘，WebRTC是一個(gè)免費(fèi)的開(kāi)放項(xiàng)目，它通過(guò)簡(jiǎn)單的API為瀏覽器和移動(dòng)應(yīng)用程序提供實(shí)時(shí)通信（RTC）功能虽缕。
1.2 WebRTC框架
上圖的框架對(duì)于不同的開(kāi)發(fā)人員關(guān)注點(diǎn)不同：
（1）紫色部分是Web應(yīng)用開(kāi)發(fā)者API層
（2）藍(lán)色實(shí)線部分是面向?yàn)g覽器廠商的API層
（3）藍(lán)色虛線部分瀏覽器廠商可以自定義實(shí)現(xiàn)
特別是圖中的 PeerConnection 為 Web 開(kāi)發(fā)人員提供了一個(gè)抽象始藕，從復(fù)雜的內(nèi)部結(jié)構(gòu)中抽象出來(lái)。我們只需要關(guān)注PeerConnection這個(gè)對(duì)象即可以開(kāi)發(fā)音視頻通話應(yīng)用內(nèi)。
WebRTC架構(gòu)組件介紹
Your Web App
Web開(kāi)發(fā)者開(kāi)發(fā)的程序伍派，Web開(kāi)發(fā)者可以基于集成WebRTC的瀏覽器提供的web API開(kāi)發(fā)基于視頻江耀、音頻的實(shí)時(shí)通信應(yīng)用。
Web API
面向第三方開(kāi)發(fā)者的WebRTC標(biāo)準(zhǔn)API（Javascript）诉植，使開(kāi)發(fā)者能夠容易地開(kāi)發(fā)出類似于網(wǎng)絡(luò)視頻聊天的web應(yīng)用祥国，最新的標(biāo)準(zhǔn)化進(jìn)程可以查看這里。
WebRTC Native C++ API
本地C++ API層晾腔，使瀏覽器廠商容易實(shí)現(xiàn)WebRTC標(biāo)準(zhǔn)的Web API舌稀，抽象地對(duì)數(shù)字信號(hào)過(guò)程進(jìn)行處理。
Transport / Session
傳輸/會(huì)話層
會(huì)話層組件采用了libjingle庫(kù)的部分組件實(shí)現(xiàn)灼擂，無(wú)須使用xmpp/jingle協(xié)議
VoiceEngine
音頻引擎是包含一系列音頻多媒體處理的框架壁查。
PS：VoiceEngine是WebRTC極具價(jià)值的技術(shù)之一，是Google收購(gòu)GIPS公司后開(kāi)源的剔应。在VoIP上睡腿，技術(shù)業(yè)界領(lǐng)先。
Opus：支持從6 kbit/s到510 kbit/s的恒定和可變比特率編碼领斥，幀大小從2.5 ms到60 ms嫉到，各種采樣率從8 kHz（4 kHz帶寬）到48 kHz（20 kHz帶寬沃暗，可復(fù)制人類聽(tīng)覺(jué)系統(tǒng)的整個(gè)聽(tīng)力范圍）月洛。由IETF RFC 6176定義。
NetEQ模塊是Webrtc語(yǔ)音引擎中的核心模塊 孽锥，一種動(dòng)態(tài)抖動(dòng)緩沖和錯(cuò)誤隱藏算法嚼黔，用于隱藏網(wǎng)絡(luò)抖動(dòng)和數(shù)據(jù)包丟失的負(fù)面影響。保持盡可能低的延遲惜辑，同時(shí)保持最高的語(yǔ)音質(zhì)量唬涧。
VideoEngine
WebRTC視頻處理引擎
VideoEngine是包含一系列視頻處理的整體框架，從攝像頭采集視頻到視頻信息網(wǎng)絡(luò)傳輸再到視頻顯示整個(gè)完整過(guò)程的解決方案盛撑。
VP8 視頻圖像編解碼器碎节，是WebRTC視頻引擎的默認(rèn)的編解碼器
VP8適合實(shí)時(shí)通信應(yīng)用場(chǎng)景，因?yàn)樗饕轻槍?duì)低延時(shí)而設(shè)計(jì)的編解碼器抵卫。
1.3 WebRTC發(fā)展前景
WebRTC雖然冠以“web”之名狮荔，但并不受限于傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用或?yàn)g覽器的終端運(yùn)行環(huán)境。實(shí)際上無(wú)論終端運(yùn)行環(huán)境是瀏覽器介粘、桌面應(yīng)用殖氏、移動(dòng)設(shè)備（Android或iOS）還是IoT設(shè)備，只要IP連接可到達(dá)且符合WebRTC規(guī)范就可以互通姻采。這一點(diǎn)釋放了大量智能終端（或運(yùn)行在智能終端上的app）的實(shí)時(shí)通信能力雅采，打開(kāi)了許多對(duì)于實(shí)時(shí)交互性要求較高的應(yīng)用場(chǎng)景的想象空間，譬如在線教育、視頻會(huì)議婚瓜、視頻社交宝鼓、遠(yuǎn)程協(xié)助、遠(yuǎn)程操控等等都是其合適的應(yīng)用領(lǐng)域巴刻。全球領(lǐng)先的技術(shù)研究和咨詢公司Technavio最近發(fā)布了題為“全球網(wǎng)絡(luò)實(shí)時(shí)通訊（WebRTC）市場(chǎng)席函，2017-2021”的報(bào)告。報(bào)告顯示冈涧，2017-2021年期間茂附，全球網(wǎng)絡(luò)實(shí)時(shí)通信（WebRTC）市場(chǎng)將以34.37％的年均復(fù)合增長(zhǎng)率增長(zhǎng)，增長(zhǎng)十分迅速督弓。增長(zhǎng)主要來(lái)自北美营曼、歐洲及亞太地區(qū)。
1.4 國(guó)內(nèi)方案廠商
聲網(wǎng)愚隧、即構(gòu)科技蒂阱、環(huán)信、融云等公司都在基于WebRTC二次開(kāi)發(fā)自己的音視頻通話方案狂塘。
聲網(wǎng)
即構(gòu)科技
1.5 WebRTC通話原理
首先思考的問(wèn)題：兩個(gè)不同網(wǎng)絡(luò)環(huán)境的（具備攝像頭/麥克風(fēng)多媒體設(shè)備的）瀏覽器录煤，要實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn) 的實(shí)時(shí)音視頻對(duì)話，難點(diǎn)在哪里荞胡？
1. 媒體協(xié)商
彼此要了解對(duì)方支持的媒體格式
比如：Peer-A端可支持VP8妈踊、H264多種編碼格式，而Peer-B端支持VP9泪漂、H264廊营，要保證二端都正確的編解碼，最簡(jiǎn)單的辦法就是取它們的交集H264
注：有一個(gè)專門(mén)的協(xié)議 萝勤，稱為Session Description Protocol (SDP)露筒，可用于描述上述這類信息，在WebRTC中敌卓，參與視頻通訊的雙方必須先交換SDP信息慎式，這樣雙方才能知根知底，而交換SDP的過(guò)程趟径，也稱為"媒體協(xié)商"瘪吏。
2. 網(wǎng)絡(luò)協(xié)商
彼此要了解對(duì)方的網(wǎng)絡(luò)情況，這樣才有可能找到一條相互通訊的鏈路
先說(shuō)結(jié)論：(1)獲取外網(wǎng)IP地址映射舵抹；（2）通過(guò)信令服務(wù)器（signal server）交換"網(wǎng)絡(luò)信息"
理想的網(wǎng)絡(luò)情況是每個(gè)瀏覽器的電腦都是私有公網(wǎng)IP肪虎，可以直接進(jìn)行點(diǎn)對(duì)點(diǎn)連接。
實(shí)際情況是：我們的電腦和電腦之前或大或小都是在某個(gè)局域網(wǎng)中惧蛹，需要NAT（Network Address Translation扇救，網(wǎng)絡(luò)地址轉(zhuǎn)換）刑枝，顯示情況如下圖：
在解決WebRTC使用過(guò)程中的上述問(wèn)題的時(shí)候，我們需要用到STUN和TURN迅腔。
STUN
STUN（Session Traversal Utilities for NAT装畅，NAT會(huì)話穿越應(yīng)用程序）是一種網(wǎng)絡(luò)協(xié)議，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網(wǎng)地址沧烈，查出自己位于哪種類型的NAT之后以及NAT為某一個(gè)本地端口所綁定的Internet端端口掠兄。這些信息被用來(lái)在兩個(gè)同時(shí)處于NAT路由器之后的主機(jī)之間創(chuàng)建UDP通信。該協(xié)議由RFC 5389定義锌雀。
在遇到上述情況的時(shí)候蚂夕，我們可以建立一個(gè)STUN服務(wù)器，這個(gè)服務(wù)器做什么用的呢腋逆？主要是給無(wú)法在公網(wǎng)環(huán)境下的視頻通話設(shè)備分配公網(wǎng)IP用的婿牍。這樣兩臺(tái)電腦就可以在公網(wǎng)IP中進(jìn)行通話。
使用一句話說(shuō)明STUN做的事情就是：告訴我你的公網(wǎng)IP地址+端口是什么惩歉。搭建STUN服務(wù)器很簡(jiǎn)單等脂，媒體流傳輸是按照P2P的方式。
那么問(wèn)題來(lái)了撑蚌，STUN并不是每次都能成功的為需要NAT的通話設(shè)備分配IP地址的上遥，P2P在傳輸媒體流時(shí)，使用的本地帶寬争涌，在多人視頻通話的過(guò)程中粉楚，通話質(zhì)量的好壞往往需要根據(jù)使用者本地的帶寬確定。那么怎么辦第煮？TURN可以很好的解決這個(gè)問(wèn)題解幼。
TURN
TURN的全稱為T(mén)raversal Using Relays around NAT，是STUN/RFC5389的一個(gè)拓展包警，主要添加了Relay功能。如果終端在NAT之后底靠， 那么在特定的情景下害晦，有可能使得終端無(wú)法和其對(duì)等端（peer）進(jìn)行直接的通信，這時(shí)就需要公網(wǎng)的服務(wù)器作為一個(gè)中繼暑中， 對(duì)來(lái)往的數(shù)據(jù)進(jìn)行轉(zhuǎn)發(fā)壹瘟。這個(gè)轉(zhuǎn)發(fā)的協(xié)議就被定義為T(mén)URN。
在上圖的基礎(chǔ)上鳄逾，再架設(shè)幾臺(tái)TURN服務(wù)器：
在STUN分配公網(wǎng)IP失敗后稻轨，可以通過(guò)TURN服務(wù)器請(qǐng)求公網(wǎng)IP地址作為中繼地址。這種方式的帶寬由服務(wù)器端承擔(dān)雕凹，在多人視頻聊天的時(shí)候殴俱，本地帶寬壓力較小政冻，并且，根據(jù)Google的說(shuō)明线欲，TURN協(xié)議可以使用在所有的環(huán)境中明场。（單向數(shù)據(jù)200kbps 一對(duì)一通話）
以上是WebRTC中經(jīng)常用到的2個(gè)協(xié)議，STUN和TURN服務(wù)器我們使用coturn開(kāi)源項(xiàng)目來(lái)搭建李丰。
補(bǔ)充：ICE跟STUN和TURN不一樣苦锨，ICE不是一種協(xié)議，而是一個(gè)框架（Framework）趴泌，它整合了STUN和TURN舟舒。coturn開(kāi)源項(xiàng)目集成了STUN和TURN的功能。
在WebRTC中用來(lái)描述 網(wǎng)絡(luò)信息的術(shù)語(yǔ)叫candidate嗜憔。
媒體協(xié)商 sdp
網(wǎng)絡(luò)協(xié)商 candidate
3. 媒體協(xié)商+網(wǎng)絡(luò)協(xié)商數(shù)據(jù)的交換通道
從上面1/2點(diǎn)我們知道了2個(gè)客戶端協(xié)商媒體信息和網(wǎng)絡(luò)信息魏蔗，那怎么去交換？是不是需要一個(gè)中間商去做交換痹筛？所以我們需要一個(gè)信令服務(wù)器（Signal server）轉(zhuǎn)發(fā)彼此的媒體信息和網(wǎng)絡(luò)信息莺治。
如上圖，我們?cè)诨赪ebRTC API開(kāi)發(fā)應(yīng)用（APP）時(shí)帚稠，可以將彼此的APP連接到信令服務(wù)器（Signal Server谣旁，一般搭建在公網(wǎng)，或者兩端都可以訪問(wèn)到的局域網(wǎng)）滋早，借助信令服務(wù)器榄审，就可以實(shí)現(xiàn)上面提到的SDP媒體信息及Candidate網(wǎng)絡(luò)信息交換。
信令服務(wù)器不只是交互 媒體信息sdp和網(wǎng)絡(luò)信息candidate杆麸，比如：
（1）房間管理
（2）人員進(jìn)出房間
WebRTC APIs
- MediaStream — MediaStream用來(lái)表示一個(gè)媒體數(shù)據(jù)流（通過(guò)getUserMedia接口獲雀榻），允許你訪問(wèn)輸入設(shè)備昔头，如麥克風(fēng)和 Web攝像機(jī),該 API 允許從其中任意一個(gè)獲取媒體流饼问。
- RTCPeerConnection — RTCPeerConnection 對(duì)象允許用戶在兩個(gè)瀏覽器之間直接通訊 ，你可以通過(guò)網(wǎng)絡(luò)將捕獲的音頻和視頻流實(shí)時(shí)發(fā)送到另一個(gè) WebRTC 端點(diǎn)揭斧。使用這些 Api莱革，你可以在本地機(jī)器和遠(yuǎn)程對(duì)等點(diǎn)之間創(chuàng)建連接。它提供了連接到遠(yuǎn)程對(duì)等點(diǎn)讹开、維護(hù)和監(jiān)視連接以及在不再需要連接時(shí)關(guān)閉連接的方法盅视。
4. 一對(duì)一通話
在一對(duì)一通話場(chǎng)景中，每個(gè) Peer均創(chuàng)建有一個(gè) PeerConnection 對(duì)象旦万，由一方主動(dòng)發(fā) Offer SDP闹击，另一方則應(yīng)答AnswerSDP，最后雙方交換 ICE Candidate 從而完成通話鏈路的建立成艘。但是在中國(guó)的網(wǎng)絡(luò)環(huán)境中赏半，據(jù)一些統(tǒng)計(jì)數(shù)據(jù)顯示贺归，至少1半的網(wǎng)絡(luò)是無(wú)法直接穿透打通，這種情況下只能借助TURN服務(wù)器中轉(zhuǎn)除破。
5. NAT知識(shí)補(bǔ)充
具體NAT打洞的知識(shí)在本課程不做進(jìn)一步的講解牧氮，這里提供些鏈接給大家做參考：
P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介
P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解
P2P技術(shù)詳解(三)：P2P技術(shù)之STUN瑰枫、TURN踱葛、ICE詳解
詳解P2P技術(shù)中的NAT穿透原理
