4、P2P连接建立：ICE框架在ARM上的适配、STUN/TURN服务器配置、NAT穿透实战

WebRTC 的核心魅力在于浏览器之间能直接传数据，不经过服务器中转。但现实很骨感——大部分设备都躲在路由器后面，没有公网 IP。这时候就需要 ICE 框架出马了。

说白了，ICE 就是个协调者。它帮你收集所有可能的网络路径，然后一条条试，直到找到能通的那条。在 ARM 设备上做这件事，坑比 x86 多不少。我最早在树莓派上跑 WebRTC 时，就遇到过 ICE 状态卡在 checking 不动的情况，折腾了两天才发现是 STUN 请求超时时间设得太短。

4.1 ICE 框架在 ARM 上的适配要点

ICE 本身是协议层的概念，跟 CPU 架构关系不大。但具体实现时，ARM 平台的资源限制会直接影响 ICE 的行为。

适配维度 ARM 上的常见问题 我的建议
ICE 候选者收集 多网卡场景下收集耗时过长 限制接口枚举范围，只监听活跃网卡
连接检查超时 默认 500ms 在弱网 ARM 设备上不够 放宽到 1000-1500ms
ICE 重启频率 网络切换时频繁触发 ICE restart 增加去抖逻辑，避免风暴
内存占用 候选者对列表膨胀导致 OOM 限制最大候选者数量（建议 10 个以内）

核心原则：ARM 设备上 ICE 的配置不能照搬 PC 端。PC 端可以任性收集几十个候选者，ARM 上必须做减法。

我记得有一次在 RK3588 开发板上做测试，默认配置下 ICE 收集到了 20 多个候选者，包括各种 IPv6 链路本地地址。连接检查阶段直接卡死。后来我把 IceTransportsType 设为 relay，只走 TURN 中继，问题立刻解决。

4.2 STUN/TURN 服务器配置实战

STUN 和 TURN 是 ICE 的左膀右臂。STUN 帮你发现公网映射地址，TURN 则是在打洞失败时做最后的中继保底。

4.2.1 自建 STUN 服务器

我习惯用 coturn 项目，它同时支持 STUN 和 TURN。在 ARM 上编译 coturn 需要注意交叉编译工具链的选择。

# 在 ARM 设备上直接编译（以树莓派为例）
sudo apt install build-essential libssl-dev libevent-dev
wget https://github.com/coturn/coturn/archive/refs/tags/4.6.2.tar.gz
tar xzf 4.6.2.tar.gz
cd coturn-4.6.2
./configure
make -j4
sudo make install

# 启动 STUN 服务（仅 STUN 模式）
turnserver -n -L 0.0.0.0 -p 3478 --stun-only

小技巧：ARM 设备上编译 coturn 时，加上 --with-openssl 可以启用 DTLS 支持。但如果你只是做内网测试，建议关掉，能省不少 CPU 资源。

4.2.2 TURN 服务器配置

TURN 服务器需要配置用户认证和带宽限制。我在项目中遇到过 TURN 连接被客户端频繁断开的问题，后来发现是 total-quota 设得太低。

# /etc/turnserver.conf 关键配置
listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
user=webrtc:password123
realm=arm-turn.local
total-quota=100
stale-nonce=600
max-bps=512000  # 限制带宽 512kbps，避免 ARM 设备过载
参数 说明 ARM 推荐值
total-quota 最大并发连接数 50-100（视内存而定）
max-bps 单连接最大带宽 512000-1024000
stale-nonce 认证令牌有效期 600（秒）
realm 认证域 自定义，不要用默认值

4.3 NAT 穿透实战

NAT 穿透是 ICE 最核心的价值。不同类型的 NAT 设备，穿透策略完全不同。

4.3.1 NAT 类型识别

我建议在正式部署前，先用工具摸清网络环境。ARM 设备上可以用 stunclient 快速测试。

# 安装 stun 测试工具
sudo apt install stun-client

# 测试 NAT 类型
stunclient stun.l.google.com 19302

# 输出示例
# Binding test: success
# Local address: 192.168.1.100:54321
# Mapped address: 123.45.67.89:54321
# Behavior test: success
# NAT type: Full Cone

注意：ARM 设备如果通过 4G 模块上网，NAT 类型通常是 Symmetric（对称型）。这种类型下，STUN 基本失效，必须依赖 TURN 中继。我在一个户外监控项目中就踩过这个坑，4G 网络下 P2P 始终连不上，最后全部切成了 TURN 模式。

4.3.2 ICE 连接状态机

ICE 的连接过程可以简化为以下几个阶段。理解这个状态机，调试时能少走很多弯路。

ICE 连接状态机 New Checking Connected Failed Completed Disconnected Checking → Connected 表示 P2P 打洞成功；Checking → Failed 则需回退到 TURN 中继

4.3.3 代码层面的 ICE 配置

在 ARM 设备上，我建议在创建 RTCPeerConnection 时显式指定 ICE 服务器列表和传输策略。

// JavaScript 示例
const iceConfig = {
  iceServers: [
    { urls: 'stun:192.168.1.200:3478' },
    {
      urls: 'turn:192.168.1.200:3478',
      username: 'webrtc',
      credential: 'password123'
    }
  ],
  iceTransportPolicy: 'relay',  // 强制走 relay，适合弱网环境
  iceCandidatePoolSize: 5       // ARM 设备建议不超过 10
};

const pc = new RTCPeerConnection(iceConfig);

// 监听 ICE 状态变化
pc.oniceconnectionstatechange = () => {
  console.log('ICE state:', pc.iceConnectionState);
  // 实际项目中，这里可以触发 UI 提示或自动重连
};

避坑指南：我曾经在 ARM 设备上把 iceCandidatePoolSize 设为 20，结果内存直接飙到 200MB+。对于 1GB 内存的设备，建议控制在 5 以内。

4.4 多路通话场景下的 ICE 优化

多路通话意味着每个连接都要跑一套 ICE 流程。ARM 设备的 CPU 和网络资源有限，必须做优化。

  • 复用 TURN 连接：同一个 TURN 服务器可以服务多个 PeerConnection，不需要为每个连接都建新通道。
  • ICE 优先级调整：多路场景下，优先使用 host 候选者（局域网直连），避免所有连接都走 TURN 中继。
  • 连接池化：维护一个 ICE 连接池，复用已建立的 P2P 通道。
场景 推荐策略 ARM 实测效果
4 路通话（局域网） host 候选者优先 CPU 占用 < 15%
4 路通话（公网） relay 候选者保底 CPU 占用 20-30%
8 路通话（混合网络） 强制 relay + 带宽限制 CPU 占用 40-50%

我的经验：多路通话时，ICE 的日志输出量非常大。建议在生产环境关闭 ICE 的详细日志，只保留状态变更日志。否则 ARM 设备的 I/O 会成为瓶颈。

嗯，ICE 这块内容其实挺深的。今天讲的这些，都是我在 ARM 设备上反复踩坑后总结出来的。你配置的时候，记得先从单路测试开始，确认 STUN/TURN 都正常后，再上多路场景。别一上来就搞 8 路并发，那样出了问题你根本不知道是 ICE 的问题还是带宽的问题。

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