TURN（NAT 中继穿透）
协议当直接连接失败时使用的中继服务器
什么是 TURN？
\nTURN（Traversal Using Relays around NAT，使用中继穿透 NAT）是一种协议,当直接的点对点路径失败时为 WebRTC 连接提供中继服务器。与仅帮助发现 IP 地址的 STUN 不同，当通过 STUN 进行 NAT 穿透不可行时，TURN 会主动在参与者之间中继所有媒体和数据。
\n可以把 TURN 想象成备用方案：当参与者由于严格的防火墙或对称 NAT 无法直接连接时，TURN 服务器充当中间人，在他们之间转发视频、音频和数据。这确保即使在最具挑战性的网络条件下通话也能成功。
\nTURN 标准化于 RFC 5766（RFC 8656 中更新），是使 WebRTC 在生产环境中可靠运行的安全网。虽然它会增加延迟并消耗服务器带宽，但 TURN 作为降级机制的作用至关重要——它是"通话失败"与"尽管有网络障碍仍然连接"之间的区别。
\n\n为什么需要 TURN
\nSTUN 对大多数连接（75-85%）效果很好，但在特定场景下会失败：
\n- \n
- 对称 NAT：为每个目的地创建不同的端口映射，使 STUN 发现的地址对对等连接无用 \n
- 双方都在严格防火墙后：双方都无法接受传入连接，阻止了直接的点对点连接 \n
- 企业网络：通常采用严格的安全策略，完全阻止点对点流量 \n
- 运营商级 NAT（CGNAT）：移动网络和一些 ISP 使用 STUN 无法穿透的多层 NAT \n
在这些情况下——大约占 WebRTC 连接的 15-25%——TURN 是唯一的解决方案。没有 TURN 服务器，这些通话将直接失败。
\n\nTURN 工作原理：分步详解
\n\n1. STUN 连接尝试失败
\nICE 首先使用主机候选和 STUN 发现的服务器反射候选尝试直接连接。当所有直接尝试失败（ICE 连接性检查超时或失败）时，ICE 转向 TURN 中继候选。
\n\n2. 客户端分配 TURN 中继
\n客户端向 TURN 服务器发送分配请求，提供身份验证凭据（用户名/密码）。TURN 服务器验证凭据并分配中继地址——TURN 服务器上专用于此客户端的公网 IP 和端口。
\n\n3. 交换中继地址
\n中继地址在 ICE 中成为"中继候选"。这个候选通过信令与远程对等点交换，就像之前交换 STUN 候选一样。
\n\n4. 通过 TURN 中继连接
\n双方对等点都连接到各自的 TURN 服务器，并为对方的中继地址创建权限。然后媒体流动：客户端 A → TURN 服务器 A → TURN 服务器 B → 客户端 B（如果双方都需要 TURN）或客户端 A → TURN 服务器 A → 客户端 B（如果只有一方需要 TURN）。
\n\n5. 开始媒体中继
\n所有视频、音频和数据包通过 TURN 服务器流动。服务器只是在授权的对等点之间转发数据包，不检查或修改内容（媒体通过 DTLS/SRTP 仍然是端到端加密的）。
\n\nTURN 传输协议
\nTURN 支持多种传输协议，按优先级顺序尝试：
\n\nTURN/UDP（首选）
\nUDP 是实时媒体的默认选择。延迟更低，无连接开销，对视频/音频质量最佳。在防火墙允许 UDP 流量时使用。
\n\nTURN/TCP（降级方案）
\n当 UDP 被阻止时使用 TCP。更可靠但延迟和开销更高。某些企业网络只允许 TCP 流量。
\n\nTURN/TLS（最后手段）
\nTLS 加密的 TCP，用于最严格的网络。将 WebRTC 流量伪装成 HTTPS，绕过深度包检测防火墙。延迟最高但几乎在任何 HTTPS 可用的地方都能工作。
\n\n成本问题
\n与 STUN 相比，TURN 的成本很高。原因如下：
\n\n带宽消耗
\nTURN 中继所有媒体。单次高清视频通话每个参与者可能消耗 2-4 Mbps。如果双方都使用 TURN，服务器处理的流量翻倍（4-8 Mbps）。在 1 小时通话中，这相当于 1.8-3.6 GB 的带宽。
\n由于 15-25% 的通话需要 TURN，带宽成本迅速累积。这就是为什么 TURN 通常是 WebRTC 基础设施中最昂贵的部分。
\n\n服务器资源
\n每个 TURN 中继都会消耗服务器 CPU 和网络容量。服务器需要高带宽连接，并且必须全球分布以实现低延迟。云提供商对带宽和计算时间都收费。
\n\n实际成本
\n典型成本：每 GB TURN 流量 $0.05-$0.15。对于每月有 10,000 小时 TURN 使用的服务，预计仅带宽成本就需要 $500-2000/月——远远超过 STUN 服务器成本（几乎为零）甚至 SFU 服务器成本。
\n\n性能影响
\n\n增加延迟
\nTURN 增加延迟，因为数据包要经过中间服务器而不是直接在对等点之间传输。典型开销：每个方向 50-150 毫秒，取决于 TURN 服务器位置。总往返增加：100-300 毫秒。
\n这使对话感觉稍微不那么自然，但对大多数用例来说仍可接受。这是直接路径失败时连接性的代价。
\n\n质量限制
\nTURN 服务器带宽可能成为瓶颈。如果服务器的网络连接比客户端慢，质量就会下降。适当的 TURN 基础设施需要高带宽、低延迟的连接——这是另一个成本因素。
\n\n安全考虑
\n\n需要身份验证
\nTURN 服务器必须对客户端进行身份验证以防止滥用。开放的 TURN 服务器会立即被利用来窃取带宽。使用服务器端生成的有时限凭据（通常几小时内有效）。
\n\n媒体加密
\n即使媒体流经 TURN 服务器，它仍然通过 DTLS/SRTP 加密。TURN 服务器无法解密内容——它们只是转发加密的数据包。端到端加密得以保持。
\n\n2025 年最佳实践
\n- \n
- 始终为 TURN 信令启用 TLS 以防止凭据被盗 \n
- 使用强身份验证和短期令牌 \n
- 实施速率限制以防止滥用 \n
- 监控带宽使用并设置每用户/会话配额 \n
- 保持服务器软件更新以修补安全漏洞 \n
- 考虑区域 TURN 服务器以最小化延迟 \n
TURN 基础设施选项
\n\n自托管 TURN
\n流行的开源实现：
\n- \n
- coturn：使用最广泛，功能丰富，维护良好 \n
- eturnal：现代 Erlang 实现，高效且可扩展 \n
优点：完全控制，大规模时可能更便宜。缺点：需要基础设施管理，全球分布复杂。
\n\n托管 TURN 服务
\nTwilio、Cloudflare Calls、Metered 和 Xirsys 等商业提供商提供 TURN 即服务。按 GB 或按分钟付费。
\n优点：无需基础设施管理，全球边缘位置，自动扩展。缺点：每 GB 成本更高，供应商锁定。
\n\n最小化 TURN 使用
\n由于 TURN 成本高昂，应用程序尝试最小化其使用：
\n- \n
- 优先使用 STUN 候选：ICE 首先尝试直接连接，仅在必要时才降级到 TURN \n
- 网络变化时重启 ICE：如果参与者从严格网络（需要 TURN）切换到宽松网络（STUN 有效），ICE 重启可以在通话中途建立直接连接 \n
- 教育用户：告知企业用户企业 VPN 可能强制使用 TURN。断开 VPN 可能启用直接连接 \n
STUN 与 TURN 对比总结
\n理解互补角色：
\n- \n
- STUN：发现服务。帮助查找公网 IP。不中继媒体。运营成本低。75-85% 的情况下有效。连接零额外延迟 \n
- TURN：中继服务。转发所有媒体。带宽成本高。15-25% 的连接需要。增加 100-300 毫秒延迟 \n
两者都是必需的：STUN 提供效率，TURN 提供可靠性。
\n\n为什么 TURN 在 2025 年仍然至关重要
\n尽管 WebRTC、NAT 类型和网络基础设施不断进步，TURN 仍然不可或缺：
\n- \n
- 企业网络出于安全考虑继续使用对称 NAT 和严格防火墙 \n
- 移动运营商部署 CGNAT 以节省 IPv4 地址 \n
- 政府和企业政策要求集中式流量路由 \n
- IPv6 采用虽在增长，但尚未消除 NAT \n
TURN 使用率保持在 15-25% 这一数字多年来一直非常稳定。每个生产级 WebRTC 应用都必须为 TURN 基础设施做预算——这不是可选项。
\n\n总结
\nTURN 是 WebRTC 的保险政策。它成本高昂，增加延迟，并且只在少数连接中需要——但如果没有它，那些少数连接将完全无法建立。
\n通过提供即使在最严格的网络条件下也能工作的中继基础设施，TURN 确保 WebRTC 实现其普遍的浏览器间通信承诺。成本是真实存在的，但替代方案——通话失败——对于生产应用来说是不可接受的。
\n理解 TURN 帮助你为 WebRTC 基础设施制定适当的预算，设计尽可能最小化 TURN 使用的系统，并理解为什么那"15-25% 的连接"代表着可靠服务与不可靠服务之间的区别。
\n\n参考资料
\n- \n
- TURN：使用中继穿透 NAT - BlogGeek.me \n
- WebRTC 的 TURN 服务器：NAT 穿透和可靠连接完整指南（2025） - VideoSDK \n
- 什么是 TURN 服务器？（使用中继穿透 NAT） - Metered \n
- WebRTC 协议简介 - Mozilla 开发者网络 \n
- TURN 服务器 - WebRTC.org \n