什么是 WebRTC ？

WebRTC（Web Real-Time Communication）是 Google于2010以6829萬(wàn)美元從 Global IP Solutions 公司購(gòu)買(mǎi)慷蠕，并于2011年將其開(kāi)源掸冤，旨在建立一個(gè)互聯(lián)網(wǎng)瀏覽器間的實(shí)時(shí)通信的平臺(tái)厘托，讓 WebRTC技術(shù)成為 H5標(biāo)準(zhǔn)之一。我們看官網(wǎng)（?https://webrtc.org）的介紹

其中：

? ?Web Real-Time Communications (WEBRTC) W3C 組織：定義瀏覽器 API稿湿。

? ?Real-Time Communication in Web-browsers (RTCWEB) IETF 標(biāo)準(zhǔn)組織：定義其所需的協(xié)議铅匹，數(shù)據(jù)，安全性等手段饺藤。

簡(jiǎn)單來(lái)說(shuō)包斑，WebRTC是一個(gè)可以在 Web 應(yīng)用程序中實(shí)現(xiàn)音頻，視頻和數(shù)據(jù)的實(shí)時(shí)通信的開(kāi)源項(xiàng)目策精。在實(shí)時(shí)通信中舰始，音視頻的采集和處理是一個(gè)很復(fù)雜的過(guò)程。比如音視頻流的編解碼咽袜、降噪和回聲消除等丸卷，但是在 WebRTC 中，這一切都交由瀏覽器的底層封裝來(lái)完成询刹。我們可以直接拿到優(yōu)化后的媒體流谜嫉，然后將其輸出到本地屏幕和揚(yáng)聲器萎坷，或者轉(zhuǎn)發(fā)給其對(duì)等端。

點(diǎn)對(duì)點(diǎn)音視頻的難點(diǎn)

拋開(kāi)低延遲沐兰、流暢性哆档、回聲消除和海量并發(fā)這些難點(diǎn)不講，單純從功能來(lái)看住闯，打通通訊雙方的兩端瓜浸，讓彼此能正常視頻及通話(huà)比原，主要存在兩個(gè)問(wèn)題：

（1）網(wǎng)絡(luò)打通問(wèn)題--無(wú)公網(wǎng)IP無(wú)法直接通信

當(dāng)今互聯(lián)網(wǎng)到處存在著一些中間件(MIddleBoxes)插佛，如NAT和防火墻，導(dǎo)致兩個(gè)(不在同一內(nèi)網(wǎng))中的客戶(hù)端無(wú)法直接通信量窘。這些問(wèn)題即便是到了IPV6時(shí)代也會(huì)存在雇寇，因?yàn)榧词共恍枰狽AT，但還有其他中間件如防火墻阻擋了鏈接的建立蚌铜。

當(dāng)今部署的中間件大多都是在C/S架構(gòu)上設(shè)計(jì)的锨侯，其中相對(duì)隱匿的客戶(hù)機(jī)主動(dòng)向周知的服務(wù)端(擁有靜態(tài)IP地址和DNS名稱(chēng))發(fā)起鏈接請(qǐng)求。大多數(shù)中間件實(shí)現(xiàn)了一種非對(duì)稱(chēng)的通訊模型冬殃，即內(nèi)網(wǎng)中的主機(jī)可以初始化對(duì)外的鏈接囚痴，而外網(wǎng)的主機(jī)卻不能初始化對(duì)內(nèi)網(wǎng)的鏈接，除非經(jīng)過(guò)中間件管理員特殊配置造壮。在中間件為常見(jiàn)的NAPT的情況下渡讼，內(nèi)網(wǎng)中的客戶(hù)端沒(méi)有單獨(dú)的公網(wǎng)IP地址，而是通過(guò)NAPT轉(zhuǎn)換耳璧，和其他同一內(nèi)網(wǎng)用戶(hù)共享一個(gè)公網(wǎng)IP成箫。這種內(nèi)網(wǎng)主機(jī)隱藏在中間件后的不可訪(fǎng)問(wèn)性對(duì)于一些客戶(hù)端軟件如瀏覽器來(lái)說(shuō)并不是一個(gè)問(wèn)題，因?yàn)槠渲恍枰跏蓟瘜?duì)外的鏈接旨枯，從某方面來(lái)看反而還對(duì)隱私保護(hù)有好處蹬昌。然而在P2P應(yīng)用中，內(nèi)網(wǎng)主機(jī)（客戶(hù)端）需要對(duì)另外的終端（Peer）直接建立鏈接攀隔，但是發(fā)起者和響應(yīng)者可能在不同的中間件后面皂贩，兩者都沒(méi)有公網(wǎng)IP地址。而外部對(duì)NAT公網(wǎng)IP和端口主動(dòng)的鏈接或數(shù)據(jù)都會(huì)因內(nèi)網(wǎng)未請(qǐng)求被丟棄掉昆汹。對(duì)于WebRTC來(lái)說(shuō)明刷，首先要解決的是如果跨越NAT實(shí)現(xiàn)內(nèi)網(wǎng)主機(jī)直接通訊的問(wèn)題。

