目錄概述P2P連接模式WebRTC的服務(wù)器與信令WebRTC的NAT/防火墻穿越技術(shù)概述

它在2011年5月開(kāi)放了工程的源代碼，在行業(yè)內(nèi)得到了廣泛的支持和應(yīng)用，成為下一代視頻通話的標(biāo)準(zhǔn)。

WebRTC的音視頻通信是基于P2P，那么什么是P2P呢？

它是點(diǎn)對(duì)點(diǎn)連接的英文縮寫(xiě)。

P2P連接模式

一般我們傳統(tǒng)的連接方式，都是以服務(wù)器為中介的模式：

類似http協(xié)議：客戶端?服務(wù)端（當(dāng)然這里服務(wù)端返回的箭頭僅僅代表返回請(qǐng)求數(shù)據(jù)）。

我們?cè)谶M(jìn)行即時(shí)通訊時(shí)，進(jìn)行文字、圖片、錄音等傳輸?shù)臅r(shí)候：客戶端A?服務(wù)器?客戶端B。

而點(diǎn)對(duì)點(diǎn)的連接恰恰數(shù)據(jù)通道一旦形成，中間是不經(jīng)過(guò)服務(wù)端的，數(shù)據(jù)直接從一個(gè)客戶端流向另一個(gè)客戶端：

客戶端A?客戶端B ... 客戶端A?客戶端C ...（可以無(wú)數(shù)個(gè)客戶端之間互聯(lián)）

這里可以想想音視頻通話的應(yīng)用場(chǎng)景，我們服務(wù)端確實(shí)是沒(méi)必要去獲取兩者通信的數(shù)據(jù)，而且這樣做有一個(gè)最大的一個(gè)優(yōu)點(diǎn)就是，大大的減輕了服務(wù)端的壓力。

而WebRTC就是這樣一個(gè)基于P2P的音視頻通信技術(shù)。

WebRTC的服務(wù)器與信令

講到這里，可能大家覺(jué)得WebRTC就不需要服務(wù)端了么？這是顯然是錯(cuò)誤的認(rèn)識(shí)，嚴(yán)格來(lái)說(shuō)它僅僅是不需要服務(wù)端來(lái)進(jìn)行數(shù)據(jù)中轉(zhuǎn)而已。

WebRTC提供了瀏覽器到瀏覽器（點(diǎn)對(duì)點(diǎn)）之間的通信，但并不意味著WebRTC不需要服務(wù)器。暫且不說(shuō)基于服務(wù)器的一些擴(kuò)展業(yè)務(wù)，WebRTC至少有兩件事必須要用到服務(wù)器：

瀏覽器之間交換建立通信的元數(shù)據(jù)（信令）必須通過(guò)服務(wù)器。 為了穿越NAT和防火墻。

第1條很好理解，我們?cè)贏和B需要建立P2P連接的時(shí)候，至少要服務(wù)器來(lái)協(xié)調(diào)，來(lái)控制連接開(kāi)始建立。而連接斷開(kāi)的時(shí)候，也需要服務(wù)器來(lái)告知另一端P2P連接已斷開(kāi)。這些我們用來(lái)控制連接的狀態(tài)的數(shù)據(jù)稱之為信令，而這個(gè)與服務(wù)端連接的通道，對(duì)于WebRTC而言就是信令通道。

圖中signalling就是往服務(wù)端發(fā)送信令，然后底層調(diào)用WebRTC，WebRTC通過(guò)服務(wù)端得到的信令，得知通信對(duì)方的基本信息，從而實(shí)現(xiàn)虛線部分Media通信連接。

當(dāng)然信令能做的事還有很多，這里大概列了一下：

用來(lái)控制通信開(kāi)啟或者關(guān)閉的連接控制消息 發(fā)生錯(cuò)誤時(shí)用來(lái)彼此告知的消息 媒體流元數(shù)據(jù)，比如像解碼器、解碼器的配置、帶寬、媒體類型等等 用來(lái)建立安全連接的關(guān)鍵數(shù)據(jù) 外界所看到的的網(wǎng)絡(luò)上的數(shù)據(jù)，比如IP地址、端口等

