4、NAT穿透与ICE框架：NAT类型详解、ICE协议核心流程、STUN与TURN服务器的角色
WebRTC 最核心的挑战是什么？说白了，就是让两个浏览器能直接“对话”。但现实很骨感——大部分设备都躲在路由器后面，没有公网 IP。这就引出了我们今天的主角：NAT 穿透与 ICE 框架。
我记得刚接触 WebRTC 那会儿，被 NAT 类型搞得晕头转向。后来踩了不少坑，才慢慢理清头绪。今天我就把这些经验掰开揉碎，跟你好好聊聊。
4.1 NAT 类型详解：你的设备到底藏在哪里？
NAT（网络地址转换）说白了就是路由器帮你“代购”。你发请求时，路由器用自己的公网 IP 和端口替换你的私网信息，等数据回来再转交给你。
但不同的路由器，代购策略不一样。这就分出了四种 NAT 类型：
| NAT 类型 | 映射行为 | 穿透难度 |
|---|---|---|
| 完全锥形 NAT | 映射后，任何外网主机都能通过这个端口访问你 | 容易 |
| 受限锥形 NAT | 只有你曾经发过请求的 IP 才能回访 | 中等 |
| 端口受限锥形 NAT | 必须 IP 和端口都匹配才能回访 | 较难 |
| 对称 NAT | 每次发请求都用不同的端口映射 | 极难 |
关键点：对称 NAT 是 WebRTC 的噩梦。我曾在项目中遇到一个用户，他的路由器就是对称 NAT，结果 P2P 死活连不上。最后只能走 TURN 中继，延迟高了 50ms 左右。
为什么会这样？你想想看，对称 NAT 每次映射端口都不一样。你告诉对方“我用 12345 端口等你”，结果对方发数据时，你的端口已经变成 12346 了。这不就失联了吗？
4.2 ICE 协议核心流程：一场精心策划的“相亲”
ICE（交互式连接建立）就是 WebRTC 的“红娘”。它的任务很简单：帮两个端点找到最佳通信路径。
我个人习惯把 ICE 流程分成三步：
- 收集候选者（Candidate）：每个端点收集自己可能的通信地址
- 交换候选者：通过信令服务器交换候选者列表
- 连通性检查：双方尝试连接，找到最优路径
嗯，这里要注意：候选者有三种类型：
- host 候选者：本机局域网地址，延迟最低
- srflx 候选者：通过 STUN 获取的公网地址
- relay 候选者：通过 TURN 服务器获取的中继地址
ICE 会按照优先级排序：host > srflx > relay。说白了，能直连绝不绕路。
避坑指南：我曾经遇到过一个问题：两个设备都在同一个局域网，按理说应该走 host 直连。但 ICE 却选择了 relay 路径。后来发现是 STUN 服务器返回了错误的公网地址，导致优先级计算混乱。解决方案是：在收集候选者时，先过滤掉明显不合理的地址。
4.3 STUN 与 TURN 服务器的角色
STUN 和 TURN 是 ICE 框架的左膀右臂。但它们的职责完全不同：
| 特性 | STUN | TURN |
|---|---|---|
| 核心功能 | 帮你发现公网 IP 和端口 | 帮你中继数据 |
| 带宽消耗 | 极低（仅信令） | 高（所有数据都经过服务器） |
| 适用场景 | 非对称 NAT 环境 | 对称 NAT 或防火墙限制 |
| 部署成本 | 低 | 高（需要大带宽） |
STUN 的工作原理其实很简单：你向 STUN 服务器发个请求，服务器看看你的源 IP 和端口，然后告诉你“嘿，你的公网地址是 1.2.3.4:5678”。
但 TURN 就复杂多了。它不仅要帮你发现地址，还要帮你转发数据。你想想看，如果所有流量都走 TURN，那服务器带宽成本得多高？
注意：不要滥用 TURN。我见过一些项目，不管三七二十一直接配 TURN 服务器。结果流量暴增，服务器扛不住。正确的做法是：先用 STUN 尝试 P2P，实在不行再 fallback 到 TURN。
4.4 ICE 框架的整体流程
把上面这些串起来，ICE 的完整流程是这样的：
- 应用层创建 PeerConnection
- ICE 层开始收集候选者（host、srflx、relay）
- 通过信令交换 SDP（里面包含候选者信息）
- 双方开始连通性检查（STUN 绑定请求）
- 找到最优路径后，建立 P2P 连接
- 如果 P2P 失败，回退到 TURN 中继
这里有个细节：连通性检查是并发的。ICE 会同时尝试所有可能的组合，谁先成功就用谁。这就像同时走几条路，哪条先到走哪条。
实战经验：我在做音视频通话时，发现 ICE 的连通性检查有时会超时。后来调整了 iceCandidatePoolSize 参数，提前缓存候选者，连接速度提升了不少。
4.5 知识体系总览
下面这张图帮你理清本章的核心逻辑：
这张图把 NAT 类型、ICE 框架和 STUN/TURN 的关系串起来了。你仔细看，NAT 类型决定了穿透难度，ICE 框架负责协调，STUN 和 TURN 提供具体能力。三者缺一不可。
个人建议：在实际项目中，我通常会先部署 STUN 服务器，观察用户 NAT 类型分布。如果对称 NAT 比例超过 10%，再考虑加 TURN。这样能有效控制成本。
好了，关于 NAT 穿透和 ICE 框架，今天就聊到这儿。记住一句话：能直连就别绕路，实在不行再找 TURN 帮忙。这是 WebRTC 网络层的核心哲学。
公众号:蓝海资料掘金营，微信deep3321