（2）媒體格式編碼問(wèn)題--媒體格式編碼多樣不統(tǒng)一

對(duì)于需要音視頻通信的雙方满粗，彼此要了解對(duì)方支持的媒體格式才能正常地對(duì)流媒體編解碼辈末。比如，Peer-A端可支持VP8、H264多種編碼格式挤聘，而Peer-B端支持VP9轰枝、H264，要保證二端都正確的編解碼组去，最簡(jiǎn)單的辦法就是取它們的交集H264鞍陨。有一個(gè)專(zhuān)門(mén)的協(xié)議稱(chēng)為SDP（Session Description Protoco），可用于描述上述這類(lèi)信息从隆，在WebRTC中诚撵，參與視頻通訊的雙方必須先交換SDP信息，這樣雙方才能知根知底广料，而交換SDP的過(guò)程砾脑，也稱(chēng)為“媒體協(xié)商”

SDP(Session Description Protocol) 是一種會(huì)話(huà)描述協(xié)議幼驶，基于文本艾杏，其本身并不屬于傳輸協(xié)議，需要依賴(lài)其它的傳輸協(xié)議（比如 SIP 和 HTTP）來(lái)交換必要的媒體信息盅藻，用于兩個(gè)會(huì)話(huà)實(shí)體之間的媒體協(xié)商购桑。SDP(會(huì)話(huà)描述協(xié)議)定義了一個(gè)標(biāo)準(zhǔn)，用于定義兩個(gè)（通常）端與端之間媒體（通常是流媒體）交換的參數(shù)氏淑。IETF已將其發(fā)布為RFC 4566勃蜘。SDP通常嵌入或封裝在另一個(gè)協(xié)議中，最廣泛使用的應(yīng)用程序位于大多數(shù)IP電話(huà)應(yīng)用程序的SIP協(xié)議內(nèi)部假残。簡(jiǎn)單地說(shuō)缭贡，SDP協(xié)議是媒體端到端對(duì)其接收規(guī)范和能力的聲明；典型的聲明會(huì)告訴我們：

（1）哪個(gè)IP地址準(zhǔn)備好接收傳入的媒體流

（2）哪個(gè)端口號(hào)正在偵聽(tīng)傳入的媒體流

（3）端點(diǎn)希望接收的媒體類(lèi)型（通常是音頻）

（4）端點(diǎn)希望在哪個(gè)協(xié)議中交換信息（通常為RTP）

（5）端點(diǎn)能夠解碼的壓縮編碼（編解碼器）

在一個(gè)典型的會(huì)話(huà)設(shè)置過(guò)程中辉懒，我們會(huì)看到兩個(gè)端點(diǎn)參與一個(gè)會(huì)話(huà)阳惹，其中每個(gè)端點(diǎn)發(fā)送一個(gè)SDP以通知另一個(gè)端點(diǎn)其規(guī)范和功能。SDP本身不提供任何媒體眶俩，但僅限于協(xié)商一組兼容的媒體交換參數(shù)莹汤；媒體流本身由不同的通道和協(xié)議處理。

一個(gè) SDP 的握手由一個(gè) offer 和一個(gè) answer 組成

WebRTC通話(huà)原理

點(diǎn)對(duì)點(diǎn)的雙方為了實(shí)現(xiàn)實(shí)時(shí)音視頻通信颠印， WebRTC需要解決媒體協(xié)商和網(wǎng)絡(luò)協(xié)商問(wèn)題纲岭，這里要引入信令服務(wù)器(Signaling Server)和STUN server

Signaling Server

