持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第2天，点击查看活动详情
一、 什么是ICE？
ICE是针对NAT问题的综合性解决方案，ICE用于NAT穿透，确定媒体流传输地址。
二、ICE的流程分为三步：
- 收集candidates
获取本机host address
从STUN服务器获取srvflx address
从TURN服务器获取relay address
- 交换candidates
发起offer的一方称为主叫方，Web A为主叫方。在A获取到candidates后，会在offer携带。被叫方Web B收到offer，开始收集candiates，收集完后，在answer消息中携带。(sdp中的a=candidate属性行携带本端的candidates地址)
- 按优先级进行连通检查
先发起offer的一方，必须等到收到answer消息拿到对方地址后才开始进行连通测试。被叫方也是等到回了answer消息后才开始进行连通测试。双方相互通过stun中Binding request和Binding response 进行，发出的Bingding request，如果收到response，则代表连通性检查成功，否则需要进行重传直到超时，则认为不可连通。双方各自进行。
以上只是ICE的核心流程，可以看到整个过程是应答式的，发出请求，等到响应才会开始下一步，整个过程非常耗时。直接的现象就是首屏会很慢。
三、candiate属性简介
candiate属性是ICE中用来描述可以用来和本地通信的地址相关的信息，这个信息一般仅需要三个要素：IP、端口、传输方式，但是为了完成整个ICE的协议的运作流程，对于一个candidate来说，还需要其他的一些和ICE协议相关的信息。
- candidate格式
candidate的格式可以在RFC8839中找到，相关的定义如下：
candidate-attribute = “candidate” “:”
foundation SP
component-id SP
transport SP
priority SP
connection-address SP ;from RFC 4566
port SP ;port from RFC 4566
cand-type
[SP rel-addr]
[SP rel-port]
*(SP cand-extension)
- 相关参数的类型：
foundation = 1*32ice-char
component-id = 1*3DIGIT
transport = “UDP” / transport-extension
transport-extension = token ; from RFC 3261
priority = 1*10DIGIT
cand-type = “typ” SP candidate-types
candidate-types = “host” / “srflx” / “prflx” / “relay” / token
rel-addr = “raddr” SP connection-address
rel-port = “rport” SP port
cand-extension = extension-att-name SP extension-att-value
extension-att-name = token
extension-att-value = *VCHAR
ice-char = ALPHA / DIGIT / “+” / “/”
更多详细的内容可以参考webrtc在github的地址，里面还有很多详细的例子：webrtc github
