webrtc-candidate形成分析

webrtc-candidate形成分析

背景

由于NAT的限制,NAT后的设备无法直接P2P通信,出现了ICE(Interactive Connectivity Establishment)技术来进行通信。WebRTC就使用了ICE技术进行通信。

ICE过程会在通信的两端形成各自的Candidate,每个Candidate代表了一个候选的通信端点。两端各自创建通信端口,通常每个网卡对创建一个UDP通信端口,每个网卡针对每个TURN服务器创建一个TURN通信端口,在端口上收集对应类型Candidate,通信的两端通过信令交换各自的Candidate,然后用本端的的每个通信端口的Candidate和对方的每个Candidate进行两两配对尝试通信(注意通信端口并不等价于Candidate,一个UDP通信端口上可能会有多个Candidate,UDP端口用host类型的Candidate用于配对),最终挑选一对可用的Candidate用于传输数据。每两个Candidate配对会形成一条传输通道,这个传输通道webrtc的代码中叫做Connection,在webrtc-internals调试界面中叫做Candidate-Pair。通信端自己的这方的Candidate叫做Local-Candidate,对方的Candidate叫做Remote-Candidate。当然在对端的视角就是反过来。

由于ICE中大部分情况都是使用UDP协议,所以本文仅讨论UDP协议通信

Candidate形成

Candidate在形成的过程中根据网络情况会形成4种Candidate:

host(Host Candidate)

host类型的Candidate就是本机地址,即网卡绑定的地址,所以每个端一定会有自己的host类型Candidate,如果有多个网卡,那么就会形成多个host类型Candidate

host类型的Candidate代表的是未经NAT转换的原始地址,所以这种类型的Candidate通常只在局域网内才会联通(不排除一些特殊网络情况)。

srflx(Sever Reflexive Candidate)

srflx类型Candidate就是本机的NAT映射地址,本机发送UDP数据经过NAT的转换后,会被NAT映射一个NAT外的地址,本端通过使用STUN协议和STUN服务器通信,STUN服务器通过查看STUN协议请求包的来源地址来获取这个地址并通过STUN将此地址添加在XOR_MAPPED_ADDRESS属性中回复给来源端。因为通常本机的不同网卡会被映射为不同的地址,所以如果有多个网卡,也会形成多个srflx类型Candidate

srflx类型Candidate地址不会用做Local-Candidate配对,只会发往对端口,对端用来作为Remote-Candidate进行配对尝试,因为这个地址本就是NAT外部看到的地址,只有对NAT外部的端才有意义,本机处于NAT内部,使用此地址无实际的意义。

但是有时会看到Local-Candidate的类型是srflx,这种情况是在配对的过程中本端向某一个Remote-Candidate发送STUN请求后收到了对端的STUN回复,STUN回复中会使用STUN协议的XOR_MAPPED_ADDRESS属性标明对端之前收到的STUN请求的来源地址,如果本端发现STUN回复中的XOR_MAPPED_ADDRESS属性值和本端之前收集的某一个Local-Candidate一致,那么说明对端是通过本端在NAT映射后的地址(既srflx类型Candidate的地址)通信的,这种情况将这个配对的Local-Candidate更新为匹配到的srflx类型Candidate

prflx(Peer Reflexive Candidate)

prflx类型Candidate是一种比较特殊的Candidate,它的特殊之处在于它不是主动收集而来,而是直接用户填写或者在配对尝试过程中形成的。prflx类型Candidatesrflx类型Candidate有些类似,它也是经过NAT映射之后的地址,区别在于,它并不是通过STUN服务器提前收集得到的,而是直接收到的数据包中。

从webrtc的源码分析可知,有3中情况会形成prflx类型Candidate

  • webrtc开始通信后,本端开始自动收集Candidate,然后将收集到的Candidate发送到对端作为Remote-Candidate,同样对端也会把收集到的Candidate发过来,作为Remote-Candidate,如果提前能够确定在当前网络中对端有一个可用的映射地址可用,那么此时可以手动构造一个Remote-Candidate,加入本端webrtc连接的Remote-Candidate列表。当然这中情况非常罕见,只有及其特殊的网络情况才适用。

  • 当配对的过程中本端向某一个Remote-Candidate发送STUN请求后收到了对端的STUN回复,STUN回复中会使用STUN协议的XOR_MAPPED_ADDRESS属性标明对端之前收到的STUN请求的来源地址,如果本端发现STUN回复中的XOR_MAPPED_ADDRESS属性值没有和当前接收数据的端口已经收集到的任何Local-Candidate地址相符,那么就认为出现了一个prflx类型Local-Candidate,其地址为XOR_MAPPED_ADDRESS属性的值。因为XOR_MAPPED_ADDRESS属性标明对端之前收到的STUN请求的来源地址,也就是说对端之前收到了这个地址发送的STUN请求,那么说明本端发送的数据被映射到了从这个地址发出,但这个地址并不是之前通过STUN服务器探测到的NAT映射地址,这可能是NAT将目的地不同的请求映射为不同的地址(对称性NAT)。

  • 当收到未知来源(即UDP包来源地址不匹配任何Remote-Candidate或可能得服务器地址)的STUN请求,那么就认为出现了一个prflx类型Remote-Candidate。这可能是对端NAT将目的地不同的请求映射为不同的地址(对称性NAT)。这个新的prflx类型Remote-Candidate仅可以用于和收到此请求的端口的Local-Candidate用于配对。

relay(Relayed Candidate)

relay类型Candidate是转发类型的Candidate,所有的数据都先发送到TURN服务器,再由服务器进行转发发送和接收到时如此。相当于TURN服务器成为了一个代理。

当Webrtc创建连接时传入了TURN服务器的信息,那么每个网卡针对每个TURN都会认证后分配一个中继地址,这个中继地址就是一个relay类型Candidate,当使用relay类型Candidate作为Local-Candidate时,将数据发送给TURN服务器,TURN服务器使用中继地址转发至目的地,当使用relay类型Candidate作为Remote-Candidate时,将要发往对端的将数据发往中继地址,TURN服务器由中继地址接收数据转发给对端。

相关推荐
EasyCVR4 天前
多品牌摄像机视频平台EasyCVR视频融合平台+应急布控球:打造城市安全监控新体系
大数据·网络·人工智能·音视频·webrtc
安步当歌7 天前
【WebRTC】视频发送链路中类的简单分析(上)
音视频·webrtc·视频编解码·video-codec
MetaverseMan8 天前
WebRTC 和 WebSocket
websocket·网络协议·webrtc
Mao.O8 天前
WebRTC实现双端音视频聊天(Vue3 + SpringBoot)
音视频·webrtc
红米饭配南瓜汤9 天前
WebRTC视频 03 - 视频采集类 VideoCaptureDS 上篇
音视频·webrtc·媒体
红米饭配南瓜汤10 天前
WebRTC视频 05 - 视频采集类 VideoCaptureDS 下篇
音视频·webrtc·媒体
安步当歌10 天前
【WebRTC】视频发送链路中类的简单分析(下)
网络·音视频·webrtc·视频编解码·video-codec
从后端到QT10 天前
WebRTC API分析
webrtc
红米饭配南瓜汤10 天前
WebRTC视频 04 - 视频采集类 VideoCaptureDS 中篇
音视频·webrtc·媒体
红米饭配南瓜汤11 天前
WebRTC视频 02 - 视频采集类 VideoCaptureModule
音视频·webrtc·媒体