菜单
集成企业聊天、人工智能、网络会议、日程安排、文档管理、工作流和考勤管理的群件 | Chat&Messenger 网络会议
  1. 家
  2. 博客
  3. 网络会议、视频通话
  4. 对 WebRTC 中的 STUN/TURN/TURNS/SFU 进行全面解释和实际应用

对 WebRTC 中的 STUN/TURN/TURNS/SFU 进行全面解释和实际应用

博客 网络会议、视频通话 科技博客
目录

什么是WebRTC？

WebRTC（Web实时通信）是一种开放技术，支持浏览器之间的实时音频、视频和数据通信。它正被谷歌等公司进行标准化，因为它仅使用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 连接，谷歌统计数据显示，大约有 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启用长期凭证机制。用户=用户名:密码请按以下格式设置您的用户名和密码：使用身份验证密钥动态身份验证采用（后者是基于令牌的身份验证，可以有效提高安全性，但在这里我们将使用简单的静态用户身份验证作为示例）。
  • 日志设置： 用于故障排除日志档案然后，指定了日志文件路径。乔治您应该启用详细日志记录。

防火墙设置

服务器端，对于 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时的注意事项

在 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 穿越难题。这将使用户能够在不知不觉中享受无缝通信，这得益于后台智能化的连接处理。

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