選單
整合企業聊天、人工智慧、網路會議、日程安排、文件管理、工作流程和考勤管理的群組軟體 | Chat&Messenger 網路會議
  1. 家
  2. 部落格
  3. 網路會議、視訊通話
  4. 對 WebRTC 中的 STUN/TURN/TURNS/SFU 進行全面解釋和實際應用

對 WebRTC 中的 STUN/TURN/TURNS/SFU 進行全面解釋和實際應用

部落格 網路會議、視訊通話 科技部落格
目錄

什麼是WebRTC？

WebRTC（Web即時通訊）是一種開放技術，支援瀏覽器之間的即時音訊、視訊和資料通訊。它正被Google等公司進行標準化，因為它只使用JavaScript API即可實現P2P通信，而無需額外的插件或軟體。

WebRTC 由以下三個主要元件構成：

  • 取得用戶媒體一個可以從攝影機和麥克風等裝置取得音訊和視訊的API。
  • RTCPeer連接：一個核心 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 位址和連接埠這是一個用於查找 IP 位址的簡單協定。例如，如果您的電腦位於 NAT 之後，它不知道自己的全域 IP 位址，但可以透過查詢 STUN 伺服器來取得「從外部看到的 IP 位址和連接埠」。

STUN 伺服器就像一面鏡子，原封不動地傳回接收到的請求的來源資訊。因此，用戶端可以獲知自身的全域 IP 位址和 NAT 指派的連接埠號碼（伺服器反射候選方案）。

STUN 通訊通常使用 UDP 協議，預設連接埠為 3478 (UDP/3478)。由於它只需要輕量級的、一次性的 UDP 通信，因此開銷和延遲都很低，幾乎不會為伺服器帶來任何負載。所以，在允許 UDP 通訊的環境中，STUN 是嘗試穿越 NAT 的首選方法。

眩暈使用場景

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

STUN的限制和缺點

STUN 只是一種「尋找自身外部位址」的方法，根據 NAT 類型和防火牆限制，僅使用 STUN 可能無法建立連線。尤其是在對稱 NAT 或嚴格防火牆環境下，對方發送的資料包可能無法到達透過 STUN 取得的位址，導致通訊失敗。

此外，在某些企業網路中，UDP 通訊本身可能會被阻塞，在這種情況下，STUN 請求將無法送達。簡而言之，STUN 是一種「判斷是否可行直接通訊」的機制，在物理上無法進行直接通訊的環境中，它無法正常運作。因此，STUN 用於 ICE（稍後詳述）候選位址取得的第一階段；如果 STUN 不足以滿足需求，則會回退到 TURN，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最大的缺點在於資源消耗和延遲。使用TURN時，所有音訊和視訊資料都必須經過伺服器，這需要伺服器端消耗大量的頻寬和處理能力。例如，假設一次一對一視訊通話單向消耗1 Mbps的頻寬，簡單運算可知，1000個並髮用戶就需要1 Gbps的中繼頻寬。因此，TURN伺服器的運作成本很高，大規模服務需要大量的TURN中繼伺服器才能擴充。

此外，更長的通訊路徑會增加延遲，導致視訊和音訊出現時間延遲並降低品質。另外，與 STUN 相比，TURN 並非嚴格意義上的點對點通信，因此安全性略低（儘管 TURN 伺服器通常只轉發未加密的 RTP/資料報，而不對其進行解析）。

一般來說，TURN 僅應在必要時使用。事實上，許多 WebRTC 通訊可以直接使用 STUN 連接，Google統計數據顯示，大約有 861 個 TP3T 呼叫無需中繼即可完成（點對點）。只有剩餘的約 141 個 TP3T 場景需要 TURN，因此為這 141 個 TP3T 場景準備好 TURN 基礎設施至關重要。

TURNS（基於 TCP/443 的 TLS）的角色和特點

TURNS 是「TURN over TLS」的縮寫，它是一種使用 TLS（傳輸層安全性）加密 TURN 協定進行中繼通訊的方法。TURN 通訊受 TLS (HTTPS) 保護它通常透過 TCP 連接埠 443 提供服務。由於 443 連接埠與 HTTPS 的連接埠號碼相同，因此更容易穿過企業防火牆，這是一個優勢，因為它更容易繞過代理和審查。。

例如，在公司網路中，可能只允許使用 80 和 443 連接埠進行外部通訊。即使在這種情況下，使用 TLS 協定在 443 連接埠上進行通訊的 TURN 伺服器也極有可能成功通過。此外，由於使用了 TLS 加密，通訊內容被第三方攔截的可能性更小，因此更安全。

在 WebRTC 中，設定""urls": "turns:turnserver:443""就像 URI 方案一樣轉彎：透過指定此選項，您可以使用此 TLS 加密的 TURN 伺服器。

TURNS 使用場景

