WebRTC | ICE详解

目录

一、Candidate种类与优先级

二、ICE策略

[1. iceServers](#1. iceServers)

[2. iceTransportPolicy](#2. iceTransportPolicy)

三、P2P连接

1.Nat类型

(1)完全锥型NAT

(2)IP限制锥型NAT

(3)端口限制锥型NAT

(4)对称型NAT

四、网络中继

[1. TURN协议中转数据](#1. TURN协议中转数据)

[(1)发送指令Send indication](#(1)发送指令Send indication)

(2)端对端传输数据


一、Candidate种类与优先级

ICE中使用的Candidate具有优先级次序,由高到低分别为host、srflx、prflx、relay。WebRTC进行一对一音视频通信时,就是按照这个次序尝试建立连接的。

不在同一局域网内,双方尝试host型Candidate连接时会失败。不过,在双方尝试连接时,双方Candidate的收集工作并未停止。Candidate收集线程还在收集其他类型的Candidate,如从STUN/TURN服务器收集srflx和relay类型的Candidate;当收集到srflx类型的Candidate时,ICE会尝试NAT打洞,如果打洞成功,则双方会通过P2P的方式传输数据;如果打洞失败,则会通过TURN服务器中转数据。

WebRTC通信时会按照内网、P2P、relay这样的次序尝试连接:

  1. 内网连接对应host连接策略。host连接表示直接在本地设备上建立的连接,也就是在同一局域网内的设备之间的直接连接。

  2. P2P连接对应srflx和prflx连接策略。srflx(server reflexive)和prflx(peer reflexive)连接都是通过STUN服务器获取的公共IP地址,用于建立点对点连接。srflx连接是通过NAT后的公共IP地址建立的连接,而prflx连接是对等方自己的NAT映射地址。

  3. 中继连接对应relay连接策略。当无法建立直接的P2P连接时,WebRTC会使用TURN服务器作为中继,建立relay连接。relay连接通过中继服务器传递数据,确保数据的可靠传输。

WebRTC中的ICE既考虑了数据传输的效率,又考虑了网络的连通率:

  • WebRTC的ICE机制会选择最好的链路传输音视频数据,即如果通信的双方在同一网段内,则优先使用内网链路;如果通信的双方不在同一网段,则优先使用P2P;当以上方式都无法连通时,则使用relay服务进行中转。
  • ICE的连通率几乎可以达到100%。在内网和P2P无法连通的情况下,它还可以通用中继的方式让彼此连通,从而大大提高了WebRTC的连通率。

二、ICE策略

RTCPeerConnection提供了一种在浏览器之间建立点对点连接的方式,而无需通过服务器进行中转。它使用了ICE(Interactive Connectivity Establishment)协议来处理网络地址和端口的自动配置,以确保连接的稳定性和可靠性。

构造RTCPeerConnection对象时,其输入参数的类型为RTCConfiguration。

cpp 复制代码
RTCConfiguration pcConfig = {
   'iceServers': [{
      'urls': 'turn:stun.learningrtc.cn:3478',
      'username': "username1",
      'credential': "password1",
   },{
      'urls': 'turn:stun.avdancedu.com:3478',
      'username': "username2",
      'credential': "password2",
   }],
   'iceTransportPolicy': "all",
   'bundlePolicy': "max-bundle",
   'rtcpMuxPolicy': "require"
};
RTCPeerConnection pc = new RTCPeerConnection(pcConfig);
...

RTCConfiguration各字段含义

1. iceServers

iceServers是RTCIceServer类型的数组,可以包含一个或多个STUN和/或TURN服务器。

2. iceTransportPolicy

在ICE中,有两种常见的网络连接策略:

  • all:默认策略,浏览器将尝试使用所有可用的网络接口(如本地IP地址、VPN、Wi-Fi等)来建立连接。这种策略适用于多种网络环境,但可能会增加连接建立的时间和网络带宽的消耗。
  • relay:这种策略仅使用中继服务器(如TURN服务器)来建立连接。中继服务器充当中间人,帮助两个浏览器在防火墙或NAT后面建立连接。这种策略适用于网络环境受限的情况,但可能会增加延迟和中继服务器的负载。

三、P2P连接

1.Nat类型

P2P指的就是如何进行NAT穿越。NAT在真实的网络环境中随处可见,它的出现主要出于两个目的。一是为了解决IPv4地址不够用的问题。当时IPv6短期内还无法替换IPv4,而IPv4的地址又特别紧缺,所以人们想到让多台主机共用一个公网IP地址,大大减缓了IPv4地址不够用的问题。二是为了解决安全问题。使用NAT后,主机隐藏在内网,这样黑客就很难访问到内网主机,从而达到保护内网主机的目的。

NAT就是一种地址映射技术,它在内网地址与外网地址之间建立了映射关系。当内网主机向外网主机发送信息时,数据在经过NAT层时,NAT会将数据包头中的源IP地址和源端口号替换为映射后的外网IP地址和外网端口。相反,当接收数据时,NAT收到数据后会将目标地址映射为内网的IP地址和端口再转给内网主机。

RFC3489和RFC5389是最重要的两份NAT穿越的协议文档。在RFC3489协议中,将NAT分成4种类型,即完全锥型、IP限制锥型、端口限制锥型以及对称型。在这4种类型中,越往后的NAT类型穿越难度越大。

大多数情况下NAT穿越使用的是UDP,这是因为UDP是无连接协议的,打洞会更加方便。当然,也可以使用TCP打洞。

(1)完全锥型NAT

完全锥型NAT的特点:一旦打洞成功,所有知道该洞的主机都可以通过它与内网主机进行通信。

(2)IP限制锥型NAT

IP限制锥型NAT要比完全锥型NAT严格得多。IP限制锥型NAT的主要特点:NAT打洞成功后,只有与之打洞成功的外网主机才能通过该洞与内网主机通信,而其他外网主机即使知道洞口也不能与之通信。

(3)端口限制锥型NAT

端口限制锥型NAT的主要特点:除了像IP限制锥型NAT一样需要对IP地址进行检测外,还需要对端口进行检测。

(4)对称型NAT

对称型NAT是4种NAT类型中对数据包检测最严格的。对称型NAT的特点:内网主机每次访问不同的外网主机时,都会生成一个新洞,而不像前面3种NAT类型使用的是同一个洞。

对称型NAT每次访问不同外网主机都生成新洞的这种特性,导致对称型NAT碰到对称型NAT或者对称型NAT遇到端口限制型NAT时,双方打洞的成功率非常低,即使可以互通,成本也非常高。WebRTC遇到上面这两种情况时,直接放弃打洞的尝试。

四、网络中继

当遇到NAT之间无法打通的情况时,WebRTC会使用TURN协议通过中转的方式实现端与端之间的通信。

1. TURN协议中转数据

TURN协议采用了典型的客户端/服务器模式,其服务器端称为TurnServer,客户端称为TurnClient。TurnClient与TurnServer之间通过信令控制数据流的发送。

TurnClient与TurnServer之间的传输协议既可以是UDP,也可以是TCP,而在TurnServer上分配的relay地址使用的都是UDP。

(1)发送指令Send indication

该指令包括两个属性:XOR-PEER-ADDRESS和DATA。其中XOR-PEER-ADDRESS属性用于指定向哪个主机转发数据,DATA属性指明数据的具体内容。

(2)端对端传输数据

一种方法就是上面说的Send indication指令,当TurnClient向某个Peer发数据时就要使用它。相反,当Peer通过TurnServer向TurnClient转发数据时,使用Data indication指令,指明向哪个TurnClient转发数据。

另一种方法是使用tunnel机制。使用tunnel机制的好处是不用再像使用Send/Data indication指令一样,每次都要指定数据发往的地址,只需要在开始发送数据之前,发送ChannelBind指令将channel number与目标地址绑定一次即可,后面统一使用channel number就可以找到发往的目的地。

相关推荐
肖爱Kun1 小时前
Webrtc本端发candidate给对端
webrtc
肖爱Kun4 小时前
Webrtc本端和对端信令交互步骤
服务器·webrtc
肖爱Kun1 天前
Webrtc信令交互
服务器·webrtc
Fisher3Star3 天前
WebRTC Transport 两种创建方式的差异解析
webrtc
Fisher3Star3 天前
FFmpeg推流至Mediasoup全流程指南
webrtc
Fisher3Star3 天前
mediasoup 创建Router全流程详解
webrtc
声网3 天前
OpenAI 的 WebRTC 秘密架构:没有 SFU?没有问题!丨 Voice Agent 学习笔记
学习·架构·webrtc
HySpark7 天前
VAD 与流式 ASR 踩坑复盘及完整解决方案
webrtc·vad·离线语音转写·流式asr·qwen-asr·音频预处理
徐子元竟然被占了!!7 天前
WebRTC协议
webrtc
ZC跨境爬虫7 天前
跟着 MDN 学 HTML day_28:(使用选择器 API 在 DOM 树中进行选择与遍历)
前端·ui·html·音视频·webrtc