获课：xingkeit.top/6667/

STUN/TURN 底层源码研读：NAT 穿透的核心机制剖析

NAT 穿透是 P2P 通信的"最后一公里"。WebRTC 能让两个身处不同网络的人视频通话，背后全靠 STUN 和 TURN 在底层撑着。不读懂源码，你永远不知道"打洞"究竟打的是什么洞。

一、STUN：一面照见公网的镜子

STUN 的本质极其简洁——它不是传输协议，而是一面镜子。客户端向 STUN 服务器发一个 UDP 包，服务器原封不动把"我看到的源地址"反射回来。这个地址，就是 NAT 设备替你映射出去的公网 IP 和端口。

消息结构遵循 RFC 5389（取代了老旧的 RFC 3489），由 20 字节固定头部加 TLV 属性字段组成。固定头部包含消息类型（Class + Method）、消息长度、魔术 cookie（固定值 0x2112A442）和 12 字节事务 ID。所有字段强制大端序，防止不同 CPU 架构的解析歧义。

核心属性是 XOR-MAPPED-ADDRESS。服务器把源 IP 和端口经过 XOR 运算后塞进响应，客户端用相同魔术字解码，即可拿到真实映射地址。相比老版的 MAPPED-ADDRESS，XOR 编码能有效防止中间设备篡改，安全性提升一个量级。

但 STUN 有致命短板：它只对锥型 NAT 有效。全球约 30% 的企业网络、65% 的移动运营商网络采用对称型 NAT——每个目标地址分配独立公网端口，STUN 探测一次只能拿到一个映射，无法通用。这就是 TURN 登场的原因。

二、TURN：保底的中继通道

TURN 遵循 RFC 5766，核心逻辑分三步：分配、授权、传输。

分配阶段：客户端发送 Allocate 请求，TURN 服务器以五元组（客户端 IP/端口、服务器 IP/端口、协议）标识一个 Allocation 资源，分配中继地址并返回，默认监听 3478 端口。服务器用 lifetimes 定时器管理资源，默认 10 分钟，客户端需每 9 分钟发刷新请求保活。

授权阶段：客户端通过 CreatePermission 显式指定允许通信的对端 IP，防止中继资源被滥用。这一步在 WebRTC 中默认权限有效期 300 秒。

传输阶段有两种模式。Send/Data Indication 方式每个包都封装 STUN 头部，开销大但灵活；Channel 方式通过 ChannelBind 绑定信道号（0x4000-0x7FFF），后续数据包只带 4 字节信道头，协议开销降低 36 字节，在 VoIP 场景中带宽效率提升高达 90%。

TURN 的代价也很明确：端到端延迟增加 30-50ms，带宽成本上升约 40%。但它是对称型 NAT 的唯一解药，某跨国企业实测显示，TURN 将 P2P 连接成功率从 STUN 的 42% 拉升至 97%。

三、ICE：让三者协同作战

ICE（RFC 5245）才是真正的指挥官。它系统化收集三类候选地址：主机候选（本地 IP）、服务器反射候选（STUN 返回的公网地址）、中继候选（TURN 分配的中继地址），按优先级排序后逐一尝试连通性检查。

优先级策略清晰：主机对主机 → STUN 反射 → TURN 中继。一旦直连成功，立即关闭中继通道。某在线教育平台的数据表明，这套策略使课堂卡顿率降低了 63%。

四、一句话总结

STUN 是探测器，TURN 是保底通道，ICE 是调度中枢。三者不是替代关系，而是分层协作。不理解 STUN 的 XOR 编码，你看不懂打洞；不理解 TURN 的 Allocation 生命周期，你调不通中继；不理解 ICE 的候选排序，你优化不了连接成功率。源码不会骗人，读一遍，胜过看十篇架构图。