WebRTC通信原理与流程

1、服务器与协议相关

1.1 STUN服务器

图1.1.1 STUN服务器在通信中的位置图

1.1.1 STUN服务简介

STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT（或多重 NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的 Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间通信。该协议由RFC 5389定义。

1.1.2 STUN服务的作用

主要是给无法在公网环境下进行通话的设备，分配公网IP用的，其实简单的说来就是告诉客户端的公网IP地址+端口。因为在NAT之后的设备自己是无法知道自己公网的IP和端口的，还有另外一个作用就是找出主机所在NAT的类型，主要会判断出主机所处网络所在是处于完全锥型、地址受限型、端口受限型，NAT对称型，从而找到更合适的通信方案。

1.2 TURN服务器

图1.2-1 TURN服务器在通信中的位置图

1.2.1 TURN服务器简介

TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果 终端在NAT之后， 那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网 的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。

1.2.2 TURN服务器的作用

当无法建立P2P连接时候，那么就通过TURN服务器来转发媒体数据

1.3 信令服务器

图1.3-1 P2P信令服务器在通信中的位置图

1.3.1 信令服务器简介

作为端对端通信的桥梁，为P2P建立连接，媒体协商，网络协商提供服务，搭在公网上，让局域网内的设备都能访问到，进行通信的交互

1.3.2 信令服务器作用

设备之间的媒体协商(SDP)，设备之间的网络协商(Candidate)提供信令交互的通道

1.4 服务器间主要的交互流程图

图1.4-1 端与端，端与服务器间的交互流程

2、ICE Candidate（ICE候选者）

2.1 简介

表示 WebRTC 与远端通信时使用的协议、IP 地址和端口，通常包含以下字段

本地IP地址、本地端口号、候选者类型、优先级、传输协议、访问服务的用户名

2.2 候选者的优先级情况

host（本机候选者）

srflx（内网主机映射的外网地址和端口）

prflx(对等反射候选者)

relay（中继候选者）

host类型是最高优先级的，在WebRTC中，首先对host类型的候选者进行连通性检查，如果他们能够互通，则直接建立连接，其实host类型之间的联通性检测就是内网间的连通性检测

如果host类型无法连接，尝试次优先级的候选者即是srflx类型候选者，然后是prflx

上面3种都不行，那么就会尝试使用relay方式建立连接

优先级: host > srflx > prflx > relay

2.3 收集Candidate

host类型： 即本机内网的IP和端口

srflx类型：即本机NAT映射后的外网的IP和端口

prflx类型：对等反射候选者，通过对端数据包头或者到对端的的地址获取

relay类型： 即中继服务器的IP和端口

2.4 STUN协议

srflx类型的Candidate是通过STURN协议进行收集的，简单来说就是内网主机通过发送STUN消息binding request到STUN服务器，服务器收到请求后，会将请求的IP地址和端口填充到binding response消息中，然后返回给内网主机，内网主机就可以知道自己外网IP和端口。也需要通过STUN协议判断当前网络所处的NAT类型，比如是完全锥形，还是端口限制型，还是地址受限类型，还是对称NAT类型

2.5 TURN协议

也是用STUN协议，只不过协议的类型不一样，比如获取中继的Candidate，会向TURN发送Alllcation指令，relay服务就会在服务端分配一个relay端口，用于中转数据，然后把地址和端口返回给客户端

2.6 ICE

其实ICE就是上面说的获取各种类型的Candidate（候选者）的过程，也就是分为

1. 在主机收集所有的host类型的Candidate
2. 通过STUN协议获取srflx类型的Candidate
3. 通过TURN协议获取relay类型的Candidate

3、通信时序图

3.1 媒体协商时序图

图3.1-1 媒体协商时序图

3.1.1 媒体协商

媒体协商主要用SDP（Session Description Protocal）以文本描述各端（PC 端、Mac 端、Android 端、iOS 端等）的能力， 这里的能力指的是各端所支持的，比如主要有以下内容

1. 音视频编解码器是什么，这些编解码器设定的参数是什么，采用什么音视频编码格式
2. 使用的传输协议是什么

3.1.2 涉及的通信协议

1. Offer信令
2. Answer信令
3. Candidate信令

3.2 网络协商时序图

图3.2-1 网络协商时序图

3.2.1 网络协商说明

其实上面绘制的没有完全体现媒体协商与网络协商的同步进行，为了提高连接效率，媒体协商跟网络协商应该同步进行在CreatePeerConnection（设置STUN/TURN服务器地址）后进行CreateOffer，在收到webrtc回调Offer信息，webrtc也在进行网络协商，只要通过回调OnCandidate收到网络协商信息，就通过信令服务把Candidate信息发送到对端去。

3.2.2 涉及的通信协议

1. Candidate信令

3.3 局域网内端对端通信时序图

图3.3-1 局域网内通信时序图

3.3.1 局域网内通信

如果两个端同在一个局域网内，可以进行直连的，webrtc中的ICE框架会判断两个端是否在同一局域网，然后进行局域网内的通信

3.3.2 涉及的协议

1. Candidate信令

3.4 NAT场景P2P连接时序图

图3.4-1 P2P打洞时序图

3.4.1 NAT通信

这种属于两个端之间的P2P的直接连接，是要依靠NAT打洞（P2P穿越），需要借助STUN服务进行协调打洞的过程的，成功率的大小跟设备所处在的NAT类型（完全锥形、地址限制型、端口限制型、完全首先型）有很大的关系，当这种方式失败了，将采用下面的第3种方式，即通过Relay中转的方式进行通信

3.4.2 涉及的协议

1. Candidate信令

3.5 通过Relay连接通信时序图

图3.5-1 通过Relay连接通信的时序图

3.5.1 通过Relay连接通信

当P2P穿越失败时候，采用这种中继的方式进行通信交换数据，端侧会向TURN服务器发送，Allocation 指令。通过向 TURN 服务器发送 Allocation 指令，Relay服务就会在服务器端分配一个新的 relay 端口，用 于中转 UDP 数据报.

3.5.2 涉及的协议

1. Candidate信令

4、浏览器通信例子

图4-1 浏览器端接入WebRTC的示例图

拿浏览器接入WebRTC来预览设备端视频的例子

1. 先http请求从地址服务器上获取信令服务器的地址，STUN/TURN服务器的地址
2. 与信令服务器建立WebSocket连接
3. 传入STUN/TURN服务器的配置，创建RTCPeerConection（浏览器WebRTC核心类）
4. 调用浏览器RTCPeerConection类的接口createOffer
5. RTCPeerConection类回调onOffer
6. 调用浏览器RTCPeerConection类的接口，setLocalDescriptions
7. 从onOffer得到回调的SDP信息转为信令发送到信令服务器
8. 浏览器收到Answer，调用浏览器类型RTCPeerConnection类的接口，setRemoteDescription
9. RTCPeerConection类回调OnCandidate
10. 通过信令服务器发送candidate到对端
11. 收到信令服务器发过来的candidate,调用浏览器类型RTCPeerConnection类的接口，addIceCandidate
12. 连接成功后收到RTCPeerConection类的onTrack收到流信息
13. h5的video标签 设置onTrack返回的流进行播放