📚 课程目录第4章网络传输与ICE穿透

4、网络传输与ICE穿透：STUN/TURN服务器部署、ICE连接状态监控、NAT穿透问题排查

各位做嵌入式WebRTC的同行，咱们都知道一个道理：媒体流能不能通，七成看网络穿透。ICE（Interactive Connectivity Establishment）这套机制，说白了就是帮两个设备在复杂的NAT环境中找到一条能用的路。我这些年调试过的嵌入式设备，从摄像头到机器人，十次通话故障里有八次是卡在ICE协商阶段。

这一章，咱们就把STUN/TURN的部署、ICE状态机的监控、以及NAT穿透的常见坑位，一个一个捋清楚。

4.1 STUN与TURN：穿透的左右手

先搞清楚这两个东西的角色。STUN（Session Traversal Utilities for NAT）负责探测公网映射地址，TURN（Traversal Using Relays around NAT）负责中继转发媒体流。我习惯这么记：STUN帮你找路，TURN帮你修路。

特性	STUN	TURN
核心功能	获取公网IP:Port映射	中继转发媒体数据
带宽消耗	极低（仅信令）	高（转发全部媒体流）
服务器负载	轻量	较重
适用场景	非对称NAT、Cone NAT	Symmetric NAT、防火墙限制
嵌入式部署	可部署在低配云服务器	需要较高带宽和计算资源

我的经验：在嵌入式项目中，我通常先只部署STUN。如果发现ICE候选者类型全是"relay"，再考虑加TURN。别一上来就上TURN，带宽和成本都扛不住。

4.2 部署STUN/TURN服务器

我个人最常用的开源方案是 coturn，它同时支持STUN和TURN协议，在ARM架构的嵌入式网关上也能跑。下面是一个典型的生产级配置。

# /etc/turnserver.conf 核心配置
listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
user=webrtc:secret123
realm=example.com
total-quota=100
stale-nonce=600
no-loopback-peers
no-multicast-peers
mobility

部署时要注意几个关键点：

端口开放：UDP 3478（STUN/TURN）、TCP 3478（TURN备用）、UDP 49152-65535（媒体中继端口池）
认证方式：生产环境必须用lt-cred-mech（长期凭证机制），别用临时凭证
公网IP绑定：如果服务器有多网卡，用external-ip指定公网IP

避坑指南：我曾经在一台只有1核1G的云服务器上部署coturn，结果并发超过20路通话时，CPU直接飙到100%。后来加了total-quota=50限制并发，才稳定下来。嵌入式环境资源更紧张，一定要做限流。

4.3 ICE连接状态监控

ICE状态机是调试的核心。WebRTC的iceConnectionState会经历几个阶段，每个阶段都对应不同的网络状况。

// 嵌入式端ICE状态回调示例
peerConnection->OnIceConnectionState(
    [](webrtc::PeerConnectionInterface::IceConnectionState state) {
        switch (state) {
            case IceConnectionState::kIceConnectionNew:
                printf("[ICE] 新连接，开始收集候选者\n");
                break;
            case IceConnectionState::kIceConnectionChecking:
                printf("[ICE] 正在检查候选者对...\n");
                break;
            case IceConnectionState::kIceConnectionConnected:
                printf("[ICE] 已连接！使用中继或直连\n");
                break;
            case IceConnectionState::kIceConnectionCompleted:
                printf("[ICE] 连接完成，所有候选者已评估\n");
                break;
            case IceConnectionState::kIceConnectionFailed:
                printf("[ICE] 连接失败！所有候选者都不可用\n");
                break;
            case IceConnectionState::kIceConnectionDisconnected:
                printf("[ICE] 连接断开，可能网络波动\n");
                break;
            case IceConnectionState::kIceConnectionClosed:
                printf("[ICE] 连接已关闭\n");
                break;
        }
    });

在实际调试中，我重点关注两个状态：

kIceConnectionChecking：如果停留超过5秒，说明候选者对质量差或STUN/TURN不可达
kIceConnectionFailed：直接宣告穿透失败，需要检查NAT类型和服务器配置

4.4 NAT穿透问题排查

NAT穿透失败，是嵌入式WebRTC最常见的故障。我总结了一套排查流程，按步骤来基本能定位问题。

