選單
整合商務聊天、網路會議、日程安排、文件管理、工作流程和網路會議出席功能的元件 |
  1. 家
  2. 博客
  3. 网络会议 视频通话
  4. WebRTC中STUN/TURN/TURNS/SFU的徹底解說與實踐

WebRTC中STUN/TURN/TURNS/SFU的徹底解說與實踐

博客 网络会议 视频通话 技術部落格
目錄

什麼是 WebRTC？

WebRTC（Web 即時通訊）是一項開放式技術，可在瀏覽器之間實現即時語音、視訊和資料通訊。它是一種僅使用 JavaScript API 即可實現 P2P 通訊的機制，無需額外的插件或軟體，目前正由 Google 等多家公司進行標準化。

WebRTC由三個主要元件組成：

  • 取得用戶媒體：從攝影機、麥克風等裝置取得音訊和視訊的API。
  • RTCPeerConnection：用於建立對等體之間的通訊以及交換媒體和資料的核心 API。
  • RTC資料通道：資料通道，可用於傳送文件、聊天等。

這些API使得許多即時應用的開發成為可能，例如視訊通話、音訊會議、檔案共享等。然而在實際通訊中，存在著NAT穿越和防火牆的問題，因此理解和實現STUN/TURN/TURNS等NAT穿越技術至關重要。

STUN、TURN、TURNS的區別與作用

要實現穩定的WebRTC點對點連接，NAT穿越機制不可或缺。本文將詳細解說代表技術STUN、TURN、TURNS的技術區別、使用情境及優缺點。

STUN 是一種主要用於在 NAT 環境中尋找外部位址的協議，而 TURN 是一種在無法直接連接時充當中繼伺服器的協定。另一方面，TURNS 使用 TLS 加密 TURN 通信，並使用與 HTTPS 相同的連接埠號碼 443，從而可以在企業網路等嚴格的防火牆後進行通訊。

透過了解每種特性並適當使用它們，您可以提高 WebRTC 通訊的成功率和品質。

STUN（UDP）的作用與特點

STUN（NAT 會話遍歷實用程式）是一種允許客戶端外部 IP 位址和連接埠這是一個獲取 PC IP 位址的簡單協定。例如，如果一台 PC 位於 NAT 後面，它不知道自己的全域 IP 位址，但可以透過查詢 STUN 伺服器來取得「自己的 IP 位址：從外部看到的連接埠」。

STUN伺服器就像一面鏡子，將收到的請求的來源資訊原封不動地回傳。這樣，客戶端就可以知道自己的全域IP位址，以及NAT（Server Reflexive candidates）所指派的連接埠號碼。

STUN 通訊通常使用 UDP 進行，預設連接埠為 3478（UDP/3478）。由於 STUN 通訊需要使用 UDP 進行輕量級、單次通信，因此開銷低、延遲低，幾乎不會給伺服器端帶來任何負擔。因此，在允許使用 UDP 通訊的環境中，會先嘗試使用 STUN 進行 NAT 穿越。

STUN使用場景

它在需要 NAT 穿越但 UDP 通訊本身不受阻斷的環境中非常有效，例如家庭網路和行動線路。如果 STUN 能夠取得彼此的外部 IP:端口，則用戶端可以建立直接（點對點）通訊。由於通訊路徑是直接的，因此延遲更少，並且能夠保持較高的品質。此外，由於伺服器僅負責 IP 資訊的交換，因此成本非常低。例如，在線上遊戲或視訊通話中，如果雙方裝置都處於相對開放的 NAT 中，則 STUN 足以實現點對點連線。

STUN 的限制和缺點

STUN 只是一種「尋找自己的外部位址」的手段，根據 NAT 類型和防火牆的限制，單獨使用 STUN 可能無法連線。尤其是在對稱型 NAT 或嚴格的防火牆環境中，來自對方的資料包可能無法到達透過 STUN 取得的位址，導致無法通訊。

