Page 297 - Web性能权威指南
P. 297
前面的例子使用了谷歌的公共演示 STUN 服务器。可惜的是，只有 STUN
还不够（参见 3.2.3 节中的“现实中的 STUN 和 TURN”），可能还需要再
提供一个 TURN，以保证那些不能直接端到端连接的用户能够建立连接
（大约 8%）。
正像这个例子所展示的，ICE 代理替我们处理了大部分复杂工作：ICE 收集过
程是自动触发的，STUN 查找是在后台执行的，而发现的候选项也会自动通过
RTCPeerConnection 对象注册。上述过程完成后，我们可以生成 SDP 提议，并通过
发信通道发送给另一端。另一端接收到 ICE 候选项后，就可以进行第二步——建立
端到端的连接了：只要 RTCPeerConnection 对象设置了远程会话描述（包含另一端
的一组候选 IP 和端口号），ICE 代理就会执行连接检查（图 18-8），以确定能否抵达
另一端。
图 18-8：WireShark 中端到端 STUN 绑定请求与响应的截图
ICE 代理发送消息（STUN 绑定请求），另一端接收之后必须以一个成功的 STUN 响
应确认。如果这个过程完成，那么就代表着有了一条端到端连接的路由线路！相反，
如果所有候选项都绑定失败，要么将 RTCPeerConnection 标记为失败，要么回退到
靠 TURN 转发服务器建立连接。
ICE 代理自动确定连接检查时候选项的次序和优先级：首先检查本地 IP 地
址，然后是公共 IP，最后才检查 TURN。建立连接后，ICE 代理周期性地
向另一端发送 STUN 请求，以此保证连接的持久化。
好麻烦！正如本节开头说的，初始化端到端的连接请求，比打开 XHR、EventSource
或新 WebSocket 会话要麻烦得多。好在，大部分工作都有浏览器替我们干。可是，
WebRTC ｜ 287
