对称型NAT下UDP打洞必然失败，必须依赖TURN中继：其为每个外部目标分配不同映射端口，导致STUN获取的公网地址在对方不可达；TURN通过中转数据绕过该限制，但需严格遵循RFC 5766鉴权、channel绑定与lifetime刷新机制。

对称NAT下直接UDP打洞必然失败，TURN是唯一可行路径

对称NAT会为每个外部目标地址+端口组合分配不同的内网映射端口，导致STUN获取的“公网地址”在对方视角完全不可达。此时STUN只能用于检测NAT类型，无法完成P2P穿透；必须依赖TURN服务器中继——你的数据包发给TURN，它再原样转发给对端，绕过NAT映射不可预测的问题。

libnice + GStreamer或Pion WebRTC是当前最稳妥的C++实现选择

自己从零实现TURN客户端几乎不可行：需完整支持RFC 5766（TURN）、RFC 6062（TCP relaying）、channel binding、HMAC-SHA1鉴权、碎片重传与心跳保活。实际项目中应复用成熟库：

• libnice（GNOME生态，C接口，与GStreamer深度集成，生产环境验证充分）
• Pion WebRTC（纯C++，header-only倾向，API清晰，但TURN仅支持UDP relay，不支持TCP/TLS通道）
• 避免用restund或自研STUN/TURN server——它们常缺ALTERNATE-SERVER重定向、REALM参数协商等关键逻辑，导致鉴权失败静默丢包

TURN URI格式和凭据必须严格匹配服务端配置

常见错误不是代码写错，而是turn:xxx?transport=udp里漏了?transport=udp，或服务端要求REALM而客户端没填。典型合法URI：

turn:192.168.1.100:3478?transport=udp

初始化时需显式提供：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

立即学习“C++免费学习笔记（深入）”；

• username：短期凭证（如"20240520:1716220800"），非固定账号
• password：对应HMAC-SHA1摘要（服务端生成，有效期通常≤24h）
• realm：必须和服务端realm配置完全一致，区分大小写
• 若服务端启用了tls或tcp transport，URI必须改为turns:或加&transport=tcp，否则连接直接被拒绝

中继流量走sendto()而非connect()，且需处理401 Unauthorized重试

TURN客户端本质是UDP socket上模拟可靠传输：所有应用数据都封装进ChannelData或Data Indication消息，发往TURN服务器的固定端口（如3478）。关键细节：

• 不能对TURN服务器地址调用connect()——这会丢失recvfrom()返回的源地址信息，导致无法识别哪个channel对应哪路媒体流
• 首次请求必收401 Unauthorized响应，含NONCE和REALM；必须用该NONCE重新计算MESSAGE-INTEGRITY并重发，否则后续所有包被丢弃
• 每路媒体流需先Allocate获得relay address，再CreatePermission放行目标IP，最后ChannelBind绑定channel number——少一步，数据就发不出去

真正难的不是连上TURN，而是确保每个Allocate响应里的lifetime被正确刷新，以及Refresh请求在超时前发出——超时后relay地址被回收，已建立的媒体流会静默中断。