需要通信的雙方之間建立WebRTC連接需要一個(gè)?信令服務(wù)器?來(lái)實(shí)現(xiàn)雙方通過(guò)網(wǎng)絡(luò)進(jìn)行連接。信令服務(wù)器的作用是作為一個(gè)中間人幫助雙方在盡可能少的暴露隱私的情況下建立連接线罕。WebRTC并沒(méi)有提供信令傳遞機(jī)制止潮，信令的傳遞和交換需要服務(wù)器參與，這個(gè)角色就是信令服務(wù)器钞楼。WebRTC信令指建立喇闸、控制和終止通信會(huì)話(huà)的過(guò)程以及業(yè)務(wù)本身的需求來(lái)看，需要交換幾個(gè)信息：媒體信息，網(wǎng)絡(luò)信息仅偎，具體業(yè)務(wù)跨蟹。

**一、**媒體信息

需要媒體數(shù)據(jù)來(lái)確定呼叫者和被呼叫者共有的編解碼器和媒體類(lèi)型橘沥。如果嘗試啟動(dòng)通信會(huì)話(huà)的端具有不同的分辨率和編解碼器配置窗轩，則會(huì)話(huà)不太可能成功。通過(guò)使用會(huì)話(huà)描述協(xié)議（SDP）格式的提供和應(yīng)答在對(duì)等方之間交換媒體配置信息的信令座咆，這些信息是通過(guò)SDP協(xié)議描述出來(lái)痢艺，通過(guò)信令服務(wù)器中轉(zhuǎn)的。

**二介陶、**網(wǎng)絡(luò)信息

兩個(gè)WebRTC客戶(hù)端如何發(fā)現(xiàn)對(duì)方的堤舒？通過(guò)信令服務(wù)器交互雙方在Internet上的位置（IP地址和端口），以便呼叫者可以找到被呼叫者哺呜。

**三舌缤、**具體業(yè)務(wù)

**會(huì)話(huà)控制信息確定何時(shí)初始化、關(guān)閉和修改通信會(huì)話(huà)某残，比如加入房間国撵，離開(kāi)房間，禁言玻墅，媒體流訂閱發(fā)布等功能介牙，需要信令服務(wù)器來(lái)控制。

**STUN server **

STUN?（Session Traversal Utilities for NAT?澳厢，NAT會(huì)話(huà)穿越應(yīng)用程序）是一種?網(wǎng)絡(luò)協(xié)議环础，它允許位于?NAT**（或多重NAT）后的客戶(hù)端找出自己的公網(wǎng)地址，查出自己位于哪種類(lèi)型的NAT之后以及NAT為某一個(gè)本地端口所綁定的Internet端端口剩拢。這些信息被用來(lái)在兩個(gè)同時(shí)處于NAT路由器之后的主機(jī)之間建立UDP通信线得。該協(xié)議由RFC 5389定義。****STUN 是 C/S 模式的協(xié)議裸扶，可以簡(jiǎn)單理解為：由客戶(hù)端發(fā)送 STUN 請(qǐng)求框都；STUN 服務(wù)響應(yīng)，告知由 NAT 分配給主機(jī)的 IP 地址和端口號(hào)呵晨。一旦擁有了ip和端口魏保，點(diǎn)對(duì)點(diǎn)通信的雙方就能直連通信了。（注：以上的響應(yīng)同時(shí)還使得STUN客戶(hù)端能夠確定正在使用的?NAT類(lèi)型——因?yàn)椴煌腘AT類(lèi)型處理傳入的UDP分組的方式是不同的摸屠。四種主要類(lèi)型中有三種是可以使用的：?完全圓錐型NAT?谓罗、?受限圓錐型NAT和?端口受限圓錐型NAT?——但大型公司網(wǎng)絡(luò)中經(jīng)常采用的對(duì)稱(chēng)型NAT（又稱(chēng)為雙向NAT）則不能使用，這時(shí)TURN就要登場(chǎng)了季二，本文暫且不講）

專(zhuān)有名詞介紹

Signaling Server ：信令服務(wù)器檩咱，負(fù)責(zé)處理通信雙方的信息交互揭措，包括媒體信息，網(wǎng)絡(luò)信息刻蚯，業(yè)務(wù)信息绊含。