此外，UDP 通訊本身可能在企業網路中被封鎖，在這種情況下，STUN 請求無法到達裝置。簡而言之，STUN 是一種用於確定是否可以進行直接通訊的機制，在物理上無法進行直接通訊的環境中不起作用。因此，在 ICE（如下所述）中使用 STUN 來獲取第一階段的候選連接，並且如果 STUN 不足以滿足需求，則會回退到 TURN（如下所述）。

TURN（UDP）的作用與特點

TURN（使用中繼繞過 NAT）是一種在無法透過 STUN 直接通訊時充當中繼的協定。 TURN 伺服器可作為通訊夥伴和對方之間可全域存取的中繼點，負責轉送封包。用戶端連接到 TURN 伺服器，並取得一個中繼 IP 位址和連接埠（稱為中繼候選）。之後，透過該 TURN 伺服器與對方進行媒體和資料交換。

TURN 通常也使用 UDP 進行通信，因此只要使用 UDP，它就能以類似於直接通信的方式中繼媒體資料包。預設情況下，TURN 協定在連接埠 3478（UDP）上被接受，與 STUN 相同。即使 UDP 連接埠號碼受到防火牆策略的限制，TURN 也可以在允許的連接埠（例如 UDP/443）上運作。只要使用 UDP，就能實現比 TCP 更高即時性的中繼。

TURN 使用場景

當無法建立直接連線時，TURN 至關重要。例如，當一方或雙方都處於嚴格的公司防火牆之後，或者雙方都具有對稱 NAT 並且 UDP 打洞失敗時，就會發生這種情況。在這樣的環境中，如果不透過 TURN 伺服器中繼，就無法進行通信，因此 TURN 是一種最後的手段。

WebRTC 的目標是讓所有對等體都能直接通信，但即使無法實現，通信本身也可以透過回退到 TURN 繼續進行。實際操作中，一般策略是先嘗試使用 STUN 直接連接，只有在失敗時才切換到 TURN 中繼。例如，在內部網路上的視訊會議中，如果雙方無法直接通信，通信將自動切換到透過 TURN 伺服器進行通信，讓用戶在不知不覺中繼續對話。

TURN 的優勢

最大的優勢在於可靠性。無論您身處何種 NAT 或防火牆環境，只要能夠建立從客戶端到 TURN 伺服器的通信，最終就能實現點對點通訊。此外，由於 TURN 在協定上是對 STUN 的擴展，因此單一伺服器實作（例如下文介紹的 coturn）可以同時處理 STUN 和 TURN 請求。一旦建立連接，後續媒體將以串流的形式進行中繼，因此從用戶的角度來看，通訊是無縫的，除了一些延遲。

TURN 的缺點

它最大的缺點是資源消耗和延遲。使用 TURN，所有音訊和視訊資料都必須經過伺服器，這需要伺服器端龐大的頻寬和處理能力。例如，假設一對一視訊通話的單向頻寬為 1Mbps，那麼簡單計算一下，如果 1,000 個用戶同時使用，則需要 1Gbps 的中繼頻寬。這使得 TURN 伺服器的運作成本很高，而大規模服務則需要準備和擴展多個 TURN 中繼伺服器。

此外，通訊路徑越長，延遲越大，導致時間滯後，視訊和音訊品質下降。此外，與使用 STUN 的點對點通訊相比，透過 TURN 進行的通訊並非嚴格意義上的點對點通信，因此在保密性方面略遜一籌（儘管 TURN 伺服器通常僅中繼未加密的 RTP/資料報，而不會解釋其內容）。

一般來說，TURN 應僅在必要時使用。事實上，大多數 WebRTC 通訊可以直接使用 STUN 連接，Google 統計數據顯示，總共約有 861 個 TP3T 呼叫無需中繼（點對點）即可建立。只有其餘 141 個 TP3T 需要 TURN，但對於這 141 個 TP3T 來說，擁有 TURN 基礎設施至關重要。

TURNS（TLS over TCP/443）的功能與特點

TURNS 是「TURN over TLS」的縮寫，是一種使用 TURN 協定和 TLS（傳輸層安全性）對中繼通訊進行加密的協定。TURN 通訊受 TLS (HTTPS) 保護並且經常在 TCP 連接埠 443 上提供服務。連接埠 443 與 HTTPS 的連接埠號碼相同，因此可以輕鬆穿過企業防火牆，並且易於繞過代理和審查。。

