官網(wǎng)永遠(yuǎn)是最重要，但同時(shí)也是最容易忽略的學(xué)習(xí)途徑。So you should look official websites firtsly.。
先看一看基礎(chǔ)概念的解釋
WebRTC 相關(guān)縮寫名詞簡(jiǎn)介
推薦一種方式，打開官方給的例子，然后通過瀏覽器調(diào)試，定位到控制到就能夠看到這個(gè)流程了。WebRTC samples
如下：
- Offer/Answer 與 Signal Channel 是什麼？
WebRTC 必須透過某種中介伺服器才能建立連線，而我們稱這種媒介為「訊號(hào)通道 (Signal Channel)」。也就是說，在建立連線之前，會(huì)先透過訊號(hào)通道交換建立連線所需的資訊。
我們所要交換的資訊就是「Offer」與「Answer」，而其內(nèi)容就是上述的 SDP。
當(dāng) Peer A 設(shè)立連線時(shí)，就會(huì)建立 Offer。接著會(huì)透過選定的訊號(hào)通道將此 Offer 傳送給 Peer B。在 Peer B 收到訊號(hào)通道傳來的 Offer 之後，就會(huì)建立 Answer，並透過同樣的訊號(hào)通道將 Answer 回傳給 Peer A。
- ICE Candidate 是什麼？
如上所述，Offer/Answer 與 SDP 用以交換多媒體的格式內(nèi)容；ICE candidate 則用以交換網(wǎng)路連線的建立方式，並可說明端點(diǎn)溝通的方法 (直接通訊，或透過 TURN 伺服器通訊)。
概述
一、WebRTC 直播時(shí)代
二、A Closer Look Into WebRTCwebkit添加新內(nèi)容
相關(guān)
一、音視頻云聲網(wǎng)Agora：從demo到實(shí)用，中間還差1萬個(gè)WebRTC
WebRtc協(xié)議棧
在這個(gè)例子中，我們將使用SIP-over-WebSocket（SIPoWS）作為信令棧。HTTP協(xié)議用于瀏覽器下載HTML5/JavaScript程序內(nèi)容；NAT棧解決P2P連接問題；媒體棧用于發(fā)送和接收RTC的音頻和視頻。
二、為什么要有打洞服務(wù)
- IPv4用完
- 私有地址一致，用了同一網(wǎng)段，不能用內(nèi)網(wǎng)地址，需要用外網(wǎng)地址。
- 在有防火墻和地址轉(zhuǎn)換時(shí)P2P需要UDP打洞：NAT后不能直接向廣域網(wǎng)那樣IP直接連接
- 不是所有 NAT 網(wǎng)絡(luò)都能打洞成功，連接就會(huì)建立失敗，只能服務(wù)器中轉(zhuǎn)。
環(huán)境搭建
一、Webrtc服務(wù)器搭建
- 通話的房間服務(wù)器(Room Server)
- 通話的信令服務(wù)器(Signaling Server)
- 防火墻打洞服務(wù)器(STUN/TURN/ICE Server)
二、iOS下音視頻通信-基于WebRTC非常全面的介紹，并且有Demo。大愛，跟著demo走一遍就熟了
嚴(yán)格來說它僅僅是不需要服務(wù)端來進(jìn)行數(shù)據(jù)中轉(zhuǎn)而已。
WebRTC至少有兩件事必須要用到服務(wù)器：
-
瀏覽器之間交換建立通信的元數(shù)據(jù)（信令）必須通過服務(wù)器。
- 我們?cè)贏和B需要建立P2P連接的時(shí)候，至少要服務(wù)器來協(xié)調(diào)，來控制連接開始建立。而連接斷開的時(shí)候，也需要服務(wù)器來告知另一端P2P連接已斷開。這些我們用來控制連接的狀態(tài)的數(shù)據(jù)稱之為信令，而這個(gè)與服務(wù)端連接的通道，對(duì)于WebRTC而言就是信令通道。
- 在建立連接之前，客戶端之間顯然沒有辦法傳遞數(shù)據(jù)。所以我們需要通過服務(wù)器的中轉(zhuǎn)，在客戶端之間傳遞這些數(shù)據(jù)，然后建立客戶端之間的點(diǎn)對(duì)點(diǎn)連接。但是WebRTC API中并沒有實(shí)現(xiàn)這些，這些就需要我們來實(shí)現(xiàn)了。
為了穿越NAT和防火墻。
WebRTC主要實(shí)現(xiàn)了三個(gè)API
- MediaStream：通過MediaStream的API能夠通過設(shè)備的攝像頭及話筒獲得視頻、音頻的同步流
- RTCPeerConnection：RTCPeerConnection是WebRTC用于構(gòu)建點(diǎn)對(duì)點(diǎn)之間穩(wěn)定、高效的流傳輸?shù)慕M件
- RTCDataChannel：RTCDataChannel使得瀏覽器之間（點(diǎn)對(duì)點(diǎn)）建立一個(gè)高吞吐量、低延時(shí)的信道，用于傳輸任意數(shù)據(jù)。
其中RTCPeerConnection是我們WebRTC的核心組件。
- P2P連接的過程
- A和B連接上服務(wù)端，建立一個(gè)TCP長(zhǎng)連接（任意協(xié)議都可以，WebSocket/MQTT/Socket原生/XMPP），我們這里為了省事，直接采用WebSocket，這樣一個(gè)信令通道就有了。
- A從ice server（STUN Server）獲取ice candidate并發(fā)送給Socket服務(wù)端，并生成包含session description（SDP）的offer，發(fā)送給Socket服務(wù)端。
- Socket服務(wù)端把A的offer和ice candidate轉(zhuǎn)發(fā)給B，B會(huì)保存下A這些信息。
- 然后B發(fā)送包含自己session description的answer(因?yàn)樗盏降氖莖ffer，所以返回的是answer，但是內(nèi)容都是SDP)和ice candidate給Socket服務(wù)端。
- Socket服務(wù)端把B的answer和ice candidate給A，A保存下B的這些信息。
三、WebRTC(iOS)下載編譯(下載指定版本)
點(diǎn)對(duì)點(diǎn)連接下，會(huì)導(dǎo)致這樣一個(gè)問題：
如果客戶端A想給客戶端B發(fā)送數(shù)據(jù)，則數(shù)據(jù)來到客戶端B所在的路由器下，會(huì)被NAT阻攔，這樣B就無法收到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阻攔了。
基礎(chǔ)概念
一、WebRTC入門教程.md
- STUN (Session Traversal Utilities for NAT) 只能UDP，告訴我暴露在廣域網(wǎng)的地址IP port ，我通過映射的廣域網(wǎng)地址進(jìn)行P2P數(shù)據(jù)通信。
- TURN( Traversal Using Relays around for NAT)UDP或TCP， 打洞失敗后，提供服務(wù)器中轉(zhuǎn)數(shù)據(jù)，通話雙方數(shù)據(jù)都通過服務(wù)器，占服務(wù)器帶寬較大 - 為了確保通話在絕大多數(shù)環(huán)境下可以正常工作。跨網(wǎng)只能用服務(wù)器中轉(zhuǎn)（測(cè)試發(fā)現(xiàn)的） ，使用TURN這種情況在視頻通話中占10%
- ICE 網(wǎng)絡(luò)連接服務(wù)
二、WebRtc建立P2P鏈接的總體流程UML類圖非常不錯(cuò)。
-
鏈接總體流程
-
時(shí)序圖
-
類圖
協(xié)議
一、NAT
NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）是1994年提出的。當(dāng)在專用網(wǎng)內(nèi)部的一些主機(jī)本來已經(jīng)分配到了本地IP地址（即僅在本專用網(wǎng)內(nèi)使用的專用地址），但現(xiàn)在又想和因特網(wǎng)上的主機(jī)通信（并不需要加密）時(shí)，可使用NAT方法。這種通過使用少量的公有IP 地址代表較多的私有IP 地址的方式，將有助于減緩可用的IP地址空間的枯竭。
- NAT實(shí)現(xiàn)方式：即靜態(tài)轉(zhuǎn)換Static Nat、動(dòng)態(tài)轉(zhuǎn)換Dynamic Nat和端口多路復(fù)用OverLoad
- NAT穿透方法：目前常用的針對(duì)UDP的NAT 穿透（NAT Traversal）方法主要有：STUN、TURN、ICE、uPnP等。其中ICE方式由于其結(jié)合了STUN和TURN的特點(diǎn)，所以使用最為廣泛。針對(duì)TCP的NAT穿透技術(shù)目前仍為難點(diǎn)。實(shí)用的技術(shù)仍然不多。
- NAT工作原理：NAT將自動(dòng)修改IP報(bào)文的源IP地址和目的IP地址，Ip地址校驗(yàn)則在NAT處理過程中自動(dòng)完成。有些應(yīng)用程序?qū)⒃碔P地址嵌入到IP報(bào)文的數(shù)據(jù)部分中，所以還需要同時(shí)對(duì)報(bào)文的數(shù)據(jù)部分進(jìn)行修改，以匹配IP頭中已經(jīng)修改過的源IP地址。否則，在報(bào)文數(shù)據(jù)部分嵌入IP地址的應(yīng)用程序就不能正常工作。簡(jiǎn)單來講就是通過一個(gè)轉(zhuǎn)換頭，將內(nèi)網(wǎng)地址變?yōu)楣W(wǎng)地址，接收的時(shí)候根據(jù)記錄將公網(wǎng)地址變成內(nèi)網(wǎng)，完成傳輸。
二、STUN
是一種網(wǎng)絡(luò)協(xié)議，它一種網(wǎng)絡(luò)協(xié)議，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網(wǎng)地址，查出自己位于哪種類型的NAT之后以及NAT為某一 個(gè)本地端口所綁定的Internet端端口。這些信息被用來在兩個(gè)同時(shí)處于NAT 路由器之后的主機(jī)之間建立UDP通信。。目的就是找到外界連接內(nèi)部地址的所需信息。
STUN是一個(gè)客戶機(jī)－服務(wù)器協(xié)議。一個(gè)VoIP電話或軟件包可能會(huì)包括一個(gè)STUN客戶端。這個(gè)客戶端會(huì)向STUN服務(wù)器發(fā)送請(qǐng)求，之后，服務(wù)器就會(huì)向STUN客戶端報(bào)告NAT路由器的公網(wǎng)IP地址以及NAT為允許傳入流量傳回內(nèi)網(wǎng)而開 通的端口。
以上的響應(yīng)同時(shí)還使得STUN客戶端能夠確定正在使用的NAT類型——因?yàn)椴煌腘AT類型處理傳入的UDP分組的方式是不同的。四種主要類型中有三種是可以使用的：完全圓錐型NAT、受限圓錐型NAT和端口受限圓錐型NAT——但大型公司網(wǎng)絡(luò)中經(jīng)常采用的對(duì)稱型 NAT（又稱為雙向NAT）則不能使用。
三、STUN和TURN技術(shù)淺析 比較全面的分析
STUN（Simple Traversal of User Datagram Protocol Through Network Address Translators），即簡(jiǎn)單的用UDP穿透NAT，是個(gè)輕量級(jí)的協(xié)議，是基于UDP的完整的穿透NAT的解決方案。它允許應(yīng)用程序發(fā)現(xiàn)它們與公共互聯(lián)網(wǎng)之間存在的NAT和防火墻及其他類型。它也可以讓應(yīng)用程序確定NAT分配給它們的公網(wǎng)IP地址和端口號(hào)。STUN是一種Client/Server的協(xié)議，也是一種Request/Response的協(xié)議，默認(rèn)端口號(hào)是3478。
在現(xiàn)實(shí)Internet網(wǎng)絡(luò)環(huán)境中，大多數(shù)計(jì)算機(jī)主機(jī)都位于防火墻或NAT之后，只有少部分主機(jī)能夠直接接入Internet。很多時(shí)候，我們希望網(wǎng)絡(luò)中的兩臺(tái)主機(jī)能夠直接進(jìn)行通信，即所謂的P2P通信，而不需要其他公共服務(wù)器的中轉(zhuǎn)。由于主機(jī)可能位于防火墻或NAT之后，在進(jìn)行P2P通信之前，我們需要進(jìn)行檢測(cè)以確認(rèn)它們之間能否進(jìn)行P2P通信以及如何通信。這種技術(shù)通常稱為NAT穿透（NAT Traversal）。最常見的NAT穿透是基于UDP的技術(shù)，如RFC3489中定義的STUN協(xié)議。
NAT對(duì)待UDP的實(shí)現(xiàn)方式有4種方式、簡(jiǎn)單可以理解為：
- 隨便搞，沒搞過的也可以搞
- 只有搞過的才能搞
- 之前帶過套的才能搞
- 只有搞得爽的才能搞
TURN，首先在RFC5766中定義，英文全稱是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中繼穿透NAT:STUN的擴(kuò)展。簡(jiǎn)單的說，TURN與STURN的共同點(diǎn)都是通過修改應(yīng)用層中的私網(wǎng)地址達(dá)到NAT穿透的效果，異同點(diǎn)是TURN是通過兩方通訊的“中間人”方式實(shí)現(xiàn)穿透。
如果一個(gè)主機(jī)位于NAT的后面，在某些情況下它不能夠與其他主機(jī)點(diǎn)對(duì)點(diǎn)直接連接。在這些情況下，它需要使用中間網(wǎng)點(diǎn)提供的中繼連接服務(wù)。TURN協(xié)議就是用來允許主機(jī)控制中繼的操作并且使用中繼與對(duì)端交換數(shù)據(jù)。TURN與其他中繼控制協(xié)議不同的是它能夠允許一個(gè)客戶端使用一個(gè)中繼地址與多個(gè)對(duì)端連接。
四、WebRTC protocols
五、SDP 協(xié)議分析
SDP 完全是一種會(huì)話描述格式 ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當(dāng)?shù)膫鬏攨f(xié)議，包括會(huì)話通知協(xié)議（SAP）、會(huì)話初始協(xié)議（SIP）、實(shí)時(shí)流協(xié)議（RTSP）、MIME 擴(kuò)展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）。SDP協(xié)議是也是基于文本的協(xié)議，這樣就能保證協(xié)議的可擴(kuò)展性比較強(qiáng)，這樣就使其具有廣泛的應(yīng)用范圍。SDP 不支持會(huì)話內(nèi)容或媒體編碼的協(xié)商，所以在流媒體中只用來描述媒體信息。
六、試驗(yàn)UDP打洞穿透NAT
比較全面的介紹了。備有例子
