介紹

WebRTC 是一個目前正在開發的開源項目，旨在提供 Web 應用程序之間實時的、點對點通信。

WebRTC 提供瞭簡單的 JavaScript API，可以幫助開發人員輕松構建具有實時音視頻傳輸功能的 Web 應用程序。 WebRTC 也計劃支持手機的原生應用。在 WebRTC 提供的 API 之下，其實隱藏瞭 WebRTC 底層的實現原理，所以除瞭使用 API 之外，很有必要瞭解一下 WebRTC 的底層實現。本篇文章非常適合初入門 WebRTC 的人，尤其那些對 WebRTC 的工作原理還不瞭解的人，為瞭讓大傢盡可能讀懂，因此會盡可能使用簡單的術語和類比來詳細解釋 WebRTC 的底層工作原理。

開始

為瞭在甲和乙之間建立 WebRTC 連接，需要執行以下兩個步驟：

1. 找到對方的位置。
2. 通知對方設置 WebRTC 連接。

第1步：找到對方

WebRTC 裡找對方的過程，可以想象成撥打電話一樣，當你需要通過電話與某人通話時，需要輸入對方的電話號碼，然後才能與該人聯系。當有人想給你打電話時，也需要同樣的過程。在打電話時，我們使用電話號碼作為用戶的標識，然後在電信系統進一步使用該標識來定位用戶。但是，Web 應用程序無法相互撥打和呼叫。因為世界上有很多個瀏覽器，而且一個系統裡可以同時存在好多個瀏覽器，瀏覽器也沒有像電話號碼一樣的唯一 ID，雖然沒有唯一的 ID，但是，瀏覽器所在的系統有一個唯一的 ID，就是 IP 地址，這個 IP 地址可以用來定位。

但是，這個過程並不那麼容易。因為，大多數情況下，這些系統都位於網絡地址轉換（NAT）設備之後。對於可用的公共 IP 地址的安全性和 IPv4 有限制，需要 NAT 設備。 NAT 設備為本地網絡中的系統分配專用 IP 地址。此私有 IP 地址僅在本地網絡中有效且可見，並且不能用於接受來自外部世界的通信，因為網絡外的系統不知道網絡內的設備的公共 IP。 由於 NAT 設備的參與，想要對等體不知道它自己的公共IP地址，因為它被NAT分配的私有IP地址掩蓋。因此，它無法與另一個對等方共享其公共IP地址以接受連接。更易懂的是，如果您希望有人給您打電話，您需要將您的電話號碼提供給其他人。但是，在NAT的存在下，它就像住在一個酒店，其房間的電話號碼是隱藏在外面的世界，來到酒店的電話在接待處處理，並根據要求進一步重定向到您的房間。這種間接形式的連接不是用於對等連接技術。為瞭克服這個問題，我們使用稱為 ICE（交互式連接建立）的協議。 ICE 的工作是找到連接兩個對等體的最佳路徑。 ICE 可以執行直接連接，即在沒有 NAT 的情況下以及間接連接，即存在 NAT 時。 ICE 框架為我們提供瞭 ICE候選者 。 ICE候選者 隻不過是包含我們自己的公共 IP 地址，端口號和其他連接相關信息的對象。

在沒有 NAT 的情況下，ICE 非常簡單，因為對等體的公共 IP 地址隨時可用。但是，在存在 NAT 的情況下，ICE 依賴於稱為會話遍歷實用程序的實體用於 NAT（STUN）和/或遍歷使用NAT周圍的中繼（TURN）。

29d809813979c23d7545315fe85c9d69

STUN 服務器基本上允許對等體找到它自己的公共 IP 地址。需要知道自己的公共 IP地址的對等體向 STUN 服務器發送請求。 STUN 服務器回復該對等體的公共 IP 地址。現在可以與其他同伴共享此公共地址，以便他們可以找到您。但是，如果對等體位於復雜的 NAT 或防火墻之後，即使 STUN 也無法找到並向請求對等體提供其 IP地址。在這種情況下，ICE 依靠 TURN 建立連接。顧名思義，TURN 是一個中繼服務器，當兩個對等體之間無法直接連接時，它可以作為傳輸數據，音頻，視頻的媒介。STUN 服務器僅在查找公共IP的過程中涉及。一旦建立瞭 WebRTC 連接，所有進一步的通信都通過 WebRTC 進行。但是，在 TURN 的情況下，即使在設置瞭 WebRTC連接之後，也需要 TURN 服務器。

但由於STUN的限制，我們必須依賴它。 STUN 服務器的成功率隻有 86％。

相關學習資料推薦，點擊下方鏈接免費報名，先碼住不迷路~】

音視頻免費學習地址：FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發

【免費分享】音視頻學習資料包、大廠面試題、技術視頻和學習路線圖，資料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以點擊788280672加群免費領取~

e32d7de2f214d24128f7325f9c4b9e18

第2步：通知對等方設置 WebRTC 連接

現在我們已經獲得瞭 ICE候選人，下一步是將這些候選人發送給我們希望連接的同伴。與候選人一起，會話描述如會話信息，時間描述，媒體描述被發送。 ICE候選者和會話描述被捆綁在對象內並使用 SDP（會話描述協議）傳送。在某些情況下，ICE候選者不會與會話描述捆綁在同一個對象中，而是單獨發送，這被稱為Trickle ICE。 在建立連接時，我們需要將信息“發送”給其他同行。但是，當我們隻知道發件人的 IP地址並且不知道接收對等方的 IP 地址時，如何轉移候選人和會話描述？由於WebRTC 連接尚未建立，這些信息通過什麼媒介傳輸？

所有這些問題的答案都在於一個稱為信號機制的概念。在建立 WebRTC 連接之前，我們需要一些介質來在對等體之間傳輸上述信息，並讓它們知道如何為 WebRTC 連接定位和連接。這是信號機制出現的地方。顧名思義，信令機制在打算連接的兩個對等體之間交換連接信號（ICE候選，會話描述等）。WebRTC 沒有定義任何實現這種信令機制的標準，而是讓開發人員創建一個他選的機制。交換信息的信令機制可以通過簡單地將信息復制粘貼到各個對等體中或通過使用諸如 WebSockets，http://Socket.io，Server Side Events 等通信信道來實現。簡而言之，信令機制隻是一種模式。在對等體之間交換連接相關信息，以便對等體可以相互識別並使用 WebRTC 進一步開始通信。 快速回顧

讓我們在回顧一下整個過程，以便更好地理解。

如果假設，對等體 A 想要與對等體 B 建立 WebRTC 連接，則需要執行以下操作：

Peer A使用 ICE 生成它的 ICE候選者。在大多數情況下，它需要 NAT（STUN）的會話遍歷實用程序或 NAT（TURN）服務器的遍歷使用中繼。 Peer A 將 ICE候選者 和會話描述捆綁到一個對象中。該對象在對等體 A 內存儲為本地描述（對等體自己的連接信息），並通過信令機制傳送給對等體 B.這部分稱為要約。 對等體 B 接收該提議並將其存儲為遠程描述（另一端的對等體的連接信息）以供進一步使用。對等體 B 生成它自己的 ICE候選者和會話描述，將它們存儲為本地描述，並通過信令機制將其發送給對等體A.這部分稱為答案。 （註：如前所述，步驟2和3中的ICE候選人也可以單獨發送） 對等體 A 從對等體 B 接收答案並將其存儲為遠程描述。 這樣，兩個對等體都具有彼此的連接信息，並且可以通過 WebRTC 成功開始通信！原文 WebRTC 的工作原理解析 | 掘金技術征文