Web 實時通訊技術WebRTC_天行無忌

Web 實時通訊 (WebRTC) 是目前正在開發的開源專案，主要目的是提供 Web 應用程式之間的實時、對等通訊。

WebRTC 是一個開源專案，允許嚮應用程式新增點對點實時通訊功能。

WebRTC 首次釋出時，針對的是在 Chrome 上執行的 Web 應用程式。但是現在在幾乎所有流行的瀏覽器、Android、iOS 和桌面平臺上都可以執行 WebRTC 應用程式。

WebRTC 提供簡單的 JavaScript API，開發人員輕鬆構建具有實時音訊、視訊和資料傳輸功能的 Web 應用程式。WebRTC 的最新發展也使其能夠整合到本機應用程式中。由於 API 背後發生了很多事情，因此瞭解 WebRTC 的概念和工作原理以充分利用該技術非常重要。

WebRTC有什麼優勢？

如果需要建立實時通訊的應用程式或平臺，則需要考慮很多因素，例如：

通訊質量（延遲、媒體質量、穩定性等）
訪問裝置硬體（相機、麥克風等）
網路使用情況（頻寬使用情況、網路限制等）
視訊和音訊編碼/解碼
安全
UX 改進功能（降噪、回聲消除等）
支援多種平臺（Windows、Mac、Linux、Android、iOS等）

如果使用 WebRTC 則就不需要考慮上面這些因素。

WebRTC 使應用程式開發人員能夠使用簡單的 API 啟動實時通訊能力。

如何建立連線

為了建立 WebRTC 連線，需要執行以下兩個步驟：

查詢對等點的位置。
通知對等方設定 WebRTC 連線。

第 1 步：找到對等點

把這想象成打電話，當需要通過電話與某人交談時，撥打對方的電話號碼並與該人建立聯絡。當有人想給你打電話時，也會發生同樣的事情。在行動通訊的情況下，使用手機/電話號碼作為使用者的標識。電信系統進一步使用該標識來定位使用者。

但是，Web 應用程式不能相互“撥號和呼叫”。世界上數以百萬計的瀏覽器中的每一個都沒有分配唯一 ID（如電話號碼）。但是，這些應用程式所在的系統一般都分配了一個唯一的 IP 地址，這個IP地址可用於“定位”對等點。

然而，這個過程並不像聽起來那麼容易。因為，這些系統中的大多數都位於網路地址轉換 (NAT)裝置後面。需要 NAT 裝置來實現對可用公共 IP 地址的安全性和 IPv4 限制。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 伺服器。

TURN 伺服器不是有意的，但由於 STUN 的限制，必須依賴它。STUN 伺服器只有大約 86% 的成功率。

第 2 步：通知對等方設定 WebRTC 連線

現在已經獲得了 ICE 候選者，下一步是將這些候選者傳送到希望連線的對等點。與候選人一起傳送會話資訊、時間描述、媒體描述等會話描述。ICE 候選者和會話描述被捆綁在一個物件內，並使用會話描述協議 (SDP)進行傳送。在某些情況下，候選 ICE 不會與 Session Description 捆綁在同一個物件中，而是單獨傳送，這稱為 Trickle ICE（這是一個全新的概念）。

需要將資訊“傳送”給其他對等方。但是，當只知道傳送方的 IP 地址而不知道接收方的 IP 地址時，候選和會話描述是如何傳輸的？而且由於WebRTC連線還沒有建立，這些資訊是通過什麼媒介傳輸的？

所有這些問題的答案都在一個稱為訊號機制的概念中。在建立 WebRTC 連線之前，需要一些媒介在對等點之間傳遞上述資訊，並讓它們知道如何定位和相互連線以進行 WebRTC 連線。這就是訊號機制發揮作用的地方。信令機制在打算連線的兩個對等方之間交換連線訊號（ICE 候選、會話描述等）。

WebRTC 沒有為實現這種訊號機制定義任何標準，而是讓開發人員建立選擇的機制。交換資訊的信令機制可以通過簡單地將資訊複製貼上到各個對等方或使用 WebSockets、Socket.io、伺服器端事件等通訊通道來實現。簡而言之，信令機制只是一種模式在對等點之間交換連線相關資訊，以便對等點可以相互識別並開始使用 WebRTC 進一步通訊。

假設對等點A想與對等點B建立 WebRTC 連線，需要執行以下操作：

對等點A使用互動式連線建立 (ICE)生成它的 ICE 候選者。在大多數情況下，它需要 NAT 會話遍歷實用程式 (STUN)或使用 NAT 周圍中繼的遍歷 (TURN)伺服器。
對等點A將 ICE 候選和會話描述捆綁到一個物件中。該物件在對等點A中儲存為本地描述（對等點自己的連線資訊），並通過信令機制傳輸到對等點B。這部分稱為要約。
Peer B 收到 offer 並將其儲存為Remote Description（另一端 peer 的連線資訊）以供進一步使用。對等體B生成它自己的 ICE 候選和會話描述，將它們儲存為本地描述，並通過信令機制將其傳送給對等體A。這部分稱為答案。（注：如前所述，第2步和第3步的ICE候選也可以分開發送）

對等點A從對等點B接收答案並將其儲存為遠端描述。

這樣，雙方就可以知道對方的連線資訊，可以通過WebRTC成功開始通訊了！

本文正在參加「金石計劃 . 瓜分6萬現金大獎」 ”