WebRTC中的ICE

ICE简介

ICE是用于UDP媒体传输的NAT穿透协议（适当扩展也可以支持TCP），它需要利用STUN和TURN协议来完成工作。

STUN协议提供了获取一个内网地址对应的公网地址映射关系（NAT Binding）的机制，并且提供了它们之间的保活机制。

TURN协议是STUN协议的一个扩展，允许一个peer只使用一个转发地址就可以和多个peer实现通信。其本质是一个中继协议。

在WebRTC中，ICE会在SDP中增加传输地址信息，利用这个信息进行NAT穿透及确定媒体流传输地址。

ICE Candidate

WebRTC中的ICE Candidate是用来描述可以连接的远端的基本信息，它至少包括（address，port，protocol）三元组，还有Candidate类型、用户名等。

WebRTC将Candidate分成四种类型，且类型间存在优先级次序，从高到低分别为host、srflx、prflx和relay。

• host：从本机网卡上获取到的地址，一般来说，一个网卡对应一个地址。
• srflx（server reflexive）：从STUN服务器获取到的地址。
• relay：从TRUN服务器获取到的地址。
• prflx（peer reflexive）：在联通测试中从对端数据报文中获取到的地址。

其中，srflx和prflx地址可能是一样的，但获取的途径不一样。

ICE的基本流程

ICE的基本流程有三步：收集Candidate，交换Candidate，按优先级尝试连接。

收集Candidate

WebRTC在进行NAT穿透时（也就是俗称的打洞），首先会收集Candidate。客户端会按顺序先获取本地的host地址，然后从STUN服务器获取srflx地址，再从TRUN服务器获取relay地址。

交换Candidate

客户端收集到的这些地址会写到SDP报文中，之后通过信令系统将它们发送给对端。对端收到这些Candidate后，会与本地的Candidate组成CandidatePair。当然，这种组合也是有规则的，比如传输协议相同的Candidate才能组成CandidatePair。

需要说明的是WebRTC中的Candidate交换是使用的trickle方式，也就是边收集边交换。

按优先级尝试连接

WebRTC会将CandidatePair按优先级排序，然后按照这个顺序去进行连通性测试。如果有可以连通的CandidatePair就停止尝试，将它作为数据传输地址。后续开始建立连接，成功后就可以利用这个通道传输音视频数据了。

总结

• WebRTC的ICE会选择出最好的连接通道来传输音视频数据。
• WebRTC的连通率几乎是100%，因为即使无法完成P2P的连接，最终也能通过中继（relay）的方式来实现端到端的连接。
• 那么WebRTC具体是怎样利用ICE协议来实现P2P的NAT穿透的呢？请关注后续文章。