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