菜单
集成商务聊天、网络会议、日程安排、文档管理、工作流程和网络会议出席功能的组件 |
  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 穿越难题。这样，您的用户就能在不知不觉中，通过精心设计的后台连接处理，享受顺畅的通信。

博客 网络会议 视频通话 技术博客
  • URLをコピーしました！
目录