在網路通訊受到嚴格限制的情況下（例如在企業網路中），當所有其他方法都被阻止時，TURN 協定就顯得尤為重要。即使在所有 UDP 和通用 TCP 連接埠都被阻止的環境中，許多策略也允許將 TURN 協定視為與 HTTPS 通訊相同的通訊方式，這使得 TURN 協定在 TLS 連接埠 443 上成為一種實用的最後手段。

它也用於公共 Wi-Fi 網路中某些連接埠關閉，或用戶端只能執行 TLS 通訊的情況。簡而言之，首先嘗試使用 UDP，如果不行，則嘗試使用 TCP，如果 TCP 也失敗，則嘗試使用 443 連接埠上的 TLS。這被視為逐步回退過程的最後階段。

TURN 的好處

TLS最大的優勢在於其極高的防火牆穿透能力。 TLS加密通訊與普通的HTTPS通訊難以區分，因此即使面對嚴格的防火牆也能輕鬆通過。尤其是在企業部署網路會議系統時，需要允許內部網路與外部網路建立連接，而從安全策略的角度來看，TCP/443 TLS通訊更容易被接受。此外，由於TLS通訊經過加密，因此可以確保與中繼伺服器之間的通訊保密性（但視訊等內容本身通常在WebRTC層就已經加密）。

轉彎的缺點

最大的缺點是性能損失。除了TURN本身的延遲和負載之外，還增加了TLS和TCP的開銷。 TCP具有重傳機制，可在資料包遺失時進行重傳以確保可靠傳輸，但它不適用於即時媒體，一旦發生丟包，視訊和音訊可能無法流暢播放。

此外，由於封包排序控制，TCP 容易出現隊頭阻塞。與 UDP 相比，抖動（波動）也會增加。此外，TLS 加密和解密處理也會增加 CPU 負載。因此，實際測量結果顯示，會出現 50 毫秒或更長的額外延遲，導致使用者明顯感受到卡頓。尤其是在視訊會議中，這種延遲的增加會擾亂對話節奏，使時間偏差更加明顯。

因此，雖然從品質上看，TURNS 可以被視為“最後的手段”，但在別無選擇的情況下，它也是確保建立溝通的可靠生命線。

近年來，人們考慮了一種新的方法（TURN over QUIC），該方法在 UDP 連接埠 443 上運行，並使用 DTLS/QUIC 而不是 TLS，但它仍處於標準化階段，尚未普及。

當 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 直接連線檢查失敗，因為未找到伺服器反射候選對象：
    通常情況下，如果 STUN 請求成功，用戶端會獲得一個主機候選位址（其本機 IP 位址）和一個伺服器反射候選位址（其全域 IP 位址），並將其與遠端對等方的類似候選位址結合，以執行連線檢查。但是，如果 STUN 請求失敗且沒有全域 IP 位址候選位址，可直接建立點對點連接的候選人數量極為有限。這種情況確實會發生。例如，如果雙方都只有私人 IP 位址，則無法相互連線。因此，ICE 會判定「無法直接連線」。如果 ICE 伺服器 (TURN) 未配置，則整個 ICE 在此階段將被視為故障，WebRTC 連線將無法建立（開發者控制台將顯示…）。ICE失敗やICE 連線狀態：失敗將顯示如下錯誤訊息。
  4. 嘗試取得 TURN 中繼候選位址（透過 TCP/TLS/443）：
    即使STUN無法直接獲得候選人，冰服務器如果指定了 TURN 伺服器，ICE 代理將接下來是我們繼續。在這種情況下，UDP 無法運作，因此用戶端將嘗試使用 TCP 或 TLS（例如）連線到 TURN 伺服器。turns: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」的順序嘗試連接候選伺服器，如果所有候選伺服器都無法連接，則連線失敗。開發人員必須了解此行為，並且至少應將TURN/TURNS伺服器新增至ICE伺服器清單中，以確保即使在最壞的情況下也能建立通訊。此外，當收到使用者要求時，需要進行故障排除，例如根據「ICE失敗」等資訊推斷網路環境問題（例如UDP阻塞），並檢查是否有任何缺失的TURN伺服器設定。

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

如果您要建立自己的 STUN/TURN 伺服器，請使用開源實作。 同向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 用戶端身份驗證，但通常任何字串都可以接受。例如： realm=example.com，伺服器名稱=example.com。
  • 監聽埠： 這是 TURN 和 STUN 監聽的 UDP 連接埠號碼。預設連接埠為 3478。監聽 IP你也可以綁定到特定的網卡，但通常0.0.0.0我們接受所有諮詢。
  • tls監聽埠： 這是用於監聽 TLS（TURNS）協定的 TCP 連接埠號碼。通常指定連接埠 443 或 5349。例如： tls-listening-port=443。
  • 自動IP： 如果伺服器本身位於 NAT 之後，則需要指定其自身的全域 IP 位址（這樣伺服器才能識別內部 IP 位址和外部 IP 位址之間的對應關係）。對於擁有直接全域 IP 位址的伺服器，則無需執行此操作。
  • 身份驗證方法： WebRTC的TURN協定使用長期身分驗證（長期憑證），lt-cred-mech啟用長期憑證機制。用戶=用戶名:密碼請按以下格式設定您的使用者名稱和密碼：使用身份驗證金鑰動態身份驗證採用（後者是基於令牌的身份驗證，可以有效提高安全性，但在這裡我們將使用簡單的靜態用戶身份驗證作為範例）。
  • 日誌設定： 用於故障排除記錄檔然後，指定了日誌檔案路徑。喬治您應該啟用詳細日誌記錄。

