4、NAT穿透与ICE框架：STUN/TURN原理、ICE候选者收集过程、P2P连接建立实战、TURN服务器部署

说到WebRTC通话，最让人头疼的问题之一就是NAT穿透。你想想看，两个用户在不同的内网里，怎么才能直接连上？这背后就是ICE框架在起作用。我最早接触这块时也被绕得晕头转向，后来亲手搭了几次环境才真正搞明白。

4.1 为什么需要NAT穿透？

简单说，NAT（网络地址转换）让多个内网设备共享一个公网IP。但这也带来了问题——外部设备没法主动连接内网设备。WebRTC要建立P2P连接，就必须解决这个障碍。

4.2 STUN与TURN：两种穿透策略

ICE框架里有两个关键角色：STUN和TURN。它们解决的问题不同，适用场景也不同。

特性	STUN	TURN
工作原理	客户端向STUN服务器查询自己的公网IP和端口	客户端通过TURN服务器中继所有媒体数据
穿透成功率	约70-80%（取决于NAT类型）	接近100%（但依赖服务器带宽）
延迟	低（P2P直连）	高（多一跳中继）
服务器成本	低（仅信令）	高（需转发媒体流）
典型场景	大部分家庭网络、企业非对称NAT	对称NAT、防火墙限制严格的环境

我个人习惯这样理解：STUN是帮你找到门牌号，TURN是直接帮你开一扇后门。能走STUN就走STUN，走不通再退而求其次用TURN。

4.3 ICE候选者收集过程

ICE（交互式连接建立）的核心思路是：收集所有可能的连接方式，然后逐一尝试，直到找到能用的那条路。

收集过程分为三步：

1. 主机候选者（Host Candidate）：本机网卡的IP和端口，比如192.168.1.100:49152。这个只在同一内网下有用。
2. 反射候选者（Server Reflexive Candidate）：通过STUN查询到的公网IP和端口，比如203.0.113.50:56789。这是最常见的穿透方式。
3. 中继候选者（Relay Candidate）：通过TURN服务器分配的转发地址，比如198.51.100.10:3478。这是最后的保底方案。

4.4 P2P连接建立实战

下面是一个典型的ICE连接建立流程。我用JavaScript代码展示关键步骤：

// 创建RTCPeerConnection
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: 'turn:turn.example.com:3478',
      username: 'user',
      credential: 'pass'
    }
  ]
});

// 监听ICE候选者
pc.onicecandidate = (event) => {
  if (event.candidate) {
    // 通过信令通道发送给远端
    signalingChannel.send({
      type: 'candidate',
      candidate: event.candidate
    });
  }
};

// 监听连接状态
pc.oniceconnectionstatechange = () => {
  console.log('ICE状态:', pc.iceConnectionState);
  // 可能的状态: new, checking, connected, completed, failed, disconnected, closed
};

// 创建Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
signalingChannel.send({ type: 'offer', sdp: offer });

这段代码里，iceServers配置了STUN和TURN服务器。onicecandidate回调会不断触发，每次收到新的候选者就发给对方。双方交换完候选者后，ICE就开始尝试连接。

4.5 TURN服务器部署

部署TURN服务器最常用的方案是coturn。我推荐用Docker部署，省心很多。

下面是一个生产级别的部署示例：

# 使用coturn镜像
docker run -d --network=host \
  -e TURN_LISTEN_PORT=3478 \
  -e TURN_RELAY_PORT=49152-65535 \
  -e TURN_REALM=example.com \
  -e TURN_USER=user:pass \
  -e TURN_MIN_PORT=49152 \
  -e TURN_MAX_PORT=65535 \
  -e TURN_USE_AUTH_SECRET=true \
  -e TURN_SECRET=my-secret-key \
  coturn/coturn

部署完成后，记得检查防火墙规则：

• UDP 3478：TURN控制端口
• UDP 49152-65535：媒体中继端口范围
• TCP 3478：备用控制端口（可选）

4.6 ICE框架整体流程

下面这张图展示了ICE框架从候选者收集到P2P连接建立的完整流程：

整个流程走下来，ICE会按优先级从高到低尝试候选者对。如果主机候选者不通，就试反射候选者；反射候选者也不通，最后才用中继候选者。这个优先级策略保证了尽可能使用低延迟的P2P连接。

4.7 常见问题与排查思路

在实际项目中，ICE连接失败是最常见的故障之一。我总结了几种典型场景：

现象	可能原因	排查方法
ICE状态卡在checking	STUN服务器不可达或NAT类型不兼容	用stunclient测试STUN服务器连通性
只能建立TURN连接	对称NAT或防火墙阻止了UDP	检查NAT类型，考虑部署TURN服务器
连接频繁断开	网络抖动或ICE重启	启用ICE重启机制，增加重试次数
TURN连接超时	TURN服务器带宽不足或端口被封	检查TURN服务器负载和防火墙规则