对称型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
初始化时需显式提供：
-
username：短期凭证（如"20240520:1716220800"），非固定账号 -
password：对应HMAC-SHA1摘要（服务端生成，有效期通常≤24h） -
realm：必须和服务端realm配置完全一致，区分大小写 - 若服务端启用了
tls或tcptransport，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地址被回收，已建立的媒体流会静默中断。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
