TURN协议
- 一、深入理解TURN协议：NAT穿透的最后一道防线
- 二、为什么需要TURN？
- 三、TURN的核心思想：做个安静的搬运工
- 四、TURN工作流程拆解
- [五、TURN vs STUN vs ICE](#五、TURN vs STUN vs ICE)
- [六、协议细节速览（RFC 5766）](#六、协议细节速览（RFC 5766）)
- 七、什么时候该用TURN？
- 八、常见误区
一、深入理解TURN协议：NAT穿透的最后一道防线
当STUN无能为力时，TURN就是那个背锅侠
二、为什么需要TURN？
在理想世界里，两个设备可以直接在互联网上"交谈"。但现实很骨感------大多数设备躲在NAT（网络地址转换）后面，家里路由器、公司防火墙、运营商网关......它们像一座座高墙，让P2P直连变得困难重重。
STUN（Session Traversal Utilities for NAT）协议能帮我们"发现"自己的公网IP和端口，实现所谓的"打洞"。然而，当遇到对称型NAT（Symmetric NAT）或者两边都在严格防火墙后面时，STUN那点本事就不够用了------洞打不开。
这时候，TURN（Traversal Using Relays around NAT）登场了。它的思路很简单：既然直连走不通，那就找个"第三方中转站"吧。
三、TURN的核心思想：做个安静的搬运工
TURN服务器像一个有公网IP的中继。两个客户端都不用费力打洞了，各自直接连接到这台服务器，剩下的事全交给服务器------它只负责原样转发数据，不解析、不修改（除非必要）。
你可以把TURN服务器想象成一个"信使"：
- 客户端A把数据交给信使
- 信使把数据原封不动递给客户端B
- 全程信使不偷看内容
四、TURN工作流程拆解
4.1、分配中继地址（Allocation）
客户端向TURN服务器发送一个Allocate请求（通常通过UDP，也支持TCP/TLS）。服务器收到后：
- 验证权限（如果配置了用户名/密码或临时凭证）
- 分配一个中继传输地址 （Relayed Transport Address，比如
203.0.113.5:50000） - 回复客户端：这个地址就是你在外界的"替身"
客户端拿到这个地址后，可以把它告诉通信伙伴。
4.2、创建权限（Permission）
TURN不是随便什么人都能用你的中继地址。客户端必须主动为伙伴的对端地址（peer address）创建权限 。发送一个CreatePermission请求，带上你要允许的IP和端口。
只有被授权过的对端，服务器才会转发它们发来的数据。
简单说：你要先告诉服务器"允许B给我发消息"，B的数据才能通过中继转给你。
4.3、数据中转
一切就绪后：
- 客户端A → TURN服务器：用
Send指示或直接发数据到服务器（ChannelData方式更高效） - TURN服务器 → 客户端B：通过
Data指示转发，源地址是中继地址 - 反过来同理
TURN协议支持两种数据传输方式：
- Send/Data机制：控制消息内嵌数据，可靠但开销大
- Channel机制：先建一个通道号绑定对端，后续只需带通道号发裸数据，适合音频/视频等大流量
4.4、刷新与释放
中继地址是有过期时间 的（默认10分钟）。客户端必须定期发Refresh请求续期。如果客户端掉线，服务器自动回收资源。
五、TURN vs STUN vs ICE
实际工程中，我们不会直接只用TURN------它太贵了（服务器带宽成本高、延迟增加）。ICE（Interactive Connectivity Establishment）的做法是：
- 收集候选：本地地址、STUN服务器发现的公网地址、TURN服务器的中继地址。
- 排序与尝试：优先尝试直连或STUN打洞，最后才降级到TURN。
- 连接建立：按优先级从高到低测试，能用快的就不用慢的。
| 方式 | 延迟 | 服务器负载 | 成功率 |
|---|---|---|---|
| 直连 | 最低 | 无 | 取决于网络 |
| STUN | 低 | 轻量 | 约80-90% |
| TURN | 高（绕路+转发） | 高 | 接近100% |
TURN是"救火队员"，不是常规选择。
六、协议细节速览（RFC 5766）
TURN建立在STUN之上，复用STUN的消息头格式（20字节），通过方法（Method） 的扩展来区分功能：
Allocate(0x003)Refresh(0x004)Send(0x006)Data(0x007)CreatePermission(0x008)ChannelBind(0x009)
消息中的属性（Attributes）携带具体信息，比如LIFETIME、XOR-RELAYED-ADDRESS、REQUESTED-TRANSPORT（通常设为UDP）。
安全方面：TURN支持STUN的长期凭证机制（TURN REST API）或TLS加密控制信道。不过数据面本身不加密------如果要加密，请用DTLS/SRTP。
七、什么时候该用TURN？
- WebRTC：绝大多数WebRTC应用都部署了TURN服务器作为最后备选（比如Google的STUN/TURN聚合服务）。
- P2P文件传输：当UPnP失败且STUN无效时。
- 低延迟敏感度场景：如实时聊天、协作编辑，TURN引入的几毫秒到几十毫秒延迟通常可接受。
- 物联网远程访问：设备在4G/5G内网，单向连接困难。
不建议全用TURN的场景：
- 4K视频会议且用户量庞大（带宽成本爆炸）
- 对延迟极度敏感的游戏（改用专用转发协议）
八、常见误区
-
TURN会加密数据吗？
不会。TURN只负责中继，数据以原样转发。加密要靠应用层（WebRTC就用DTLS/SRTP）。
-
把TURN服务器放在公网就行？
要考量地理位置。服务器离双方越近，延迟越小。通常会用CDN或云厂商多地部署。
-
TURN能突破所有防火墙？
只要防火墙允许出站UDP（或TCP）连接，就能连上TURN服务器。如果连TURN服务器都连不上......那只能换协议了（比如用TURN over TCP over TLS over HTTP，但实际很少见）。