WebRTC 穿越 NAT 的秘诀WebRTC Samples 中 Trickle ICE、STUN/TURN 与 ICE Restart 实战教程【免费下载链接】samplesWebRTC Web demos and samples项目地址: https://gitcode.com/gh_mirrors/sa/samples在 WebRTC 实战开发中NAT 穿透是最让人头疼的环节。本项目 gh_mirrors/sa/samples 是一组官方的 WebRTC Web 演示与代码样例WebRTC Web demos and samples其中 PeerConnection 分类下的 trickle-ice、restart-ice 等示例把 Trickle ICE、STUN/TURN 服务器配置、ICE Restart 三大 NAT 穿透核心机制拆解成了可交互的在线 Demo。本教程带你用这套 WebRTC Samples 快速理解并验证 ICE 候选收集与服务端配置的完整流程。一、为什么 WebRTC 必须穿越 NAT浏览器中的RTCPeerConnection默认只知道本机内网地址host 候选而绝大多数用户都在 NAT/防火墙之后。ICEInteractive Connectivity Establishment协议的作用就是穷举各种可达地址让双方建立一条可用的媒体通道候选类型含义常见场景host本机网卡地址同一局域网直连srflx经 STUN 服务器反射出的公网地址普通办公/家庭网络relay经 TURN 服务器中转的地址对称型 NAT、双向防火墙prflx打洞过程中被动发现的反射地址边缘情况二、Trickle ICE 实战边收集边传输候选传统 ICE 要等所有候选收齐后才能交换完整 SDP等待时间长Trickle ICE则把acandidate行从 SDP 中剥离通过信令通道发现一个、发送一个显著降低建联延迟。WebRTC 各浏览器现已默认使用 Trickle ICE。2.1 打开官方 Demo 观察候选收集示例页 trickle-ice/index.html 会创建一个RTCPeerConnection按你配置的 ICE 服务器开始收集候选并以表格实时展示每个候选的类型、协议、地址、端口、优先级最后给出收集耗时与结果Done / Authentication failed? / Not reachable?。核心逻辑位于 trickle-ice/js/main.jsonicecandidate回调每发现一个候选就追加一行直观呈现滴漏过程onicegatheringstatechange监听complete状态判断收集结束getFinalResult()通过候选类型做启发式诊断——只配了 TURN/UDP 却拿不到relay候选时会提示认证失败或服务器不可达见 main.js#L192-L226。2.2 快速配置 STUN 与 TURN 服务器Demo 内置了默认 STUN 地址stun:stun.l.google.com:19302见 main.js#L39-L45你可以在页面上添加自己的 STUN/TURN URI 以及 TURN 的username/credential配置会保存在 localStorage 中方便复测。验证标准很简单页面说明中也写明了这一点STUN 生效能收集到srflx候选TURN 生效能收集到relay候选若把 IceTransports 设为relay则只收集 relay 候选可用于强制走中转的测试。配置项对应RTCConfiguration中的iceServers与iceTransportPolicy示例代码见 main.js#L141-L144。三、STUN 与 TURN 如何分工可以这样理解两者的分工STUN免费照镜子。客户端问 STUN 服务器我的公网地址是什么拿到反射地址后尝试打洞直连速度快、无带宽成本但对称型 NAT 下打洞可能失败。TURN付费中转站。打洞失败时媒体流量经 TURN 服务器中继转发兼容性最好但引入延迟并消耗服务器带宽。生产环境的最佳实践是同时配置 STUN TURN优先直连打洞失败自动降级到 relay。Trickle ICE 让这种多候选并存成为可能——浏览器会按priority字段RFC 5245 定义Demo 中解析为 type/local pref/component 三段见 main.js#L176-L182择优尝试无需应用层干预。四、ICE Restart连接掉线后的自救机制网络切换WiFi 切 4G、路由器重启、NAT 映射过期都会让已建立的通道失效。此时不必重建RTCPeerConnection只需发起一次 ICE Restart核心动作调用createOffer({ iceRestart: true })生成全新的 ICE ufrag/pwd 并重新走一轮 SDP 交换与候选收集。restart-ice/js/main.js 演示了完整流程页面提供Restart ICE按钮连接进入connected状态后才可用main.js#L116-L121点击后以iceRestart: true重新 createOffer并复用既有的 offer/answer 交换链路通过getStats()读取新的selectedCandidatePair确认恢复后使用的是哪条路径main.js#L217-L250。配合 states 示例可以同时观察signalingState、iceConnectionState、connectionState三组状态机定位卡在disconnected还是failed这类问题。五、常见排查清单 只有 host 候选、没有 srflx→ 检查 STUN 地址是否可解析、端口 3478 是否放行TURN 报 Authentication failed?→ 核对turn:URI 的 username/credential注意 time-based 凭证的过期时间TURN 报 Not reachable?→ 服务器未运行或 3478 UDP 被拦截可尝试?transporttcp连上后频繁闪断→ 监听iceconnectionstatechange进入disconnected后自动触发一次 ICE Restart打洞成功率低→ 为不同运营商/地区部署多组 STUNTURN利用 Trickle ICE 的候选冗余兜底。六、延伸多中继与多路径如果单条路径带宽不够还可以参考 multiple-relay 示例用 videopipe.js 把一路流拆到多条 PeerConnection 上转发实现冗余与负载均衡。总结借助 WebRTC Samples 的三件套你可以系统掌握 NAT 穿透全链路用 trickle-ice 验证 STUN/TURN 配置与候选收集用 restart-ice 掌握掉线自愈用 states 监控状态机。理解了候选类型、优先级与重启机制你的 WebRTC 应用就能在复杂网络环境下稳定连通。【免费下载链接】samplesWebRTC Web demos and samples项目地址: https://gitcode.com/gh_mirrors/sa/samples创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考