确认NAT类型：用stunclient工具测试，看是Full Cone、Restricted Cone还是Symmetric NAT
检查STUN可达性：从嵌入式设备ping STUN服务器的3478端口，确认UDP能通
验证候选者列表：在ICE回调中打印所有候选者，看有没有srflx（STUN反射地址）
对比本地和反射地址：如果反射地址和本地地址在同一网段，说明STUN没穿透NAT
强制使用TURN：如果以上都正常但连接还是失败，尝试iceTransportPolicy: relay强制走中继

关键指标：在日志中搜索"candidate:"字段，如果只有"host"类型候选者，没有"srflx"或"relay"，那问题一定出在STUN/TURN的连通性上。

下面这张图展示了ICE候选者收集和选择的完整流程，我建议你把它打印出来贴在工位上。

4.5 实战：日志分析定位穿透问题

嗯，这里要重点说说日志。嵌入式设备不像PC端有完善的调试工具，很多时候只能靠日志来还原现场。我习惯在ICE回调里加入时间戳和候选者详情。

[2025-03-15 10:23:45.123] [ICE] State: kIceConnectionNew
[2025-03-15 10:23:45.456] [ICE] Local candidate: host 192.168.1.100:5000
[2025-03-15 10:23:45.789] [ICE] STUN request sent to 203.0.113.5:3478
[2025-03-15 10:23:46.012] [ICE] STUN response received: srflx 100.64.0.1:15000
[2025-03-15 10:23:46.345] [ICE] Remote candidate: host 10.0.0.50:6000
[2025-03-15 10:23:46.678] [ICE] State: kIceConnectionChecking
[2025-03-15 10:23:47.001] [ICE] Connectivity check: srflx 100.64.0.1:15000 <-> host 10.0.0.50:6000
[2025-03-15 10:23:47.334] [ICE] State: kIceConnectionConnected

从这段日志能看出什么？

STUN请求耗时约223ms，说明网络延迟正常
反射地址是100.64.0.1，这是运营商级NAT（CGNAT）的典型地址段
最终通过srflx和远程host候选者建立了连接，说明是Restricted Cone NAT

我的习惯：在嵌入式设备上，我会把ICE日志循环写入一个环形缓冲区，保留最近100条记录。这样当通话质量出问题时，可以一键导出日志，不用提前开启抓包。

4.6 常见NAT场景与应对策略

NAT类型	特征	穿透策略	嵌入式注意事项
Full Cone	任何外部主机都能通过映射地址通信	STUN即可	最简单，但现实中很少见
Restricted Cone	只允许目标IP曾发过包的地址回包	STUN + 端口预测	大部分家用路由器属于此类
Port Restricted Cone	限制IP和端口	STUN + 精确端口匹配	企业防火墙常见
Symmetric NAT	每个目标IP:Port映射不同公网端口	必须用TURN	4G/5G移动网络典型场景

为什么会这样？Symmetric NAT每次对外通信都分配不同的端口，STUN拿到的映射地址只对STUN服务器有效，对端设备根本用不了。这时候只能走TURN中继。

避坑指南：我曾经在一个4G物联网项目中，所有设备都走Symmetric NAT，但我只部署了STUN服务器。结果ICE协商全部失败，通话建立率不到10%。后来加上TURN服务器，建立率直接提升到95%以上。记住：移动网络场景，TURN不是可选项，是必选项。

4.7 性能优化与资源控制

嵌入式设备的资源有限，ICE协商不能无限制消耗CPU和内存。我建议做以下限制：

候选者数量上限：每个ICE会话最多收集10个候选者，避免过多组合导致检查爆炸
连通性检查超时：单个候选者对检查超时设为500ms，总检查时间不超过10秒
ICE重启策略：连续3次连接失败后，间隔30秒再重启ICE，避免频繁重试

// 嵌入式ICE配置示例
webrtc::PeerConnectionInterface::RTCConfiguration config;
config.ice_candidate_pool_size = 5;  // 预生成候选者池
config.ice_connection_receiving_timeout = 1000;  // 1秒无数据视为断开
config.ice_backup_candidate_pair_ping_interval = 500;  // 备用候选者探测间隔