防火牆設定

在伺服器端，對於眩暈/轉向UDP埠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時的注意事項

在 Linux 環境中使用 443 連接埠執行 Coturn 時，需要注意連接埠權限。 1024 以下的端口稱為特權端口，通常需要 root 權限才能打開。 Ubuntu 的 coturn 軟體包預設使用 443 連接埠。旋轉伺服器由於該命令由使用者執行，因此無法直接綁定 443 連接埠。作為一種變通方法，/etc/default/coturn將執行用戶更改為root用戶，設定上限命令旋轉伺服器執行檔cap_net_bind_service授予權限的方法有很多種。例如，在後一種情況下，sudo setcap cap_net_bind_service=+ep /usr/bin/turnserver執行此操作將允許非 root 使用者綁定到低編號連接埠。此外，請指定憑證檔案（cert/pkey）的正確路徑，並設定檔案權限，以便 coturn 使用者可以讀取該檔案。更改設定後…sudo systemctl restart coturn重新啟動服務並檢查日誌是否有任何錯誤。

操作檢查

Coturn 伺服器啟動後，我們將使用 STUN 用戶端進行測試以驗證其運行情況，然後嘗試從瀏覽器中的 WebRTC 應用程式建立 ICE 連線。stunclient命令（apt-get install stun-client（可採用以下方式實現）stunclient <伺服器 IP> 3478按照這種方式執行指令，可以測試你是否能夠取得到你的外部IP位址。此外，在瀏覽器中，ICE候選地址會列在開發者工具日誌中。srflx（伺服器反射）候選人和中繼請檢查是否已取得到候選人。如果無法獲取，請按以下步驟排查問題。

  • 檢查伺服器防火牆設定（iptables 或雲端安全群組）中是否已開啟必要的連接埠。
  • 檢查用戶端 ICE 伺服器設定（稍後說明）中是否配置了正確的 URI、連接埠和驗證資訊。
  • turnserver.confの領域確保設定與客戶端的身份驗證相符（這在基於瀏覽器的 WebRTC 中通常不是問題，因為它會自動分配網域，但對於自訂實作要小心）。
  • coturn 日誌（/var/log/turnserver.log檢查是否有任何身份驗證錯誤（使用者錯誤上述錯誤表示使用者名稱和密碼不符。

如果上述設定正確，您自己的 STUN/TURN/TURNS 伺服器將會運行，從而在各種網路環境中啟用 WebRTC 連線。

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

為了在 WebRTC 應用程式（瀏覽器）端實際使用我們剛剛建立的 STUN/TURN 伺服器，ICE 伺服器配置已完成。在 JavaScript WebRTC API 中，RTCPeer連接產生配置時，您可以指定 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 中設定的使用者名稱。網站用戶和密碼secretpass123這指定查詢參數。傳輸=udp新增此選項後，系統將嘗試使用 UDP 協定建立 TURN 連線（如果未指定，瀏覽器將首先嘗試 UDP，如果失敗，則會嘗試 TCP）。此設定可確保即使透過 STUN 直接連線失敗，也能找到 UDP 連接埠 443 上的 TURN 中繼候選設備。
  3. TURN（TLS/TCP）： turns:turn.example.com:443
    使用 TLS 的 TURN這是 TURNS 伺服器配置。這裡也需要指定使用者名稱和密碼。瀏覽器會透過 TCP 連接埠 443 與此條目建立 TLS 連接，並檢索 TURN 中繼候選伺服器。這是一個最後的備用中繼候選伺服器；即使 UDP 通訊完全不可能，這個候選伺服器的存在也帶來了建立通訊的希望。

RTCPeer連接當這些路徑產生後，系統會依序嘗試連接到指定的ICE伺服器並收集候選路徑。 ICE代理首先取得STUN候選路徑（srflx），然後同時取得TURN候選路徑（中繼）。 ICE演算法隨後將這些候選路徑組合起來，執行連線檢查，並選擇最優路徑。開發人員無需了解任何其他步驟。

觀點： 如上所述準備多個方案。這一點很重要。例如眩暈：如果在 UDP 被阻止的環境中僅指定 TURN，則找不到候選協議，連線將失敗。同樣，在僅允許 TCP 的環境中僅指定 TURN（UDP）也會失敗。因此，如果可能，轉動：と轉彎：在 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（Traversal Using Relays Around NAT，即使用 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 穿越難題。這樣做可以讓用戶在不知不覺中享受無縫通信，這要歸功於後台智慧化的連接處理。

部落格 網路會議、視訊通話 科技部落格
  • 網址をコピーしました！
目錄