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穿透的呢?请关注后续文章。

你可能感兴趣的:(webrtc音视频ice)