WebRTC入門

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WebRTC入門


??WebRTC的歷史

Web的最后一個(gè)主要挑戰(zhàn)之一是通過語音和視頻實(shí)現(xiàn)人與人之間的通信:實(shí)時(shí)通信,簡稱RTC。RTC在Web應(yīng)用程序中應(yīng)與在文本輸入中輸入文本一樣自然。沒有它,我們?cè)趧?chuàng)新和開發(fā)新的人們互動(dòng)方式方面的能力將受到限制。

從歷史上看,RTC一直是公司性的并且很復(fù)雜,需要昂貴的音頻和視頻技術(shù)才能在內(nèi)部獲得許可或開發(fā)。將RTC技術(shù)與現(xiàn)有內(nèi)容,數(shù)據(jù)和服務(wù)集成在一起非常困難且耗時(shí),尤其是在Web上。

Gmail視頻聊天在2008年開始流行,2011年Google引入了環(huán)聊,該環(huán)聊使用Google Talk服務(wù)(與Gmail一樣)。Google收購了GIPS,這是一家開發(fā)了RTC所需的許多組件的公司,例如編解碼器和回聲消除技術(shù)。Google開源了GIPS開發(fā)的技術(shù),并與IETF和W3C的相關(guān)標(biāo)準(zhǔn)機(jī)構(gòu)合作,以確保行業(yè)共識(shí)。2011年5月,愛立信構(gòu)建了WebRTC的第一個(gè)實(shí)現(xiàn)。

WebRTC為實(shí)時(shí),無插件的視頻,音頻和數(shù)據(jù)通信實(shí)施了開放標(biāo)準(zhǔn)。需求是真實(shí)的:

許多Web服務(wù)使用RTC,但需要下載,本機(jī)應(yīng)用程序或插件。包括Skype,F(xiàn)acebook和Google Hangouts。

下載,安裝和更新插件非常復(fù)雜,容易出錯(cuò)且令人討厭。

插件很難部署,調(diào)試,故障排除,測(cè)試和維護(hù),并且可能需要許可以及與復(fù)雜,昂貴的技術(shù)的集成。首先說服人們安裝插件通常很困難!

WebRTC項(xiàng)目的指導(dǎo)原則是其API應(yīng)該是開源的,免費(fèi)的,標(biāo)準(zhǔn)化的,內(nèi)置在Web瀏覽器中的,并且比現(xiàn)有技術(shù)更有效。

我們現(xiàn)在在哪?

WebRTC用于各種應(yīng)用程序,例如WhatsApp,F(xiàn)acebook Messenger,appear.in和TokBox等平臺(tái)。WebRTC也已與WebKitGTK +Qt本機(jī)應(yīng)用程序集成。

WebRTC實(shí)現(xiàn)了三個(gè)API:

*MediaStream(又名getUserMedia)

*RTCPeerConnection

*RTCDataChannel

API在兩個(gè)規(guī)范中定義:

*WebRTC

*getUserMedia

Chrome,Safari,F(xiàn)irefox,Edge和Opera在移動(dòng)設(shè)備和臺(tái)式機(jī)上都支持這三種API。

getUserMedia:訪問數(shù)據(jù)流,例如來自用戶的相機(jī)和麥克風(fēng)的數(shù)據(jù)流。

RTCPeerConnection:是WebRTC組件,用于處理對(duì)等點(diǎn)之間的流數(shù)據(jù)的穩(wěn)定和高效的通信。音頻或視頻呼叫,具有用于加密和帶寬管理的功能。

RTCDataChannel:除了音頻和視頻,WebRTC還支持其他類型數(shù)據(jù)的實(shí)時(shí)通信。RTCDataChannel API支持低延遲和高吞吐量的對(duì)等數(shù)據(jù)交換。通用數(shù)據(jù)的對(duì)等通信。

我的第一個(gè)WebRTC

WebRTC應(yīng)用程序需要做幾件事:

獲取流音頻,視頻或其他數(shù)據(jù)。