在建立連接之前，客戶端之間顯然沒(méi)有辦法傳遞數(shù)據(jù)。所以我們需要通過(guò)服務(wù)器的中轉(zhuǎn)，在客戶端之間傳遞這些數(shù)據(jù)，然后建立客戶端之間的點(diǎn)對(duì)點(diǎn)連接。但是WebRTC API中并沒(méi)有實(shí)現(xiàn)這些，這些就需要我們來(lái)實(shí)現(xiàn)了。

而第2條中的NAT這個(gè)概念，參考文章iOS即時(shí)通訊，從入門到“放棄”？，中也提到過(guò)，不過(guò)是為了應(yīng)對(duì)NAT超時(shí)，所造成的TCP連接中斷。在這里我們就不展開(kāi)去講了，感興趣的可以看看：NAT百科

這里我簡(jiǎn)要說(shuō)明一下，NAT技術(shù)的出現(xiàn)，其實(shí)就是為了解決IPV4下的IP地址匱乏。舉例來(lái)說(shuō)，就是通常我們處在一個(gè)路由器之下，而路由器分配給我們的地址通常為192.168.0.1 、192.168.0.2如果有n個(gè)設(shè)備，可能分配到192.168.0.n，而這個(gè)IP地址顯然只是一個(gè)內(nèi)網(wǎng)的IP地址，這樣一個(gè)路由器的公網(wǎng)地址對(duì)應(yīng)了n個(gè)內(nèi)網(wǎng)的地址，通過(guò)這種使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助于減緩可用的IP地址空間的枯竭。

但是這也帶來(lái)了一系列的問(wèn)題，例如這里點(diǎn)對(duì)點(diǎn)連接下，會(huì)導(dǎo)致這樣一個(gè)問(wèn)題：

如果客戶端A想給客戶端B發(fā)送數(shù)據(jù)，則數(shù)據(jù)來(lái)到客戶端B所在的路由器下，會(huì)被NAT阻攔，這樣B就無(wú)法收到A的數(shù)據(jù)了。

但是A的NAT此時(shí)已經(jīng)知道了B這個(gè)地址，所以當(dāng)B給A發(fā)送數(shù)據(jù)的時(shí)候，NAT不會(huì)阻攔，這樣A就可以收到B的數(shù)據(jù)了。這就是我們進(jìn)行NAT穿越的核心思路。

于是我們就有了以下思路：

我們借助一個(gè)公網(wǎng)IP服務(wù)器,a,b都往公網(wǎng)IP/PORT發(fā)包,公網(wǎng)服務(wù)器就可以獲知a,b的IP/PORT，又由于a,b主動(dòng)給公網(wǎng)IP服務(wù)器發(fā)包，所以公網(wǎng)服務(wù)器可以穿透NAT A,NAT B送包給a,b。

所以只要公網(wǎng)IP將b的IP/PORT發(fā)給a,a的IP/PORT發(fā)給b。這樣下次a和b互相消息，就不會(huì)被NAT阻攔了。

WebRTC的NAT/防火墻穿越技術(shù)

基于上述的一個(gè)思路來(lái)實(shí)現(xiàn)的：

建立點(diǎn)對(duì)點(diǎn)信道的一個(gè)常見(jiàn)問(wèn)題，就是NAT穿越技術(shù)。在處于使用了NAT設(shè)備的私有TCP/IP網(wǎng)絡(luò)中的主機(jī)之間需要建立連接時(shí)需要使用NAT穿越技術(shù)。以往在VoIP領(lǐng)域經(jīng)常會(huì)遇到這個(gè)問(wèn)題。目前已經(jīng)有很多NAT穿越技術(shù)，但沒(méi)有一項(xiàng)是完美的，因?yàn)镹AT的行為是非標(biāo)準(zhǔn)化的。這些技術(shù)中大多使用了一個(gè)公共服務(wù)器，這個(gè)服務(wù)使用了一個(gè)從全球任何地方都能訪問(wèn)得到的IP地址。在RTCPeeConnection中，使用ICE框架來(lái)保證RTCPeerConnection能實(shí)現(xiàn)NAT穿越

這里提到了ICE協(xié)議框架，它大約是由以下幾個(gè)技術(shù)和協(xié)議組成的：STUN、NAT、TURN、SDP，這些協(xié)議技術(shù)，幫助ICE共同實(shí)現(xiàn)了NAT/防火墻穿越。

以上就是詳解IOS WebRTC的實(shí)現(xiàn)原理的詳細(xì)內(nèi)容，更多關(guān)于IOS WebRTC的實(shí)現(xiàn)原理的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！