STUN server：STUN的全稱(chēng)是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)， 即穿越NAT的簡(jiǎn)單UDP傳輸炊汹，是一個(gè)輕量級(jí)的協(xié)議躬充。可以簡(jiǎn)單理解為：由客戶(hù)端發(fā)送 STUN 請(qǐng)求讨便；STUN 服務(wù)響應(yīng)充甚，告知由 NAT 分配給主機(jī)的 IP 地址和端口號(hào)。

SDP：Session Description Protocol 為了連接到對(duì)端用戶(hù)霸褒，我們必須要對(duì)其他用戶(hù)的設(shè)備情況有所了解伴找，比如音頻視頻的編碼解碼器、使用何種編碼格式废菱、使用何種網(wǎng)絡(luò)技矮、設(shè)備的數(shù)據(jù)處理能力，昙啄，而 SDP 為我們提供了這些功能

ICE：Interactive Connectivity Establishment 通信的兩側(cè)可能會(huì)處于不同的網(wǎng)絡(luò)環(huán)境中穆役，有時(shí)會(huì)存在好幾層的訪(fǎng)問(wèn)控制、防火墻梳凛、路由跳轉(zhuǎn)，所以我們需要一種方法在復(fù)雜的網(wǎng)絡(luò)環(huán)境中找到對(duì)方梳杏，并且連接到相應(yīng)的目標(biāo)韧拒。WebRTC 使用了集成了 STUN、TURN 的 ICE 來(lái)進(jìn)行雙方的數(shù)據(jù)通信十性。

offer叛溢、answer：一個(gè) SDP 的握手由一個(gè) offer 和一個(gè) answer 組成，一方發(fā)送offer劲适，另一方接收到offer后楷掉，發(fā)送answer。

**WebRTC音視頻通信流程

**

在同一房間的雙方通過(guò)WebRTC建立音視頻通信霞势，主要分為四個(gè)階段：

（一）加入房間烹植、呼叫對(duì)方，對(duì)方應(yīng)答

** **（1）ClientA登錄后連接信令服務(wù)器愕贡，選擇進(jìn)入某個(gè)房間草雕；

** **（1）ClientB登錄后連接信令服務(wù)器，選擇進(jìn)入某個(gè)房間固以；（1）（2）不分先后

** **（3）ClientA 在此房間中看到ClientB在線(xiàn)墩虹，選擇呼叫ClientB嘱巾；

** **（4）ClientB選擇同意接聽(tīng)； （3）（4）中的ClientA和ClientB可以互換诫钓；

（二）交換SDP旬昭，發(fā)送/接收offer，發(fā)送/接收answer

** **（1）ClientA 執(zhí)行g(shù)etUserMedia() ->new RTCPeerConnection->Peer.addStream->createOffer

** **（2）ClientB 執(zhí)行g(shù)etUserMedia() ->new RTCPeerConnection->Peer.addStream菌湃；（1）（2）并行執(zhí)行稳懒；

** **（3）ClientA通過(guò)信令服務(wù)器中轉(zhuǎn)offer給ClientB；

** **（4）ClientB收到offer后慢味，setRemoteDescription->createAnswer场梆；并通過(guò)信令服務(wù)器中轉(zhuǎn)answer給ClientA；

** **（5）ClientA收到answer后顶岸，setRemoteDescription；

（三）交換ICE candidate

** ****（1）ClientA 向STUN Server請(qǐng)求ICE（請(qǐng)求可能在之前某個(gè)時(shí)候已經(jīng)發(fā)出）叫编，STUN Server返回ICE candidate **

** ****（2）ClientB 向STUN Server請(qǐng)求ICE（請(qǐng)求可能在之前某個(gè)時(shí)候已經(jīng)發(fā)出）辖佣，STUN Server返回ICE candidate **

** **（3）ClientA通過(guò)信令服務(wù)器中轉(zhuǎn)ICE candidate到達(dá)ClientB；ClientB通過(guò)信令服務(wù)器中轉(zhuǎn)ICE candidate到達(dá)ClientA霞篡；

** **（4）ClientA收到B的ICE canditate世蔗，addIceCandidate

** **（5）ClientB收到A的ICE canditate，addIceCandidate

（四）開(kāi)始音視頻通信

** **（1）ClientA addStream 展示對(duì)方遠(yuǎn)程音視頻流朗兵；

** **（2）ClientA addStream 展示對(duì)方遠(yuǎn)程音視頻流污淋；