獲取諸如IP地址和端口之類的網(wǎng)絡(luò)信息,并與其他WebRTC客戶端(稱為對(duì)等方)進(jìn)行交換,以啟用連接,即使通過NAT和防火墻也是如此。

協(xié)調(diào)信令通信以報(bào)告錯(cuò)誤并啟動(dòng)或關(guān)閉會(huì)話。

交換有關(guān)媒體和客戶端功能的信息,例如分辨率和編解碼器。

交流流音頻,視頻或數(shù)據(jù)。

為了獲取和傳遞流數(shù)據(jù),WebRTC實(shí)現(xiàn)了以下API:

MediaStream:訪問數(shù)據(jù)流,例如來自用戶的相機(jī)和麥克風(fēng)的數(shù)據(jù)流。

RTCPeerConnection:音頻或視頻呼叫,具有用于加密和帶寬管理的功能。

RTCDataChannel:通用數(shù)據(jù)的對(duì)等通信。

信令:會(huì)話控制,網(wǎng)絡(luò)和媒體信息


WebRTC使用RTCPeerConnection在瀏覽器(也稱為對(duì)等設(shè)備)之間通信流數(shù)據(jù),但還需要一種機(jī)制來協(xié)調(diào)通信并發(fā)送控制消息,該過程稱為信令。WebRTC?指定信令方法和協(xié)議:信令不是RTCPeerConnection API的一部分

相反,WebRTC應(yīng)用程序開發(fā)人員可以選擇他們喜歡的任何消息協(xié)議,例如SIP或XMPP,以及任何適當(dāng)?shù)碾p工(雙向)通信通道。

信令用于交換三種類型的信息:

會(huì)話控制消息:初始化或關(guān)閉通信并報(bào)告錯(cuò)誤。

網(wǎng)絡(luò)配置:對(duì)于外界,我的計(jì)算機(jī)的IP地址和端口是什么?

媒體功能:我的瀏覽器及其要與之通信的瀏覽器可以處理哪些編解碼器和分辨率?

在開始對(duì)等流傳輸之前,必須成功完成通過信令進(jìn)行的信息交換。

1. 客戶端通過信令服務(wù)器, 進(jìn)行offer SDP 握手

SDP(Session Description Protocol):描述建立音視頻連接的一些屬性,如音頻的編碼格式、視頻的編碼格式、是否接收/發(fā)送音視頻等等SDP 是通過webrtc框架里面的PeerConnection所創(chuàng)建

2. 客戶端通過信令服務(wù)器, 進(jìn)行Candidate 握手

Candidate:主要包含了相關(guān)方的IP信息,包括自身局域網(wǎng)的ip、公網(wǎng)ip、turn服務(wù)器ip、stun服務(wù)器ip等Candidate 是通過webrtc框架里面的PeerConnection所創(chuàng)建 ?

3 客戶端在SDP 和Candidate握手成功后, 就建立起一個(gè)P2P端對(duì)端的鏈接, 視頻流就能直接傳輸, 不需要經(jīng)過服務(wù)器啦

P2P信息會(huì)話

1.Amy端通過 createOffer 生成 SDP 描述

2.Amy通過 setLocalDescription,設(shè)置本地的描述信息

3.Amy將 offer SDP 發(fā)送給用戶Bob

4.用戶Bob通過 setRemoteDescription,設(shè)置遠(yuǎn)端的描述信息

5.Bob用戶通過 createAnswer 創(chuàng)建出自己的 SDP 描述

6.Bob用戶通過 setLocalDescription,設(shè)置本地的描述信息

7.Bob用戶將 anwser SDP 發(fā)送給主播Amy

8.Amy端通過 setRemoteDescription,設(shè)置遠(yuǎn)端的描述信息。

9.通過SDP握手后,兩端之間就會(huì)建立起一個(gè)端對(duì)端的直接通訊通道。

