14、网络适应性：NAT穿透、ICE重启、连接质量监控、自适应码率
做WebRTC多人视频会议，最头疼的是什么？
不是编码，不是渲染，而是——连不上。
我见过太多项目，本地跑得飞起，一上公网就崩。用户明明在同一个城市，就是看不到对方的画面。说白了，网络环境太复杂了。NAT、防火墙、丢包、抖动……每一个都能让你的视频会议变成“幻灯片会议”。
这一章，我们就来啃这块硬骨头。我会把NAT穿透、ICE重启、连接质量监控、自适应码率这几个核心点，掰开揉碎了讲清楚。
14.1 NAT穿透：让两个内网用户“见面”
先问一个问题：你家电脑的IP是192.168.1.101，你同事家的是192.168.1.102。这两个IP在公网上根本不存在，它们怎么找到对方？
这就是NAT（网络地址转换）要解决的问题。说白了，NAT就像公司前台，内部分机号（私有IP）对外不可见，所有外线电话都先打到前台（公网IP），前台再转给你。
WebRTC做NAT穿透，靠的是ICE框架。ICE不是单一技术，它整合了STUN和TURN两种方案。
核心思路：先尝试最直接的P2P连接（STUN），如果不行，就通过中继服务器转发（TURN）。
14.1.1 STUN：找到你的公网“门牌号”
STUN（Session Traversal Utilities for NAT）的作用很简单：帮你发现自己的公网IP和端口。
流程是这样的：
- 你的客户端向STUN服务器发一个请求：“我是什么IP？”
- STUN服务器看到请求来自某个公网IP:端口，就把它返回给你。
- 你拿到这个公网地址，把它放到SDP里，发给对方。
听起来很完美？但有个坑——锥形NAT和对称型NAT。
我在项目中遇到过，STUN在锥形NAT下工作得很好，但遇到对称型NAT就歇菜了。对称型NAT会给每个目标分配不同的端口映射，STUN拿到的地址只对STUN服务器有效，换一个目标就不行了。
避坑指南：我曾经在一个企业级项目中，发现30%的用户无法建立P2P连接。排查下来，都是对称型NAT搞的鬼。解决方案？老老实实上TURN。
14.1.2 TURN：最后的“救火队员”
TURN（Traversal Using Relays around NAT）就是那个中继服务器。当P2P走不通时，所有媒体数据都通过TURN服务器转发。
代价很明显：带宽成本高、延迟增加。但没办法，这是保底方案。
配置TURN服务器时，我建议你注意两点：
- 带宽预算：一个TURN服务器能支撑多少路视频流？按每路2Mbps算，100路就是200Mbps。别等用户骂了才扩容。
- 地理位置：TURN服务器离用户越近越好。我习惯在全球部署多个TURN节点，用DNS解析做就近接入。
// 配置TURN服务器示例
const iceServers = [
{ urls: 'stun:stun.l.google.com:19302' },
{
urls: 'turn:turn.example.com:3478',
username: 'user',
credential: 'pass'
}
];
const pc = new RTCPeerConnection({ iceServers });14.2 ICE重启：连接断了怎么办？
网络不是一成不变的。用户从WiFi切到4G，或者NAT映射过期了，连接就可能断掉。
ICE重启就是用来处理这种情况的。它不会重建整个PeerConnection，而是重新进行ICE协商，尝试建立新的连接。
14.2.1 什么时候需要ICE重启？
- 网络切换：用户从WiFi切到移动网络，IP变了。
- 连接超时：长时间没有收到对方的数据包。
- 质量恶化：丢包率持续超过阈值，重启可能找到更好的路径。
注意：ICE重启不是万能的。如果TURN服务器都挂了，重启也没用。我建议配合连接质量监控一起使用，别盲目重启。
14.2.2 如何触发ICE重启？
代码很简单，但逻辑要谨慎：
// 触发ICE重启
function restartIce(pc) {
// 创建一个新的offer，并设置iceRestart为true
pc.createOffer({ iceRestart: true })
.then(offer => pc.setLocalDescription(offer))
.then(() => {
// 通过信令服务器发送新的offer给远端
signalingServer.send({
type: 'ice-restart',
sdp: pc.localDescription
});
});
}我个人习惯在重启前先做一次连接质量评估。如果只是短暂抖动，等几秒可能自己恢复。频繁重启反而会让用户体验更差。
14.3 连接质量监控：用数据说话
没有监控，你就是在盲人摸象。WebRTC提供了getStats() API，可以拿到非常详细的连接数据。
14.3.1 关键指标有哪些？
| 指标 | 说明 | 健康值 |
|---|---|---|
| 丢包率 | 发送/接收的数据包丢失比例 | < 1% |
| 往返时延（RTT） | 数据包从发送到确认的时间 | < 200ms |
| 抖动 | 延迟的变化程度 | < 30ms |
| 可用带宽 | 当前网络能承载的比特率 | 视分辨率而定 |
14.3.2 如何采集数据？
我建议每隔1-2秒采集一次，不要过于频繁，否则会影响性能。
// 采集连接质量数据
async function monitorConnection(pc) {
const stats = await pc.getStats();
let report = {};
stats.forEach(report => {
if (report.type === 'candidate-pair' && report.state === 'succeeded') {
report.currentRoundTripTime; // RTT
report.availableOutgoingBitrate; // 可用上行带宽
}
if (report.type === 'inbound-rtp') {
report.packetsLost; // 丢包数
report.packetsReceived; // 接收包数
report.jitter; // 抖动
}
});
// 计算丢包率
if (report.packetsReceived > 0) {
report.lossRate = report.packetsLost /
(report.packetsLost + report.packetsReceived);
}
return report;
}我的经验：别只看平均值。峰值抖动和瞬时丢包率更能反映问题。我曾经遇到一个案例，平均丢包率只有0.5%，但每10秒会有一个2秒的丢包高峰，视频直接卡成PPT。后来加了滑动窗口统计，才抓到这个问题。
14.4 自适应码率：让视频“随网而变”
网络质量是动态的。早上好好的，下午就卡了。自适应码率（ABR）就是让视频编码器根据网络状况，自动调整编码参数。
14.4.1 核心逻辑
说白了就是：网络好，我提高码率，给你高清画质；网络差，我降低码率，保证流畅优先。
WebRTC内置了拥塞控制算法（GCC），它会根据延迟和丢包来估算可用带宽。但默认算法不一定适合你的场景，我建议自己做一层封装。
14.4.2 实现一个简单的ABR控制器
class ABRController {
constructor() {
this.currentBitrate = 1000; // 初始码率 1Mbps
this.minBitrate = 200; // 最低 200Kbps
this.maxBitrate = 4000; // 最高 4Mbps
this.lastAdjustTime = 0;
}
// 根据网络质量调整码率
adjustBitrate(networkStats) {
const now = Date.now();
// 每2秒调整一次，避免频繁波动
if (now - this.lastAdjustTime < 2000) return;
let newBitrate = this.currentBitrate;
// 丢包率 > 5%，降低码率
if (networkStats.lossRate > 0.05) {
newBitrate = Math.max(
this.minBitrate,
this.currentBitrate * 0.8
);
}
// RTT > 300ms，降低码率
else if (networkStats.rtt > 300) {
newBitrate = Math.max(
this.minBitrate,
this.currentBitrate * 0.9
);
}
// 网络良好，尝试提升码率
else if (networkStats.lossRate < 0.01 && networkStats.rtt < 150) {
newBitrate = Math.min(
this.maxBitrate,
this.currentBitrate * 1.05
);
}
this.currentBitrate = newBitrate;
this.lastAdjustTime = now;
// 应用新的码率
this.applyBitrate(newBitrate);
}
applyBitrate(bitrate) {
// 通过编码器参数或RTCRtpSender.setParameters()调整
const sender = pc.getSenders()[0];
const params = sender.getParameters();
params.encodings[0].maxBitrate = bitrate * 1000;
sender.setParameters(params);
}
}注意：码率调整不要太激进。我见过一个项目，码率每秒钟都在变，视频画面忽清忽糊，用户反而更难受。建议加一个“稳定期”逻辑：调整后至少保持3秒，除非网络急剧恶化。
14.5 知识体系总览
下面这张图，把本章的核心逻辑串起来了：
你看，整个网络适应性其实是一个闭环：先通过STUN/TURN打通网络，用ICE管理连接，然后持续监控质量，最后根据质量动态调整码率。任何一个环节出问题，都会影响用户体验。
总结一下：
- NAT穿透：STUN打洞，TURN兜底
- ICE重启：网络变了就重新协商，别硬撑
- 质量监控：用getStats()拿数据，别靠感觉
- 自适应码率：网络好就高清，网络差就流畅
嗯，这一章的内容就到这里。网络适应性是个大话题，但核心逻辑并不复杂。你只要把这几块串起来，就能应对大部分网络场景了。