30-29之 WebRTC 的 P2P 打洞術 ( ICE )

正文開始

上一篇文章中,咱們已經理解了為什麼 P2P 連線如此的困難,接下來這篇文章咱們將要學習:

WebRTC 是如何進行打洞與連線呢 ?

WebRTC 的打洞流程 ICE

WebRTC 它主要使用一個名為ICE ( Interactive Connectivity Establishment ) 的框架來進行打洞,它內部整合了 STUN 與 TURN 協議,下面簡單的說明一下這兩個協議。

STUN ( Session Traversal Utilities for NAT ) 中文為 NAT 對談穿透應用程式,它的最主要用處就是幫助在 NAT 內的用戶找到可以連到它的位置。

STUN-RFC3489 STUN-RFC5389

TURN ( Traversal Using Relay NAT ),它也是一種穿透 NAT 的一樣協議,不過它是使用中繼的方式來進行,通常都是 STUN 的候選位置都無法連線時,才會使用它。

TURN-RFC5766

WebRTC 連線流程

假設目前要連線的雙方情況如下:

A 內網位置:192.168.1.1:5555
B 內網位置:10.10.1.1:7777
A 外網位置(經過 NAT 轉換):310.110.1.1:9000
B 外網位置(經過 NAT 轉換):210.210.1.1:7000
TURN Server:111.111.111.111

下圖為示意圖。表示雙方去外部連 Server 時對外的的位置。

接下來咱們就開始進行 ICE 打洞流程。

A 想和 B 進行 P2P 連線

Step1. 用戶 A 準備發起請求前,先至 STUN Server 收集候選位置。

在向 Signaling Server 建立連線請求前前,會先去 STUN Server 收集本機用戶 A 的候選位置,這個位置就是用來給別人可以連到我的位置。

其中候選位置如下 :

  • 主機候選項:如果本機在 NAT 裡面,則為私有位置(192.168.1.1:5555)。
  • STUN 反射候選項:如果本機在 NAT 裡面,則為最外層 NAT 的外網位置。(310.110.1.1:9000)
  • 對等反射候選項:這是在進行檢查候選項連線期間發現新的才會有。
  • 中繼後候項:就是 TURN Server 位置。(111.111.111.111)

Step2. 用戶 A 向 Signaling Server 提交 A 的 SDP

上面收集完以候選位置以後 A 就會向 Signaling Server 請求和 B 進行連線,並且附加包含 A 的候選位置的 SDP 給 Server。

Step3. 用戶 B 收到 Signaling Server 請求後,也至 STUN Server 收集候選位置

用戶 B 從 Signaling Server 收到 A 的連線請求與 SDP 後,也前往 STUN 收集 B 自已的候選位置,為了讓 用戶 A 可以連自已。

Step4. 用戶 B 回覆 Signaling Server 答應請求

用戶 B 取得完自已的候選位置後,它會將這些資訊包含在 SDP 內,回覆給 Signaling Server,然後 Server 在將 B 的 SDP 回覆給用戶 A 。

這時雙方都有了對方的候選位置了。

Step5. 雙方開始使用 SDP 內的候選位置嘗試連線。

然後這時雙方 ICE 就會開始使用後選位置來進行嘗試連線。

這裡有件事情要注意:

ICE 會根據下圖的順序來嘗試

ICE 會先從本機候選位開始來嘗試,因為如果嘗試成功了,就代表雙方在同一個 NAT 後面,這樣就會直接的使用這個本機候選位來進行 P2P 連線,因為這樣是效能最好的

Step6-1. 嘗試成功,開始進行 P2P 連線。

如果其中一個有成功,那就會開始進行 P2P 連線,然後就可以開始傳送聲音囉。

Step6-2. 嘗試失敗,轉成使用 TURN 開始進行中介連線 (這時就不是 P2P 了)

但如果前三個都失敗了,那就只能選擇備案,那就是使用 TURN Server 那進行中繼連線了,但這樣的確就不算是 P2P 連線了。

通常需要用到 TURN 的原因

通常需要用到 TURN Server 來進行的原因在於:

雙方其中一邊是使用 Symmetric NAT,也就是所謂的對稱形 NAT

最主要的問題就是,這種對稱形的 NAT 它所配置的 PORT 會變。

結論

本篇文章中咱們學到了 WebRTC 的 P2P 打洞技術 ICE,它是一個包含了 STUN 與 TURN 的 NAT 打洞框架,某些情況下,ICE 幾乎可以說是 100 % 的打洞率,因為它最後還有一個 TURN,但是如果真的需要到使用 TURN 的話那就不是 P2P 連線了,這種時後在連麥直播時就會出問題了。

至於有沒有什麼解決方法呢 ? 目前還真想不到呢 ~ 這之後在來研究吧 ~

備註

上面的一些圖片中 IP 有用到 310 的那個,那是錯的,範例應該只到 255,不過我懶的改了,反正只是範例。

參考資料

comments powered by Disqus