WebRTC，即Web Real-Time Communication，web實時通信技術。簡單地說就是在web浏覽器裡面引入實時通信，包括音視訊通話等。
WebRTC實時通信技術介紹
如何使用
媒體介紹
信令
STUN和TURN介紹
對等連接配接和提議/應答協商
資料通道
NAT和防火牆穿透
簡單應用
其它
WebRTC實作了基于網頁的語音對話或視訊通話，目的是無插件實作web端的實時通信的能力。
WebRTC提供了視訊會議的核心技術，包括音視訊的采集、編解碼、網絡傳輸、展示等功能，并且還支援跨平台，包括linux、windows、mac、android等。
WebRTC支援多個浏覽器參與的多方會話或會議會話，要建立這類會話有如下兩種模式：
WebRTC易于使用，隻需極少步驟便可建立媒體會話。有些消息在浏覽器和伺服器之間流動，有些則直接在兩個浏覽器（成為對等端）之間流動。
建立WebRTC連接配接需要如下幾個步驟：
擷取本地媒體（<code>getUserMedia()</code>，MediaStream API）
在浏覽器和對等端（其它浏覽器或終端）之間建立對等連接配接（RTCPeerConnection API）
将媒體和資料通道關聯至該連接配接
交換會話描述（RTCSessionDescription）
浏覽器M從Web伺服器請求網頁
Web伺服器向M傳回帶有WebRTC js的網頁
浏覽器L從Web伺服器請求網頁
Web伺服器向L傳回帶有WebRTC js的網頁
M決定與L通信，通過M自身的js将M的會話描述對象（offer，提議）發送至Web伺服器
Web伺服器将M的會話描述對象發送至L上的js
L上的js将L的會話描述對象（answer，應答）發送至Web伺服器
Web伺服器轉發應答至M上的js
M和L開始互動，确定通路對方的最佳方式
完成後，M和L開始協商通信密鑰
M和L開始交換語音、視訊或資料
WebRTC三角形會話具體的調用流程：
WebRTC梯形會話方式具體的調用流程：
先來看下WebRTC中的本地媒體：
軌道（MediaStreamTrack，代表裝置或錄制内容可傳回的單一類型的媒體，唯一關聯一個“源”，WebRTC不能直接通路或控制“源”，對“源”的一切控制都通過軌道實施；一個“源”可能對應多個軌道對象）
流（MediaStream，軌道對象的集合）
軌道和流的示意如下：
如下代碼展示了本地媒體的簡單擷取，并展示：
運作效果如下：
完整代碼檢視：https://github.com/caiya/webrtc-demo.git
在WebRTC中，信令起着舉足輕重的作用。但實作沒有标準化，比如http、websocket、xmpp等。
協商媒體功能和設定
辨別和驗證會話參與者的身份（交換SDP對象中的資訊：媒體類型、編解碼器、帶寬等中繼資料）
控制媒體會話、訓示進度、更改會話、終止會話
雙占用分解
簡單地說，信令就是協調通訊的過程，一旦信令服務建立好了，兩個用戶端之間建立了連接配接，理論上它們就可以進行點對點通訊了。
WebRTC要求在兩個對等端建立雙向的信令通道，通常有三種方式來傳輸WebRTC信令：http、websocket、資料通道
http方式如下：
websocket代理信令傳輸：
WebRTC提供了浏覽器端的P2P通信，但并不意味着WebRTC不需要伺服器。撇開應用伺服器不說，至少以下兩種伺服器是必須的：
浏覽器之間建立通信前交換各種中繼資料（信令）的伺服器（信令服務）
穿越NAT和防火牆的伺服器（stun、turn、rsip等）
WebRTC使用RTCPeerConnection建立連接配接傳送流資料，在建立RTCPeerConnection執行個體之後，想要建立點對點的信道，需要做兩件事：
确定本機上的媒體流的特性，比如分辨率、編解碼能力啥的（SDP描述符）
連接配接兩端的主機的網絡位址（ICE Candidate）
通過offer和answer交換SDP描述符：
甲和乙各自建立一個PC執行個體
甲通過PC所提供的createOffer()方法建立一個包含甲的SDP描述符的offer信令
甲通過PC所提供的setLocalDescription()方法，将甲的SDP描述符交給甲的PC執行個體
甲将offer信令通過伺服器發送給乙
乙将甲的offer信令中所包含的的SDP描述符提取出來，通過PC所提供的setRemoteDescription()方法交給乙的PC執行個體
乙通過PC所提供的createAnswer()方法建立一個包含乙的SDP描述符answer信令
乙通過PC所提供的setLocalDescription()方法，将乙的SDP描述符交給乙的PC執行個體
乙将answer信令通過伺服器發送給甲
甲接收到乙的answer信令後，将其中乙的SDP描述符提取出來，調用setRemoteDescripttion()方法交給甲自己的PC執行個體
通過ICE架構建立NAT/防火牆穿越的連接配接：
WebRTC使用ICE架構來獲得這個外界可以直接通路的位址，RTCPeerConnection在創立的時候可以将ICE伺服器的位址傳遞進去，如：
甲、乙各建立配置了ICE伺服器的PC執行個體，并為其添加onicecandidate事件回調
當網絡候選可用時，将會調用onicecandidate函數
在回調函數内部，甲或乙将網絡候選的消息封裝在ICE Candidate信令中，通過伺服器中轉，傳遞給對方
甲或乙接收到對方通過伺服器中轉所發送過來ICE Candidate信令時，将其解析并獲得網絡候選，将其通過PC執行個體的addIceCandidate()方法加入到PC執行個體中
這樣連接配接就創立完成了，可以向RTCPeerConnection中通過addStream()加入流來傳輸媒體流資料。
浏覽器位于網絡位址轉換裝置（NAT）之後是一種極為普遍的設計。舉個栗子：
再來看個圖，了解下“公共位址”和“私有位址”：
NAT主要負責維護内部ip位址和端口号與外部ip位址和端口号之間的映射表。
STUN，Session Traversal Utilities for NAT，稱為NAT會話周遊實用工具伺服器。簡單地說，就是擷取内網裝置的最外層NAT（公共ip位址）資訊。
TURN，Traversal Using Relay around NAT，稱為中繼型NAT周遊伺服器。
上一節中有簡單介紹對等連接配接和offer/answer互動流程，這節再說明下。
其實WebRTC定義了兩組主要的功能，分别是：媒體捕獲（getUserMedia()，前面已介紹）、媒體傳輸。對等連接配接和提議/應答協商的概念是媒體傳輸的核心。
RTCPeerConnection接口是WebRTC的主要API，用來在P2P端建立媒體連接配接及資料連接配接路徑。RTCPeerConnection對象的構造函數有一系列屬性，最主要的是iceServers屬性，表示伺服器位址清單。用于幫助透過NAT和防火牆建立會話。
要在二者之間建立連接配接，必須在二者之間建立會話。offer/answer是一種“一次性通過”型協商機制。實際中該過程可能會反複多次。
WebRTC使用RTCSessionDescription對象表示提議和應答。每個浏覽器都将生成一個該對象。
本地浏覽器隻關注兩個特定的調用：
生成提議、應答：
以下測試demo展示在兩個浏覽器中進行實時視訊通話，源碼位址：https://github.com/caiya/webrtc-p2p.git
RTCDataChannel，資料通道是浏覽器之間建立的非媒體的互動連接配接。即不傳遞媒體消息，繞過伺服器直接傳遞資料。相比WebSocket、http消息，資料通道支援流量大、延遲低。
隻有在建立完RTCPeerConnection執行個體之後才能建立資料通道，如下：
一端建立完資料通道後，另一端隻需要監聽ondatachannel事件即可：
此時，兩個對等端已經彼此建立資料通道，可以直接互相發送消息：
項目源代碼位址：https://github.com/caiya/webrtc-p2p-datachannel
部分截圖：
作者 @晁州
2017 年 11月 27日