9、ICE与网络穿透：ICE协议原理、STUN与TURN的区别、NAT穿透实战、ICE状态回调处理

做WebRTC开发，绕不开一个核心问题：两个设备怎么在互联网上找到对方？

你想想看，咱们平时在公司、在家、在咖啡厅，设备都在局域网里，背后是各种路由器、防火墙。A设备想跟B设备直接通信，中间隔着NAT（网络地址转换），这就像两个人各自躲在不同的房间里，只能通过门缝喊话。ICE协议就是那个帮你们找到彼此、甚至帮你们搭桥的“通信兵”。

我个人习惯把ICE理解成一套“找路策略”。它不保证一定能直连，但它会穷尽所有可能——直连不行就中继，中继还不行？嗯，那基本就是网络环境太极端了。

9.1 ICE协议原理：它到底在干什么？

ICE的全称是Interactive Connectivity Establishment，交互式连接建立。说白了，就是让两端设备交换所有可能的连接方式，然后选一条能用的。

ICE的核心逻辑其实很简单：

  1. 收集候选者（Candidate）：每个设备把自己能用的IP和端口都列出来。
  2. 交换候选者：通过信令服务器，把候选列表发给对方。
  3. 连通性检查：两端互相尝试连接，看哪条路能通。
  4. 选最优路径：能通的里面，选延迟最低、质量最好的。

我在项目中遇到过一个问题：有个客户反馈视频会议经常连不上，排查了半天，发现是ICE的候选者收集阶段超时了。后来加了STUN服务器，问题就解决了。所以ICE不是万能的，它需要外部辅助。

核心要点：ICE本身不解决NAT穿透，它只是“组织者”。真正干活的是STUN和TURN。

ICE协议工作流程 设备A 设备B 信令服务器 ① 收集候选者 ① 收集候选者 ② 发送候选者 ③ 转发候选者 ④ 发送候选者 ⑤ 转发候选者 ⑥ 连通性检查（STUN打洞） ⑦ 建立P2P连接

9.2 STUN与TURN的区别：一个指路，一个带路

很多初学者搞不清STUN和TURN的区别。我打个比方：

  • STUN 就像你站在房间里，问门外的人“我现在的门牌号是多少？”——它帮你发现自己的公网IP和端口。
  • TURN 就像你出不去，让快递员帮你把东西送到对方手里——它帮你中继数据。

具体来说：

特性 STUN TURN
作用 获取公网映射地址 中继转发媒体数据
带宽消耗 极低（仅信令） 高（转发音视频流）
延迟 低（直连） 较高（多一跳）
适用场景 NAT类型支持直连 对称NAT或防火墙限制
成本 低（轻量服务器） 高（需要大带宽）

我的建议：优先用STUN，TURN作为兜底。我曾经见过一个项目，为了省事直接全走TURN，结果服务器带宽费用一个月好几万。后来优化成STUN优先，成本降了80%。

9.3 NAT穿透实战：Android端如何配置

在Android上配置ICE，核心就是设置PeerConnection的IceServer。代码其实不多，但配置错了就全白搭。

// 创建ICE服务器列表
List<PeerConnection.IceServer> iceServers = new ArrayList<>();

// STUN服务器（用于获取公网地址）
String stunUrl = "stun:stun.l.google.com:19302";
iceServers.add(PeerConnection.IceServer.builder(stunUrl).createIceServer());

// TURN服务器（用于中继）
String turnUrl = "turn:your-turn-server.com:3478";
String username = "your-username";
String credential = "your-credential";
iceServers.add(
    PeerConnection.IceServer.builder(turnUrl)
        .setUsername(username)
        .setPassword(credential)
        .createIceServer()
);

// 创建配置
PeerConnection.RTCConfiguration config = 
    new PeerConnection.RTCConfiguration(iceServers);

// 关键配置：ICE重启策略
config.iceTransportsType = PeerConnection.IceTransportsType.ALL;
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE;
config.rtcpMuxPolicy = PeerConnection.RtcpMuxPolicy.REQUIRE;
config.continualGatheringPolicy = PeerConnection.ContinualGatheringPolicy.GATHER_CONTINUALLY;

// 创建PeerConnection
PeerConnectionFactory factory = PeerConnectionFactory.builder()
    .setOptions(options)
    .createPeerConnectionFactory();

PeerConnection connection = factory.createPeerConnection(config, observer);