例如，公司內部網路可能只允許在連接埠 80 和 443 上進行外部通信，但即使在這種情況下，如果 TURN 伺服器在連接埠 443 上使用 TLS 通信，則通訊很有可能通過。此外，由於通訊使用 TLS 加密，因此它們是安全的，第三方難以攔截。

在 WebRTC 中，設定“urls”：“turns：turnsserver：443”在 URI 方案中：轉彎：您可以透過指定以下方式使用此 TLS 加密的 TURN 伺服器

使用TURNS的場景

TURNS 對於在嚴格限制的環境中（例如所有其他通訊方式都被阻止的公司網路）進行 WebRTC 通訊非常有用。即使在所有 UDP 和常規 TCP 連接埠都被阻止的環境中，也有許多策略允許以與 HTTPS 通訊相同的方式進行通信，因此在 TLS 連接埠 443 上使用 TURN 實際上是最後的手段。

它也用於公共無線區域網路某些連接埠關閉的情況，或客戶端只能進行 TLS 通訊的情況。首先是 UDP，如果不起作用則使用 TCP，如果不起作用則使用 TLS 到 443「它被定位為逐步回落的最後階段。

TURNS 的優勢

其最大的優勢在於其強大的防火牆防禦能力。 TLS 加密通訊難以與常規 HTTPS 區分，因此更容易通過嚴格的過濾器。尤其是當公司引入網路會議系統時，需要允許從內部網路進行外部連接，但基於 TCP/443 的 TLS 通訊更容易在安全策略下被接受。此外，由於經過加密，因此可以確保與中繼伺服器本身的通訊的機密性（*但是，內容本身，例如視頻，通常已在 WebRTC 層加密）。

TURNS 的缺點

最大的缺點是性能損失。除了 TURN 本身的延遲和負載外，還有 TLS 和 TCP 的開銷。 TCP 是一種可靠的傳輸方式，並且在發生資料包遺失時具有重傳機制，但它並不適合即時媒體，如果發生遺失，視訊和音訊可能無法流暢播放。

此外，由於資料包排序，TCP 容易出現隊頭阻塞，與 UDP 相比，抖動（波動）也有所增加。此外，TLS 加密和解密處理會為 CPU 帶來額外的負載。據報道，這會導致 50 毫秒或更長的額外延遲，用戶可能會感覺到卡頓。尤其是在視訊會議中，這種延遲的增加會減慢對話節奏，並導致明顯的時間差異。

這樣，TURNS 在品質方面可以被視為一種“最後手段”，但在除了建立通訊之外別無選擇的情況下，它也是一條可靠的生命線。

近年來，人們考慮採用一種在 UDP 連接埠 443 上運行並使用 DTLS/QUIC 代替 TLS 的新方法（TURN over QUIC），但它仍處於標準化過程中，並不常用。

UDP STUN 不可用時的通訊流程

