參考文章：
架構：
經典三層結構：
- Web app 層(應用層)：Web開發者開發的程序，Web開發者可以基於集成WebRTC的瀏覽器提供的web API開發基於視頻、音頻的實時通信應用。
- Web api 層：面向第三方開發者的WebRTC標準API（Javascript），使開發者能夠容易地開發出類似於網絡視頻聊天的web應用，需要注意的是可能在不同瀏覽器中API接口名會不太一樣, 所以推薦使用這個JS適配器 來協調各個瀏覽器的不同接口。 這些API可分成Media API、 RTCPeerConnection、Peer-to-peer Data API三類:
- Media API：MediaStream用來表示一個媒體數據流。 MediaStreamTrack：在瀏覽器中表示一個媒體源。
- RTCPeerConnection：一個RTCPeerConnection對象允許用戶在兩個瀏覽器之間直接通訊，代表一個由本地計算機到遠端的 WebRTC 連接。該 API 提供了創建，保持，監控，關閉連接的方法的實現。包括 SDP、RTCIceCandidate、RTCIceServer 等概念，詳見下文基礎概念部分。
- SDP: 用來描述當前連接者想要傳輸的內容，支持的協議類型，支持的編解碼類型等。
- RTCIceCandidate：一個ICE協議的候選者，簡單講，就是目標節點的IP以及端口。
- RTCIceServer：表示一個ICE Server，其主要用於當前主機的IP發現，通過和ICE Server通訊，我們會得到一組可供連接使用的 IP:Port 候選值，雙方通過交換ICE候選值來建立起連接。
-
Peer-to-peer Data API：數據通道(DataChannel)接口表示一個在兩個節點之間的雙向的數據通道，該通道可以設置成可靠傳輸或非可靠傳輸。
-
WebRTC 核心層
-
WebRTC C C++ API (PeerConnection): 這層的API相對比較少，最主要就是實現P2P連接。在PeerConnection裏面又包含了很多接口，如傳輸質量，傳輸質量報告，統計數據，各種流都是封裝在PeerConnection模塊裏面。除此之外主要有音視頻採集，音視頻傳輸，非音視頻數據傳輸等。
- Session Management/ Abstract signaling (Session): 會話層，進行會話功能管理，用來管理音視頻，非音視頻數據傳輸，處理相關邏輯
- 最核心的第三層，包含：音頻引擎，視頻引擎，傳輸，三大核心模塊。
- 最底層是與硬件相關的硬件適配層：這層包含：音頻的採集和渲染，視頻的捕捉，網絡IO。注意到上圖中底層的這個三個模塊都是畫的虛線，表示這些模塊是可以自己去實現的，可以重載的，這樣大大增加WebRTC的靈活性，爲跨平臺提供了基礎。
-
基礎概念：
- WEB-RTC：WebRTC全稱 Web Real-Time Communication，是一種實時音視頻的技術，它最大優勢是低延時。具體點，感覺更像是一種通信的協議控制，跨平臺；核心是 p2p 鏈接，也可以使用服務器跳板當備份鏈接；
-
信令：WebRTC 建立連接之前，需要進行一種發現和媒體格式協商，以使不同網絡上的兩個設備相互定位。這個過程被稱爲信令。是使呼叫成爲可能的初始引導程序。交換信令消息後，WebRTC Agent 纔可以直接相互通信。
-
信令消息只是文本。 WebRTC Agent 並不關心它們的傳遞方式。信令通常使用 Websockets 分享，但這不是必須的。
- 作用 - 建立瀏覽器之間的通信。
- 用來控制通信開啓或者關閉的連接控制消息
- 發生錯誤時用來彼此告知的消息
- 媒體適配：媒體流元數據，比如像解碼器、解碼器的配置、帶寬、媒體類型等等
- 用來建立安全連接的關鍵數據
- 網絡配置：外界所看到的網絡上的數據，比如IP地址、端口等
- 信令服務器 - 生成信令以及傳輸信令的服務，就是信令服務器。信令服務器的作用是作爲一箇中間人幫助雙方在儘可能少的暴露隱私的情況下建立連接，同時也可以作爲 P2P 鏈接失敗後的一箇中轉服務器(備份方案)。
-
- SD: 全稱 Session Description - 會話描述，如果加上 Protocol，既是會話描述協議(SDP)。這個協議描述媒體協商的信息，是一個 key/value 協議，每一行是一個值。看起來類似於 INI 文件。 一個會話描述包含零個或多個媒體描述。一個媒體描述通常映射到單個媒體流。具體見文檔。
- NAT：網路地址轉換(Network Address Translation)，可爲你的裝置提供公用IP地址。路由器具備公用IP地址，而連上路由器的所有裝置則具備私有IP地址。接着針對請求，從裝置的私有IP對應到路由器的公用IP與專屬的通訊端口。如此一來，各個裝置不需佔用專屬的公用IP，亦可在網路上被清楚識別。
- STUN 和 TURN
- STUN：NAT 的UDP簡單穿越（Simple Traversal of UDP over NATs）是一種網絡協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之後以及NAT爲某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處於NAT路由器之後的主機之間建立UDP通信。即使通過 STUN 服務器取得了公用 IP 地址，也不一定能建立連線。因爲不同的NAT類型處理傳入的UDP分組的方式是不同的。四種主要類型中有三種是可以使用STUN穿透：完全圓錐型NAT、受限圓錐型NAT和端口受限圓錐型NAT。但大型公司網絡中經常採用的對稱型 NAT（又稱爲雙向NAT）則不能使用，這類路由器會通過 NAT 佈署所謂的「Symmetric NAT」限制。也就是說，路由器只會接受你之前連線過的節點所建立的連線。這類網絡就需要TURN技術。
- TURN：中繼NAT實現的穿透（Traversal Using Relays around NAT）就是通過TURN服務器開啓連線並轉送所有數據，進而繞過Symmetric NAT的限制。你可通過TURN服務器建立連線，再告知所有端點傳送封包至該服務器，最後讓服務器轉送封包給你。這個方法更耗時且更佔頻寬，因此在沒有其他替代方案時纔會使用這個方法。
- ICE：交互式連接創建（Interactive Connectivity Establishment，ICE）是一個允許你的瀏覽器和對端瀏覽器建立連接的協議框架。在實際的網絡當中，有很多原因能導致簡單的從 A 端到 B 端直連不能如願完成。這需要繞過阻止建立連接的防火牆，給你的設備分配一個唯一可見的地址（通常情況下我們的大部分設備沒有一個固定的公網地址），如果路由器不允許主機直連，還得通過一臺服務器轉發數據。ICE 通過使用上面幾種技術（NAT，STUN，TURN）完成上述工作。ICE使用STUN或者TURN服務（或者同時使用兩者）來建立連接。
WEB-RTC 鏈接過程：
總體上和 TCP 的三次差不多：
