WebRTC 的工做原理解析 | 掘金技術徵文

介紹

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）。

STUN 服務器基本上容許對等體找到它本身的公共 IP 地址。須要知道本身的公共 IP地址的對等體向 STUN 服務器發送請求。 STUN 服務器回覆該對等體的公共 IP 地址。如今能夠與其餘同伴共享此公共地址，以便他們能夠找到您。可是，若是對等體位於複雜的 NAT 或防火牆以後，即便 STUN 也沒法找到並向請求對等體提供其 IP地址。在這種狀況下，ICE 依靠 TURN 創建鏈接。顧名思義，TURN 是一箇中繼服務器，當兩個對等體之間沒法直接鏈接時，它能夠做爲傳輸數據，音頻，視頻的媒介。

STUN 服務器僅在查找公共IP的過程當中涉及。一旦創建了 WebRTC 鏈接，全部進一步的通訊都經過 WebRTC 進行。可是，在 TURN 的狀況下，即便在設置了 WebRTC鏈接以後，也須要 TURN 服務器。

但因爲STUN的限制，咱們必須依賴它。 STUN 服務器的成功率只有 86％。

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

如今咱們已經得到了 ICE候選人，下一步是將這些候選人發送給咱們但願鏈接的同伴。與候選人一塊兒，會話描述如會話信息，時間描述，媒體描述被髮送。 ICE候選者和會話描述被捆綁在對象內並使用 SDP（會話描述協議）傳送。在某些狀況下，ICE候選者不會與會話描述捆綁在同一個對象中，而是單獨發送，這被稱爲Trickle ICE。

在創建鏈接時，咱們須要將信息「發送」給其餘同行。可是，當咱們只知道發件人的 IP地址而且不知道接收對等方的 IP 地址時，如何轉移候選人和會話描述？因爲WebRTC 鏈接還沒有創建，這些信息經過什麼媒介傳輸？

全部這些問題的答案都在於一個稱爲信號機制的概念。在創建 WebRTC 鏈接以前，咱們須要一些介質來在對等體之間傳輸上述信息，並讓它們知道如何爲 WebRTC 鏈接定位和鏈接。這是信號機制出現的地方。顧名思義，信令機制在打算鏈接的兩個對等體之間交換鏈接信號（ICE候選，會話描述等）。

WebRTC 沒有定義任何實現這種信令機制的標準，而是讓開發人員建立一個他選的機制。交換信息的信令機制能夠經過簡單地將信息複製粘貼到各個對等體中或經過使用諸如 WebSockets，Socket.io，Server Side Events 等通訊信道來實現。簡而言之，信令機制只是一種模式。在對等體之間交換鏈接相關信息，以便對等體能夠相互識別並使用 WebRTC 進一步開始通訊。

快速回顧

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

若是假設，對等體 A 想要與對等體 B 創建 WebRTC 鏈接，則須要執行如下操做：

1. Peer A使用 ICE 生成它的 ICE候選者。在大多數狀況下，它須要 NAT（STUN）的會話遍歷實用程序或 NAT（TURN）服務器的遍歷使用中繼。
2. Peer A 將 ICE候選者 和會話描述捆綁到一個對象中。該對象在對等體 A 內存儲爲本地描述（對等體本身的鏈接信息），並經過信令機制傳送給對等體 B.這部分稱爲要約。
3. 對等體 B 接收該提議並將其存儲爲遠程描述（另外一端的對等體的鏈接信息）以供進一步使用。對等體 B 生成它本身的 ICE候選者和會話描述，將它們存儲爲本地描述，並經過信令機制將其發送給對等體A.這部分稱爲答案。 （注：如前所述，步驟2和3中的ICE候選人也能夠單獨發送）
4. 對等體 A 從對等體 B 接收答案並將其存儲爲遠程描述。 這樣，兩個對等體都具備彼此的鏈接信息，而且能夠經過 WebRTC 成功開始通訊！

Agora SDK 使用體驗徵文大賽 | 掘金技術徵文，徵文活動正在進行中