Web 實時通信技術WebRTC

語言: CN / TW / HK

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地址可用於“定位”對等點。

image.png

然而,這個過程並不像聽起來那麼容易。因為,這些系統中的大多數都位於網絡地址轉換 (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 是一箇中繼服務器,當兩個對等點之間無法直接連接時,充當傳輸數據、音頻、視頻的中介。

3.jpg

STUN 服務器只在尋找公網 IP 的過程中參與。一旦建立了 WebRTC 連接,所有進一步的通信都通過 WebRTC 進行。但是,在 TURN 的情況下,即使在設置了 WebRTC 連接之後,也始終需要 TURN 服務器。

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

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

image.png

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

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

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

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

假設對等點A想與對等點B建立 WebRTC 連接,需要執行以下操作:

  1. 對等點A使用交互式連接建立 (ICE)生成它的 ICE 候選者。在大多數情況下,它需要 NAT 會話遍歷實用程序 (STUN)或使用 NAT 周圍中繼的遍歷 (TURN)服務器。

  2. 對等點A將 ICE 候選和會話描述捆綁到一個對象中。該對象在對等點A中存儲為本地描述(對等點自己的連接信息),並通過信令機制傳輸到對等點B。這部分稱為要約。

  3. Peer B 收到 offer 並將其存儲為Remote Description(另一端 peer 的連接信息)以供進一步使用。對等體B生成它自己的 ICE 候選和會話描述,將它們存儲為本地描述,並通過信令機制將其發送給對等體A。這部分稱為答案。(注:如前所述,第2步和第3步的ICE候選也可以分開發送)

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

這樣,雙方就可以知道對方的連接信息,可以通過WebRTC成功開始通信了!

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