Page 298 - Web性能权威指南

考虑到性能，我们也必须明白，在实际发送数据之前，可能会经历从 STUN 服务器
到通信端之间的很多次往返——当然，前提是 ICE 协商成功！

18.4.4 增量提供（Trickle ICE）

ICE 收集过程决非瞬间就能完成的：取得本地 IP 地址很快，但查询 STUN 服务器
需要经过到外部服务器的往返，然后还有另一次端到端的 STUN 连接检查。Trickle
ICE 是对 ICE 协议的扩展，用意在于实现端与端之间的增量收集和连接检查。这个
用意其实很简单：

• 两端交换没有 ICE 候选项的 SPD 提议；
• 发现 ICE 候选项之后，通过发信通道发送到另一端；
• 新候选描述一就绪，立即执行 ICE 连接检查。

简言之，就是不等到 ICE 收集过程完成，而是依靠发信通道向另一端递增地交付更
新，从而加快协商。相应的 WebRTC 实现当然也很简单：

var ice = {"iceServers": [
{"url": "stun:stun.l.google.com:19302"},
{"url": "turn:user@turnserver.com", "credential": "pass"}
]};

var pc = new RTCPeerConnection(ice);
navigator.getUserMedia({ "audio": true }, gotStream, logError);

function gotStream(stream) {
pc.addstream(stream);
pc.createOffer(function(offer) {
pc.setLocalDescription(offer);
signalingChannel.send(offer.sdp); ➊
});
}

pc.onicecandidate = function(evt) {
if (evt.candidate) {
signalingChannel.send(evt.candidate); ➋
}
}
signalingChannel.onmessage = function(msg) {
if (msg.candidate) {
pc.addIceCandidate(msg.candidate); ➌
}
}

➊ 发送不包含 ICE 候选项的 SDP 提议
➋ 本地 ICE 代理发现一个 ICE 候选项后就立即发送

288 ｜ 第 18 章