由于我們所處的網(wǎng)絡(luò)環(huán)境錯(cuò)綜復(fù)雜,用戶可能處在私有內(nèi)網(wǎng)內(nèi),使用p2p傳輸時(shí),將會(huì)遇到NAT以及防火墻等阻礙。這個(gè)時(shí)候我們就需要在SDP握手時(shí),通過STUN/TURN/ICE相關(guān)NAT穿透技術(shù)來保障p2p鏈接的建立

RTCPeerConnection

RTCPeerConnection是WebRTC組件,用于處理對(duì)等點(diǎn)之間的流數(shù)據(jù)的穩(wěn)定和高效的通信。

下面是WebRTC架構(gòu)圖,顯示了RTCPeerConnection的角色。您會(huì)注意到,綠色部分很復(fù)雜!


WebRTC架構(gòu)

從該圖中可以理解的主要事情是RTCPeerConnection使Web開發(fā)人員免受潛在的各種復(fù)雜問題的困擾。WebRTC使用的編解碼器和協(xié)議進(jìn)行了大量工作,即使在不可靠的網(wǎng)絡(luò)上也可以進(jìn)行實(shí)時(shí)通信:

丟包隱藏 回聲消除 帶寬適應(yīng)性 動(dòng)態(tài)抖動(dòng)緩沖 自動(dòng)增益控制 降噪抑制 圖像“清潔”。

RTCPeerConnection plus服務(wù)器

在現(xiàn)實(shí)世界中,WebRTC需要服務(wù)器(無論多么簡單),因此可能發(fā)生以下情況:

* 用戶彼此發(fā)現(xiàn)并交換“真實(shí)世界”的詳細(xì)信息,例如姓名。

* WebRTC客戶端應(yīng)用程序(對(duì)等)交換網(wǎng)絡(luò)信息。

* 對(duì)等方交換有關(guān)媒體的數(shù)據(jù),例如視頻格式和分辨率。

* WebRTC客戶端應(yīng)用程序遍歷NAT網(wǎng)關(guān)和防火墻。

換句話說,WebRTC需要四種服務(wù)器端功能:

用戶發(fā)現(xiàn)和交流。

發(fā)信號(hào)。

NAT /防火墻遍歷。

對(duì)等通信失敗時(shí)中繼服務(wù)器。

NAT遍歷,對(duì)等網(wǎng)絡(luò)以及為用戶發(fā)現(xiàn)和信令構(gòu)建服務(wù)器應(yīng)用程序的要求不在本文討論范圍之內(nèi)??梢哉fICE框架使用STUN協(xié)議及其擴(kuò)展TURN來使RTCPeerConnection能夠應(yīng)對(duì)NAT穿越和其他網(wǎng)絡(luò)問題。

ICE是用于連接對(duì)等方(例如兩個(gè)視頻聊天客戶端)的框架。最初,ICE嘗試通過UDP以盡可能短的延遲直接連接同級(jí)。在此過程中,STUN服務(wù)器只有一項(xiàng)任務(wù):使NAT后的對(duì)等方能夠找到其公共地址和端口。


尋找連接候選者

如果UDP失敗,ICE將嘗試TCP。如果直接連接失?。ㄓ绕涫怯捎谄髽I(yè)NAT穿越和防火墻),ICE將使用中間(中繼)TURN服務(wù)器。換句話說,ICE將首先使用帶有UDP的STUN直接連接對(duì)等方,如果失敗,將回退到TURN中繼服務(wù)器?!皩ふ液蜻x對(duì)象”一詞是指查找網(wǎng)絡(luò)接口和端口的過程


WebRTC數(shù)據(jù)通路

RTCDataChannel

除了音頻和視頻,WebRTC還支持其他類型數(shù)據(jù)的實(shí)時(shí)通信。RTCDataChannel API支持低延遲和高吞吐量的對(duì)等數(shù)據(jù)交換。

該API有很多潛在的用例

遠(yuǎn)程桌面應(yīng)用程序?實(shí)時(shí)文字聊天?文件傳輸?分散網(wǎng)絡(luò)

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

友情鏈接更多精彩內(nèi)容