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（候选者）的过程，也就是分为
- 在主机收集所有的host类型的Candidate
- 通过STUN协议获取srflx类型的Candidate
- 通过TURN协议获取relay类型的Candidate
3、通信时序图
3.1 媒体协商时序图
图3.1-1 媒体协商时序图
3.1.1 媒体协商
媒体协商主要用SDP（Session Description Protocal）以文本描述各端（PC 端、Mac 端、Android 端、iOS 端等）的能力， 这里的能力指的是各端所支持的，比如主要有以下内容
- 音视频编解码器是什么，这些编解码器设定的参数是什么，采用什么音视频编码格式
- 使用的传输协议是什么
3.1.2 涉及的通信协议
- Offer信令
- Answer信令
- Candidate信令
3.2 网络协商时序图
图3.2-1 网络协商时序图
3.2.1 网络协商说明
其实上面绘制的没有完全体现媒体协商与网络协商的同步进行，为了提高连接效率，媒体协商跟网络协商应该同步进行在CreatePeerConnection（设置STUN/TURN服务器地址）后进行CreateOffer，在收到webrtc回调Offer信息，webrtc也在进行网络协商，只要通过回调OnCandidate收到网络协商信息，就通过信令服务把Candidate信息发送到对端去。
3.2.2 涉及的通信协议
- Candidate信令
3.3 局域网内端对端通信时序图
图3.3-1 局域网内通信时序图
3.3.1 局域网内通信
如果两个端同在一个局域网内，可以进行直连的，webrtc中的ICE框架会判断两个端是否在同一局域网，然后进行局域网内的通信
3.3.2 涉及的协议
- Candidate信令
3.4 NAT场景P2P连接时序图
图3.4-1 P2P打洞时序图
3.4.1 NAT通信
这种属于两个端之间的P2P的直接连接，是要依靠NAT打洞（P2P穿越），需要借助STUN服务进行协调打洞的过程的，成功率的大小跟设备所处在的NAT类型（完全锥形、地址限制型、端口限制型、完全首先型）有很大的关系，当这种方式失败了，将采用下面的第3种方式，即通过Relay中转的方式进行通信
3.4.2 涉及的协议
- Candidate信令
3.5 通过Relay连接通信时序图
图3.5-1 通过Relay连接通信的时序图
3.5.1 通过Relay连接通信
当P2P穿越失败时候，采用这种中继的方式进行通信交换数据，端侧会向TURN服务器发送，Allocation 指令。通过向 TURN 服务器发送 Allocation 指令，Relay服务就会在服务器端分配一个新的 relay 端口，用 于中转 UDP 数据报.
3.5.2 涉及的协议
- Candidate信令
4、浏览器通信例子
图4-1 浏览器端接入WebRTC的示例图
拿浏览器接入WebRTC来预览设备端视频的例子
- 先http请求从地址服务器上获取信令服务器的地址，STUN/TURN服务器的地址
- 与信令服务器建立WebSocket连接
- 传入STUN/TURN服务器的配置，创建RTCPeerConection（浏览器WebRTC核心类）
- 调用浏览器RTCPeerConection类的接口createOffer
- RTCPeerConection类回调onOffer
- 调用浏览器RTCPeerConection类的接口，setLocalDescriptions
- 从onOffer得到回调的SDP信息转为信令发送到信令服务器
- 浏览器收到Answer，调用浏览器类型RTCPeerConnection类的接口，setRemoteDescription
- RTCPeerConection类回调OnCandidate
- 通过信令服务器发送candidate到对端
- 收到信令服务器发过来的candidate,调用浏览器类型RTCPeerConnection类的接口，addIceCandidate
- 连接成功后收到RTCPeerConection类的onTrack收到流信息
- h5的video标签 设置onTrack返回的流进行播放