我們將逐步解釋當 UDP 上的 STUN 不可用時，WebRTC ICE 的處理過程。假設 UDP 完全阻塞，例如在企業網路中，並觀察 ICE 協商如何回退。

  1. 客戶端向 STUN 伺服器發送外部 IP 查詢（UDP/3478）：
    WebRTC 用戶端（瀏覽器）冰服務器透過 UDP 連接埠 3478 向 中指定的 STUN 伺服器傳送綁定請求（驗證外部位址的請求）。這是收集 ICE 候選的第一步，如果成功，伺服器將傳回自己的全域 IP 位址和連接埠號，並作為伺服器反射候選（srflx 候選）新增至候選清單。
  2. UDP封包被防火牆阻止，且未收到任何回應：
    在這種情況下，網路防火牆設定會阻止 UDP 通訊到達外部。因此，傳送到 STUN 伺服器的請求無法到達伺服器，或回覆無法到達客戶端。結果，客戶端未收到 STUN 回應，無法知道外部 IP 位址。 ICE 代理程式等待回應一段時間，但隨後逾時。從使用者的角度來看，連線仍在處理中，沒有顯示任何錯誤訊息，但實際上未能收集候選人這種情況目前正在發生。
  3. ICE 直接連線檢查失敗，因為沒有可用的 Server Reflexive 候選：
    通常情況下，如果 STUN 連線成功，用戶端除了主機候選（您的本機 IP）之外，還會有一個伺服器自反候選（您的全域 IP），並將其與遠端對等體的類似候選相結合，以檢查連線是否正常。但是，如果由於 STUN 連線失敗導致沒有全域 IP 候選，則直接同儕聯繫的候選人極為有限例如，如果雙方都只有私人 IP 位址，即使嘗試連線也無法互相存取。因此，ICE 會判斷無法直接通訊。如果 ICE 伺服器（TURN）未配置，則整個 ICE 會在此階段被視為失敗，WebRTC 連線將無法建立（開發者控制台將顯示ICE 失敗和......和ICE連線狀態：失敗等）。
  4. 嘗試取得 TURN 中繼候選（透過 TCP/TLS/443）：
    即使 STUN 直接取得候選失敗，冰服務器如果在後續步驟在此範例中，由於 UDP 不可用，因此客戶端將嘗試使用 TCP 或 TLS 連線到 TURN 伺服器（例如，轉彎：turn.example.com：443（如果已配置，TLS 握手將開始。）幸運的是，防火牆允許在 TCP 443 連接埠上進行 HTTPS 通信，因此透過 TLS 建立的 TURN 連接成功。用戶端在 TURN 伺服器上取得一個中繼位址，接力候選人另一端將獲得中繼候選，這些候選是「透過 TURN 伺服器進行通訊的虛擬候選」。同時，另一端（遠端）也將獲得中繼候選，或者如果網路沒有問題，則會有直接候選或 STUN 候選。無論如何，只要至少一端有中繼候選，另一端就可以嘗試連接到該 TURN 伺服器。
  5. 透過中繼建立 ICE 連線（或最終失敗）：
    一旦雙方都有可用的候選人（本例中是一個或兩個中繼候選人），ICE 就會使用它們來檢查連接。一旦透過 TURN 伺服器與伺服器建立通信，就可以進行中繼，因此即使 UDP 不在雙方之間直接傳輸，媒體通道也會打開。這允許用戶之間開始視訊和音訊通訊。連線建立後，雖然會有一些 TCP over TLS 形式的開銷，但對話本身是可以進行的。相反，如果這裡也發生故障（例如，公司代理檢測到並阻止了非 HTTP TLS 通信，或者 TURN 伺服器的身份驗證失敗），ICE 就會失敗，連接將被放棄。應用程式需要偵測到這種情況，並通知用戶「無法連線」等資訊。

這是在無法使用 UDP 的惡劣環境下 ICE 協商的流程。簡而言之，候選伺服器將按照「主機 → STUN → TURN」的順序進行嘗試，如果失敗，連線將會失敗。開發人員務必了解此行為，並至少在 ICE 伺服器清單中包含一個 TURN/TURNS 伺服器，以便即使在最壞的情況下也能建立通訊。此外，在收到使用者查詢時，需要進行故障排除，例如根據「ICE 失敗」等資訊推斷網路環境問題（例如 UDP 阻塞），並檢查是否缺少 TURN 伺服器設定。

使用 coturn 建置和設定 STUN/TURN/TURNS 伺服器

如果您想設定自己的 STUN/TURN 伺服器，請使用開源實作。 科特恩使用 coturn 很常見。 coturn 是一個支援 STUN 和 TURN 的伺服器實現，根據設定還可以支援 TURNS（TLS）。本文介紹如何在 Linux 伺服器上安裝 coturn 並建立一個提供 STUN/TURN/TURNS 服務的伺服器，以及設定重點。此外，也介紹了典型的設定檔 (turnserver.conf) 也會顯示。

安裝和基本配置

安裝

對於 Ubuntu 和 Debian，易於您可以從此處安裝 coturn 套件。例如，使用以下命令安裝它並將其設定為自動啟動。

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