这里有几个坑，我踩过：

  • STUN地址别写错：Google的公共STUN是stun:stun.l.google.com:19302，端口别写成443。
  • TURN的认证信息：有些TURN服务器用长期凭证，有些用临时token。我建议用临时token，安全性更高。
  • GATHER_CONTINUALLY：这个配置让ICE持续收集候选者，而不是只收集一次。网络变化时特别有用。

注意：不要在生产环境直接使用Google的公共STUN服务器。它只适合测试。生产环境请自建STUN/TURN服务器，或者用云服务商提供的方案。

9.4 ICE状态回调处理：别让连接断了你都不知道

ICE连接状态的变化，是WebRTC开发中最容易忽略但又最关键的部分。我见过太多App，视频通话突然断了，用户一脸懵，代码里连个日志都没打。

Android上通过PeerConnection.Observer来监听ICE状态：

private PeerConnection.Observer observer = new PeerConnection.Observer() {
    
    @Override
    public void onIceConnectionState(IceConnectionState state) {
        switch (state) {
            case NEW:
                Log.d("ICE", "连接初始化");
                break;
            case CHECKING:
                Log.d("ICE", "正在检查连通性...");
                showConnectingUI();
                break;
            case CONNECTED:
                Log.d("ICE", "连接成功！");
                hideConnectingUI();
                break;
            case COMPLETED:
                Log.d("ICE", "连接完成，候选者全部检查完毕");
                break;
            case DISCONNECTED:
                Log.w("ICE", "连接断开，尝试重连...");
                attemptReconnection();
                break;
            case FAILED:
                Log.e("ICE", "连接失败，需要重新协商");
                restartIce();
                break;
            case CLOSED:
                Log.d("ICE", "连接已关闭");
                break;
        }
    }

    @Override
    public void onIceCandidate(IceCandidate candidate) {
        // 收集到候选者，通过信令发送给对方
        signalingClient.sendCandidate(candidate);
    }

    @Override
    public void onIceCandidatesRemoved(IceCandidate[] candidates) {
        // 候选者被移除（网络变化时）
        signalingClient.removeCandidates(candidates);
    }
};

这里我特别想强调DISCONNECTED和FAILED的区别：

  • DISCONNECTED：网络暂时波动，ICE还在尝试恢复。你可以等几秒，不行再重连。
  • FAILED：彻底没戏了，必须重新创建PeerConnection。

我曾经在项目中遇到一个bug：网络切换时（比如WiFi切4G），ICE状态变成DISCONNECTED，但代码里直接调了close()，导致用户必须重新进入会议室。后来改成先等5秒，如果没恢复再重连，体验就好了很多。

实战建议：在onIceConnectionState回调里加一个状态机，记录当前状态。这样调试时能清楚看到状态流转，排查问题快很多。

9.5 候选者优先级：ICE怎么选最优路径？

ICE收集到的候选者不止一个。比如：

  • 本地IP（192.168.x.x）
  • 公网IP（经过STUN映射后的）
  • 中继地址（TURN服务器分配的）

ICE会给每个候选者打分，分数越高越优先。规则大致是：

  1. 本地候选者优先级最高（同局域网延迟最低）
  2. STUN映射的候选者次之（能直连就不中继）
  3. TURN中继候选者优先级最低（兜底方案）

你可以在代码里通过onIceCandidate看到每个候选者的sdpMLineIndex和sdpMid，但一般不需要手动干预。ICE自己会选最优的。

小技巧：调试时打印所有候选者，看看有没有公网IP。如果只有本地IP和TURN地址，说明STUN没生效，检查一下网络配置。

9.6 常见问题与避坑指南

做ICE这块，我踩过的坑能写满一页纸。挑几个典型的说说：

  • STUN请求超时：有些企业网络会屏蔽STUN的端口（3478）。我建议备选多个STUN服务器。
  • TURN认证过期：如果TURN用临时token，记得在过期前重新获取。否则通话会突然中断。
  • ICE重启时机：不要频繁重启ICE。网络波动时，先等几秒，让ICE自己恢复。实在不行再重启。
  • 候选者太多：如果设备有多个网卡（比如VPN），候选者列表会很长。可以用IceTransportsType.RELAY强制只用TURN，但一般不推荐。

曾经我踩过的坑：有一次线上事故，用户反馈视频会议经常卡死。查了半天，发现是ICE在DISCONNECTED状态时，UI线程做了耗时操作，导致ANR。后来把重连逻辑放到子线程，问题解决。记住：ICE回调可能不在主线程，UI操作记得切线程。

好了，ICE这块的内容就这些。说白了，它就是WebRTC的“交通指挥员”——帮你找到路，走不通就换条路，实在不行就绕道。理解了这一点，后面的开发就会顺畅很多。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →