关于前端:WebRTC简介

70次阅读

共计 5214 个字符,预计需要花费 14 分钟才能阅读完成。

什么是 WebRTC

WebRTC 全称网页及时通信(Web Real-Time Communication),是一个反对网页浏览器进行实时音视频对话的 API,于 2011 年 6 月 1 日开源,并被纳入 W3C 规范。以被泛滥浏览器反对,如 Edge,Chrom,Firefox,Opera 等

WebRTC 整体示意图

WebRTC 次要用在音视频的实时通信上,上图是 WebRTC 1 对 1 音视频通信的示意图,通过这个示意图,咱们能够明确,应用 WebRTC 开发音视频的实时通信的整体构造包含:

  • WebRTC 终端,次要负责音视频的采集 / 展现,编 / 解码,NAT 穿梭和数据传输等
  • Signal 服务器,次要负责信令解决(退出房间 / 退出房间,以及媒体协商 SDP 等),能够应用 Websocket/Socket 等实现
  • STUN/TURN 服务器,次要负责获取 WebRTC 终端的公网 IP 地址或 NAT 穿梭失败的数据直达(若 NAT 穿梭胜利,则采纳 P2P 通信,反之,采纳直达服务器直达)

交互流程

WebRTC 端到端建设连贯,并进行音视频实时通信的大体过程如下

  1. WebRTC 两个客户端别离与 Signal 服务器建设连贯,Signal 服务端为 WebRTC 端调配房间 / 退出指定的房间,并返回 WebRTC 房间信息
  2. WebRTC 端会创立 RTCPeerConnection 媒体连贯,这个连贯须要晓得单方的流媒体数据格式能力进行后续的数据传输,它们通过 Signal 服务端进行 SDP 媒体协商

    1. WebRTC- 1 先创立 RTCPeerConnection 媒体连贯,并生成 Offer 申请(蕴含了它这个客户端反对的的媒体格式等内容),并将其设置到 RTCPeerConnectionLocalDescription,而后向 Signal 服务器发送 Offer 申请, 由其转发给 WebRTC- 2 端。
    2. WebRTC- 2 端收到了 Offer 申请,也会创立 RTCPeerConnection 媒体连贯,并将 Offer 申请中对端反对的 SDP 设置到 RTCPeerConnectionRemoteDescription, 同时生成 Answer 应答,并将其设置到 RTCPeerConnectionLocalDescription, 而后发送到 Signal 服务器,由其转发给 WebRTC-1
    3. WebRTC-1 收到 Answer,将 SDP 设置到 RTCPeerConnectionRemoteDescription,实现媒体协商
  3. WebRTC 两端都有了对端的连贯信息和媒体协商信息,就能够进行连贯,并通信

留神:WebRTC- 1 和 WebRTC- 2 建设连贯的形式有 P2P 和通过直达服务器直达两种形式,其中 SDP 中就包含对端的连贯信息,这个信息是在生成 SDP 时,会和 STUN/TURN 服务器进行通信,收集该 WebRTC 端的 ICE(蕴含如何与其建连的信息), 而后 WebRTC 客户端就能够通过对方的 ICE 进行连贯。

WebRTC 是如何建连

WebRTC 是反对浏览器之间建设连贯的连贯,然而浏览器所在主机之间的网络环境可能差别很大,有的主机在局域网内,有的在公网上,局域网和公网的主机通信须要通过 NAT,所以须要先理解有哪些类型的 NAT, 在看看 WebRTC 如何为不同网络环境的机器之间建设连贯

NAT 品种

齐全锥形 NAT

主机 host 通过 NAT 拜访外网 B, 在 NAT 上就会打个”洞“,所有晓得这个”洞“的外网主机都能够通过这个与 host 上的侦听程序通信。这个”洞“对应 NAT 映射:

内网 IP: 内网 Port<–> 外网 IP: 外网 Port

那么机器 A 或 C 就能够通过这个外网 IP: 外网 Port 和 host 上的过程通信了

IP 限度锥形 NAT

IP 限度锥型要比齐全锥型 NAT 严格得多,它次要的特点是,host 主机在 NAT 上“打洞”后,NAT 会对穿梭洞口的 IP 地址做限度。只有注销的 IP 地址才能够通过,也就是说,只有host 主机拜访过的外网主机能力穿梭 NAT

也就是 NAT 映射表为:

内网 IP: 内网 Port<–> 外网 IP: 外网 Port<–> 被拜访的主机 IP

那么这里只有 B 能够和 X 通信,而 A,C 因为 IP 未被拜访,故无奈与其通信

端口限度锥型

端口限度锥型要比 IP 限度形还要严格,它次要的特点是,host 主机在 NAT 上“打洞”后,NAT 会对穿梭洞口的 IP 地址和端口做限度。也就是说,只有host 主机拜访过的外网主机及提供服务的程序的端口能力穿梭 NAT

也就是 NAT 映射表为

内网 IP: 内网 Port<–> 外网 IP: 外网 Port<–> 被拜访的主机 IP:被拜访主机 Port

那么这里只有 B 上的 P1 端口的过程能力和其通信

对称型 NAT

这是 NAT 中最严格的一种类型,也就是说 host 主机拜访 A 时会打一个”洞“,拜访 B 是会再打一个”洞“,也即六元组中

内网 IP: 内网 Port<–> 外网 IP:外网 Port<–> 被拜访的主机 IP:被拜访主机 Port

不同的被拜访主机对应不同的 外网 Port

那么 host 主机怎么晓得本人的网络属于哪一种类型的?

咱们须要一台公网的服务器,且它领有两个网卡,那么咱们就能够通过如下步骤判断它的 NAT 环境

  1. 主机向服务器 #1 的一个网卡和端口发送申请, 服务器会用雷同的 IP 和端口发送响应
  2. 若主机收不到响应,阐明主机的网络限度了 UDP 协定,间接退出
  3. 如果能收到回包,且返回的主机的 IP 和主机本身的 IP 一样,阐明主机领有公网 IP, 如果不一样,则阐明主机处于 NAT 防护下
  4. 如果主机领有公网 IP, 须要判断它的防火墙类型,此时能够再向服务器 \#1 网卡和端口发送申请,而后服务器 \#1 另一个网卡网卡和端口进行回包
  5. 如果主机能收到,阐明它是没有防护的公网主机,反之,则收到对称型防火墙爱护

若第 3 步中判断主机在 NAT 防护下,须要判断它是在哪种类型的 NAT 环境,步骤如下

  1. 主机向服务器 #1 一个网卡和端口发送申请,服务器#1 用另一个网卡和不同端口回包
  2. 若主机收到音讯,阐明是齐全锥形 NAT
  3. 若收不到,向服务器 #2 一个网卡和端口发送申请,并用雷同的网卡和端口回包
  4. 主机收到音讯后比对服务器 #1 和#2 返回的主机的外网的 IP 和端口是否统一

    ,如果不统一,则是对称型 NAT(对称型 NAT 的特点就是与不同机器通信都会打不同的”洞“)

  5. 若放回的外网 IP 和端口一样(阐明应用的是同一个”洞“),这时候只须要判断是 IP 限度还是端口限度,能够向服务器 #1 的一个网卡和端口发送申请,并用雷同网卡的不同端口回包
  6. 若能收到就是 IP 限制型,收不到就是端口限制型

咱们晓得不同限制型的 NAT 限度的严格水平为

对称型 NAT> 端口限度 NAT >IP 限度 NAT > 齐全锥形 NAT

咱们上述办法先排除对称型和齐全锥形,在辨别是 IP 限度还是端口限度。

对称型 NAT 与对称型 NAT 之间以及对称型 NAT 与端口限制型 NAT 之间无奈打洞

WebRTC 如何建连

WebRTC 建连是比较复杂,它要思考端到端之间的连通性和数据传输的高效性,所以当有多条无效连贯时,须要抉择传输品质最好的线路,如能用内网连通就不必公网,如果公网也连通不了(比方单方都是处在对称型 NAT 下),那么就须要通过服务端中继的形式。

WebRTC 建连就是解决图中红色框的局部。

单方处于同一网段

  • 间接内网连贯
  • 通过公网绕一圈后再连贯

单方位于不同网段

  • P2P 的形式建设连贯(须要应用 NAT 打”洞“),优先应用
  • 通过中继服务器直达

ICE 候选者

ICE(Interactive Connectivity Establishment,ICE)候选者示意 WebRTC 与远端通信是应用的协定、IP、端口等,如

{
  IP: xxx.xxx.xxx.xxx,  // 本地 IP
  port: number, // 端口
  type: host/srflx/relay, // 类型,host 示意本机候选者,srflx 示意内网主机映射的外网的地址和端口,relay 示意中继候选者
  priority: number,  // 优先级
  protocol: UDP/TCP,
  usernameFragment: string
  ...
}

WebRTC 建设连贯是抉择的 ICE 优先级为 host> srflx > relay

那么 srflx(外网 IP)和 relay(中继 IP)是怎么获取?这就须要理解 STUNTURN协定

STUN 协定

通过上述 NAT 介绍,咱们晓得咱们能够向公网的服务器发送一个申请,而后服务器返回主机的外网 IP 和端口,这个就是 STUN 协定,恪守该协定就能拿到本人的公网 IP(在公网上部署 STUN 服务器,内网主机向其发送 binging request 即可取得本人的外网 IP 和端口)

TURN 协定

relay 型候选者的获取是通过也是 STUN 获取,只不过音讯类型不一样,次要应用 Allocation 指令。主机向 TURN 服务器发送 Allocation 指令,relay 服务器会子啊服务端调配新的端口,用于直达 UDP 数据报

SDP 简介

SDP简称 Session Description Protocal,用来形容各端反对的音视频编解码格局和连贯相干的信息。次要包含以下几个局部:

  • Session Metadata,会话元数据
  • Network Description,网络形容
  • Stream Description,流形容
  • Security Descriptions,平安形容
  • Qos Grouping Descriptions,服务质量形容

以下是会话形容和

//========== 以上示意会话形容 ==========
v=0    //protocol version
o=- 4007659306182774937 2 IN IP4 127.0.0.1     //username sessionID version networkType addressType IP
s=-           //sessionName
t=0 0   //session 的开始和完结工夫,0 0 示意长久会话

...
// 上面的媒体形容,在媒体形容局部包含音频和视频两路媒体
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126  
// 媒体类型 audio 端口 9 传输协定 流媒体格式
...
a=rtpmap:111 opus/48000/2 // 对 RTP 数据的形容
a=fmtp:111 minptime=10;useinbandfec=1 // 对格局参数的形容
...
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
...
// 下面是音频媒体形容,上面是视频媒体形容
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
...
a=rtpmap:96 VP8/90000
...


...
//======= 平安形容 ============
a=ice-ufrag:1uEe // 进入连通性检测的用户名
a=ice-pwd:RQe+y7SOLQJET+duNJ+Qbk7z// 明码,这两个是用于连通性检测的凭证
a=fingerprint:sha-256 35:6F:40:3D:F6:9B:BA:5B:F6:2A:7F:65:59:60:6D:6B:F9:C7:AE:46:44:B4:E4:73:F8:60:67:4D:58:E2:EB:9C //DTLS 指纹认证,以辨认是否是非法用户
...
//======== 服务质量形容 =========
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb // 应用 google 的带宽评估算法
a=rtcp-fb:96 transport-cc // 启动防拥塞
a=rtcp-fb:96 ccm fir // 解码出错,申请关键帧
a=rtcp-fb:96 nack    // 启用丢包重传性能
a=rtcp-fb:96 nack pli // 与 fir 相似
...

多人音视频通信的架构?

下面介绍的 1 对 1 的通信模型,若要实现多对多的通信,个别有三种计划

  1. Mesh 计划。各个终端两两之间建设连贯,造成网状。
  2. MCU(Multipoint Conferencing Unit)计划。服务端别离和各个客户端建设连贯,组成星形构造,所有终端发送的音视频须要咋服务器进行混合,之后再发送给客户端。
  3. SFU(Selective Forwarding Unit)计划。不同于 MCU, 这里不对音视频混合,仅仅转发给房间内的其余终端

[Mesh 架构]

[MCU 架构]

[SFU 架构]

长处 毛病
Mesh 简略,不须要直达数据,不须要开发媒体服务器 上行带宽压力大,资源耗费大,兼容各种客户端
MCU 技术成熟,客户体验号 服务端编解码和混流资源耗费大,提早高
SFU✅ 服务端资源耗费小,延时低,能适应不同终端类型 用户体验不好(音视频不同步),客户端应用简单(混流,渲染等)

参考文献

  • https://zh.wikipedia.org/wiki…
  • https://time.geekbang.org/col…

正文完
 0