這將啟動 coturn 伺服器作為守護進程。預設情況下，它將運行配置文件 /etc/turnserver.conf 這將加載文件，然後您可以編輯它（為了安全起見，請在編輯之前進行備份）。

基本設定

turnserver.conf現在，設定以下項目：

  • 領域和伺服器名稱： 這是 TURN 伺服器的網域名稱或識別名。它可能用於對 WebRTC 用戶端進行身份驗證，但基本上可以是任意字串。例如： 領域=example.com，伺服器名稱=example.com。
  • 監聽埠： 用於偵聽 TURN 和 STUN 的 UDP 連接埠號碼。預設值為 3478。監聽IP您也可以使用以下方式綁定到特定的 NIC0.0.0.0我們全部接受。
  • tls監聽埠： 這是用於監聽 TLS (TURNS) 的 TCP 連接埠號碼。通常指定 443 或 5349。例如： tls監聽埠=443。
  • 外部IP位址： 如果伺服器本身位於 NAT 之後，請指定其自身的全域 IP（這允許伺服器識別內部 IP 和外部 IP 之間的對應）。如果伺服器擁有直接的全域 IP，則無需執行此操作。
  • 身份驗證方法： WebRTC 使用長期憑證進行 TURN，因此lt-cred-mech（長期憑證機制）已啟用。用戶=用戶名:密碼或以以下格式設定使用者名稱和密碼使用授權秘密（後者是基於token的認證，對於提升安全性比較有效，不過這裡我們以簡單的靜態使用者認證為例）
  • 日誌設定： 用於故障排除記錄檔指定日誌檔案路徑冗長的您可能想要啟用詳細日誌記錄。

防火牆設定

在伺服器端，用於 STUN/TURNUDP 連接埠 3478以及 TURN/TLSTCP 連接埠 443（或 5349）必須打開。此外，TURN 中繼預設使用 UDP 連接埠範圍 10000-20000，因此也請在伺服器上開啟此連接埠範圍（如有必要，最小連接埠和最大連接埠（範圍可以透過

下面是反映上述基本設定的範例。/etc/turnserver.conf以下是一個例子：

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

上文中，域example.com我們獲得 Let's Encrypt 憑證並將其用於 TLS 設定。lt-cred-mech啟用長期身份驗證使用者這將設定簡單的用戶名/密碼驗證。使用授權秘密和靜態認證秘密建議的方法是使用基於令牌的方法來頒發臨時憑證，但我們在這裡不討論這個。

使用 TLS 時的注意事項

在 443 連接埠上執行 coturn 時，需要注意 Linux 環境中的連接埠權限。 1024 以下的端口稱為特權端口，通常需要 root 權限才能打開。 Ubuntu coturn 軟體包預設為轉彎伺服器因為它是由使用者執行的，所以它不能按原樣綁定到連接埠 443。/etc/預設/coturn將運行用戶更改為 root，或者設定上限使用命令轉彎伺服器到可執行檔cap_net_bind_service有一種方法可以授予權限。例如，在後一種情況下，sudo setcap cap_net_bind_service=+ep /usr/bin/turnserver透過執行此命令，即使非 root 使用者也能綁定低編號連接埠。此外，請指定憑證檔案 (cert/pkey) 的正確路徑，並設定檔案權限，以便 coturn 使用者可以讀取該檔案。更改設定後，sudo systemctl 重啟 coturn重新啟動服務並檢查日誌是否有任何錯誤。

操作檢查

啟動 coturn 伺服器後，我們將使用 STUN 用戶端對其進行測試以檢查其運行情況，並嘗試從瀏覽器中的 WebRTC 應用程式連接到 ICE。擊暈客戶端命令（apt-get 安裝 stun-client（可安裝於stunclient <伺服器 IP> 3478您可以嘗試執行以下命令以取得外部 IP。此外，在您的瀏覽器中，ICE 候選地址將列在開發者工具日誌中，因此srflx（伺服器反身）候選人和中繼檢查是否找到候選。如果沒有，請嘗試以下方法進行故障排除：

  • 伺服器的防火牆設定（iptables 或雲端安全群組）中是否開啟了必要的連接埠？
  • 用戶端 ICE 伺服器設定（如下所述）中是否設定了正確的 URI、連接埠和驗證資訊？
  • turnserver.conf的領域確保設定與客戶端身份驗證一致。 （這在瀏覽器版本的 WebRTC 中通常不是問題，因為領域是自動分配的。但如果您有自訂實現，則需要小心。）
  • 循環日誌 (/var/log/turnserver.log) 並檢查是否有身份驗證錯誤 (錯誤用戶如果出現如上錯誤，則表示使用者名稱/密碼不符。

透過上述設置，您將擁有自己的 STUN/TURN/TURNS 伺服器運行，並能夠在各種網路環境中支援 WebRTC 連線。

WebRTC 用戶端 ICE 伺服器設定範例（JavaScript）

要實際使用我們剛剛在 WebRTC 應用程式（瀏覽器）上建置的 STUN/TURN 伺服器，ICE伺服器設定在 JavaScript 的 WebRTC API 中，RTCPeerConnection您可以在產生時指定 STUN/TURN 伺服器清單。接下來，我們將展示一個指定所有 STUN/TURN/TURNS 伺服器的具體程式碼範例，並解釋其意義。

首先，為 ICE 伺服器建立一個配置物件。輸入伺服器的網域名稱。turn.example.com（根據情況替換）。 STUN 不需要身份驗證，因此只需指定 URI。 TURN/TURNS 需要身份驗證，因此也需要指定使用者名稱和密碼。

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

以上冰服務器該數組有三個條目。

  1. 眩暈： stun：turn.example.com：3478
    指定您自己的 STUN 伺服器位址（如果省略端口，則使用 3478）。 STUN 用於判斷 NAT 穿透並取得候選位址。瀏覽器首先透過 UDP 查詢此伺服器以取得伺服器反射候選位址。
  2. TURN（UDP）： turn:turn.example.com:443?transport=udp
    建立您自己的 TURN 伺服器UDP 連接埠 443這是要使用的設定。先前在coturn中設定的使用者名稱作為認證訊息webrtcuser和密碼secretpass123查詢參數已指定。？傳輸=udp（如果未指定，瀏覽器將首先嘗試 UDP，如果失敗，則再嘗試 TCP。）透過此設置，即使使用普通 STUN 的直接連接失敗，您也可以獲得在 UDP 連接埠 443 上進行 TURN 中繼的候選。
  3. TURN（TLS/TCP）： 轉彎：turn.example.com：443
    使用 TLS 的 TURN這是 TURNS 伺服器的設定。使用者名稱和密碼也在此指定。瀏覽器將在 TCP 連接埠 443 上與此條目建立 TLS 連接，以取得 TURN 中繼候選。這是最後的中繼候選，即使完全無法透過 UDP 通信，也有可能建立通信。

RTCPeerConnection當 ICE 代理程式產生 ICE 伺服器時，它會按順序嘗試連接到指定的 ICE 伺服器並收集候選伺服器。 ICE 代理程式首先取得 STUN 候選伺服器（srflx），然後並行取得 TURN 候選伺服器（relay）。然後，ICE 演算法會合併這些候選伺服器，執行連線檢查並選擇最佳路由。開發人員無需了解任何其他流程。

觀點： 如上所述準備多名候選人很重要。例如，眩暈：如果僅指定 TURN (UDP)，則在 UDP 被封鎖的環境中將找不到任何候選，連線將失敗。同樣，如果僅指定 TURN (UDP)，則在僅允許 TCP 的環境中連線也會失敗。因此，如果可能，轉動：和轉彎：透過在 ICE 伺服器中同時包含這兩種協議，可以實現冗餘，以便在任何環境中都能找到至少一個有效的候選路徑（當然，TURN 伺服器必須同時支援 UDP 和 TCP/TLS）。客戶端（瀏覽器）會自動選擇一條可用的路徑，因此清單的順序並不是什麼大問題。如果非要我說，冰運輸政策的中繼除非您指定此項，否則瀏覽器將優先考慮直接連接，因此如果您輸入 STUN 條目，則可以避免不必要地使用 TURN 伺服器。此外，如果在 ICE 伺服器清單中輸入了不相關的伺服器（例如不存在的位址），則可能會因等待逾時而導致延遲，因此最好只輸入那些確實可用的伺服器。

最後，讓我們使用此設定運行 WebRTC 應用程式並驗證連線狀態。peerConnection.getStats()或者chrome://webrtc-internals您可以使用 Chrome 查看 ICE 候選版本和連線狀態。如果一切正常，在 UDP 可用的環境中，它應該會自動回退到直接 (P2P) 連線；在 UDP 不可用的環境中，它應該會自動回退到透過 TURN/TLS 的連線。

SFU 和 TURN 之間的區別

WebRTC 中繼大致可以分為“TURN”和“SFU”，但它們的角色、配置和用途有顯著差異。這裡我們總結了它們之間的技術差異。

TURN：中繼作為點對點的替代方案

TURN（使用中繼繞過 NAT）是一種輔助中繼伺服器，用於無法進行 WebRTC P2P 通訊的環境。當 STUN 因 NAT 或防火牆而無法正常運作時，TURN 伺服器會在對等體之間運作並中繼資料包。由於每個對等體都向每個通訊夥伴分別發送流，因此配置為網狀結構，而 TURN 則被定位為「替補」。

  • 作品：每個使用者透過中繼（實際上是一個網格）向其他每個使用者進行傳輸
  • 可擴展性：低（人數越多，負荷越高）
  • 播出內容：僅進行簡單的資料包傳輸，不進行媒體分析或最佳化

SFU：高效中繼，支援多方通話

SFU（選擇性轉發單元）是用於多參與者網路會議的智慧中繼伺服器。每個客戶端向 SFU 發送一個流，SFU 選擇性地將其轉發給其他參與者。它還執行揚聲器偵測、影像品質調整和延遲優化，實現可擴展的高性能廣播。

  • 作品：星型，每個客戶端連接到一個 SFU
  • 可擴展性：昂貴（即使人數增加也只能發送一次）
  • 播出內容：可以控制傳輸目的地和媒體優化

TURN 與 SFU 對比表

特徵轉動西門菲沙大學
目的無法進行 NAT 穿越時的替代方案多人即時溝通
通訊配置網狀（相互傳輸）星型（一次傳輸）
中繼功能簡單中繼（透明）可選轉送和優化
可擴展性低的昂貴的
媒體控制沒有任何是（例如揚聲器偵測、解析度調整）

TURN 只是在無法進行 P2P 通訊時的最後手段，是補充 P2P 網格的中繼。SFU 是一種中繼架構，從一開始就被設計為有效率地進行多方通話。由於兩者的作用根本不同，因此在設計時不要混淆它們。

摘要

本文為中階到高階 WebRTC 使用者詳細講解了 STUN、TURN 和 TURNS 之間的技術區別，以及何時使用它們、如何使用 coturn 建立伺服器和一些程式碼範例，以及 ICE 在惡劣網路環境中的表現。

眩暈它重量輕，並支援在 NAT 環境中直接通訊。轉動在困難情況下提供溝通的生命線；轉彎透過結合這些，即使在公司內部等特殊環境中也可以使用 WebRTC。

每種方式都有各自的優缺點，因此理想情況下，應盡可能直接使用 STUN 連接，僅在絕對必要時使用 TURN 中繼。在實際的 WebRTC 應用程式開發中，透過在 ICE 伺服器設定中準備本文介紹的多條路由，並在伺服器端正確配置和操作 coturn，即可在各種網路環境中提供穩定的即時通訊。

WebRTC 是一個結合了瀏覽器 API 和網路技術的複雜領域，但了解 STUN/TURN 和 ICE 的工作原理對於創建可靠的應用程式至關重要。

我們希望您能運用本文的信息，嘗試克服您產品中的 NAT 穿越難題。這樣，您的用戶就能在不知不覺中，透過精心設計的後台連接處理，享受順暢的溝通。

博客 网络会议 视频通话 技術部落格
  • 網址をコピーしました！
目錄