---

一、webRTC介绍

未来应用趋势，向web浏览器发展

ffmpeg与webRTC区别：
ffmpeg用于处理多媒体文件的编辑，音视频的编解码
webRTC用于处理多网络抖动，丢包评估，回音消除，降噪

webRTC可以跨平台

二、webRTC原理与架构

绿色为webRTC核心功能，紫色部分为浏览器提供的js的api层，即浏览器对C++ API做了一层封装

绿色部分，核心层，分为四层：
C++层，PeerConnection对等连接，其中包含很多API：传输质量，传输数据，传输统计报告，音视频设备管理，采集，等
session层，上下文管理
音视频引擎和传输（音频：编码器/防抖动/回音消除和降噪，视频：编码器/防抖动buffer/图像增强，传输：底层UDP，应用层RTP/SRTP/RTCP）
音频的采集和渲染，视频的采集（没有视频渲染，需要浏览器应用层自己做）【虚线部分允许浏览器自己进行重载】

三、webRTC源码目录结构

四、webRTC信令服务器

1.原理

每个公司的业务模型不一样，因此没有统一规范
信令服务器的作用：

信令服务器要传输的信息：
1.SDP
2.网络信息，用于建立p2p
3.具体的业务信息

2.信令服务器实现

建议使用socket.io

为什么使用socket.io
1、socket.io时WebSocket的超集，本身就支持WebSocket的功能
2、信令服务器需要基于TCP协议，因为需要保证可靠性，而WebSocket底层使用的就是TCP协议
3、socket.io本身就带有房间的概念
4、socket.io是跨平台、跨终端、跨语言的，开发方便

五、webRTC传输基本知识

1、NAT（Network Address Translator）
将内网地址转换为公网地址，内网地址无法通讯，通过NAT转换为公网之后，才有通信的可能
2、STUN（Simple Traversal of UDP Through NAT）
充当中介作用，交换两个公网的信息，使得两个公网之间可以建立连接
3、TURN（Traversal Using Relays around NAT）
在云端架设一个服务器，在P2P连接不成功情况下，保证音视频互通
4、ICE（Interactive Connectivity Establishment）
罗列所有通信可能性(STUN、TURN)，选择最优解

1.NAT

NAT网络原理图：

NAT种类（1到4越来越严格）：
1、完全锥型（Full Cone NAT）
对响应没有限制，外网的任何ip都可以与内网ip访问

2、地址限制锥型（Address Restricted NAT）
只接收有发送过请求的ip地址相关的响应

3、端口限制锥型（Port Restricted NAT）
地址限制型基础上，再加上对端口的限制

4、对称型（Symmetric NAT）
同一主机向不同主机发送请求时，通过NAT映射的外网ip地址和端口不同

**如何判断当前stun服务的NAT类型：**客户端发送一个ECHO请求到stun服务端，服务端通过同样的ip和端口，返回消息回来，客户端如果未接收到，说明udp不通，如果收到响应判断公网ip地址与本机ip是否一致

2.STUN协议

2.1 STUN协议概述

STUN存在的目的就是进行NAT穿越
STUN是典型的客户端/服务器模式，客户端发送请求，服务端进行响应
它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。

2.2 RFC STUN规范

RFC3489/STUN：Simple Traversal of UDP Through NAT

    ① 定义：为简单的通过UDP进行NAT穿越的规范
    ② 存在问题：
        - 网络路由器对UDP的限制比较多，有的路由器是不允许进行UDP传输的，导致在使用RFC3489规范在进行NAT穿越的时候，失败率很高

RFC5389/STUN：Session Traversal Utilities for NAT

    ① 定义：一系列穿越NAT的工具
    ② 特性：
            - 通过UDP和TCP两种协议进行NAT穿越

2.3 STUN协议

消息头结构：
① 总共20字节
② 组成：
（1）协议3489
- 2字节（16bit）的消息类型
- 2字节（16bit）的消息长度：注意，消息长度不包括20字节消息头本身
- 16字节（128bit）的事物ID，请求与响应的事物ID相同，用于请求于响应的匹配
（2）协议5389：格式如下图所示

- 2字节（16bit）的消息类型：
· 消息类型的最低两位必须是00，用来区分复用同一个端口时哪一个时STUN协议(与老版本协议做区分)
· C0和C1用来分类（0b00-请求/0b01-指示/0b10-成功响应/0b11-失败响应）
· 剩下的12位用于定义请求/指示，如下图

- 2字节（16bit）的消息长度：注意，消息长度不包括20字节消息头本身
- 4字节（32bit）的魔法值
- 12字节（96bit）的事物ID，请求与响应的事物ID相同，用于请求于响应的匹配
消息类型
只有六种，分两种方法（最低4bit）：1表示绑定，2表示私密（5389将私密删除了）

事务ID
如果不是下述的固定值，说明不是rfc5389而是3489

消息体结构
消息体数据需要为32bit对齐，如果不是对齐需要补0对齐


不同消息类型下，对应属性的实现要求如下图（N/A表示不支持，O表示可选，M表示必选）

大小端模式

大端模式：数据的高字节保存在内存的低地址中
小端模式：数据的高字节保存在内存的高地址中
网络字节顺序：采用大端排序方式

2.3 STUN协议操作流程概述

如图为典型的stun配置，stun客户端连接到私有网络NET1，通过NAT1连接到私有网络NET2，NET2通过NAT2连接公网，stun服务器部署在公网。
   stun是一个简单的客户端-服务端模型的协议，客户端发送请求至服务端，然后服务端返回响应。有两种类型的请求——一种是Binding Request，通过UDP传输；一种是Shared Secret Request，通过基于TCP的TLS传输。Shared Secret Request要求服务器返回一个临时的username和pazuissword，这个username和password用于后续的Binding Request和Binding Response，保证身份认证和消息完整。Binding Request用于确定nat分配的绑定，客户端通过udp发送Binding Request到服务器，服务器获取到发送源的ip地址和端口，并将其复制到Binding Response中发送回客户端。在Binding Request消息中有一些参数设置使得客户端可以要求服务器在其他地方，或者用不同的ip和端口发送Binding Response。有一些属性用于提供消息完整性和身份验证。
   这些方法就是使用stun来发现NAT的类型以及学习使用Binding。STUN客户端通常嵌入到一个应用程序中，该应用程序需要获得一个公共IP地址和端口，可以用来接收数据，如：应用想通过公共ip和端口获取RTP数据，当应用启动时，内置stun客户端发送一个Shared Secret Request到服务器来获取username和passeword，然后发送Binding Request。通过DNS SRV记录可以发现STUN服务器，一般假设客户端已配置了用于查找STUN服务器的域。通常，这将是应用程序正在使用的服务的提供者的域(这样的提供者被鼓励部署STUN服务器，以便允许其客户通过NAT使用其应用程序)。当然，客户端也可以通过其他方式确定STUN服务器的地址或域名。STUN服务器甚至可以嵌入到终端系统中。
   Binding Request用于发现NAT的存在，以及发现由NAT映射后的公网ip地址和端口。Binding Request通过UDP协议发送到服务器端，在stun客户端和服务器端之间，Binding Request可能会通过一层或多层NAT。最终的结果是，服务器接收到的请求消息的源IP地址和端口，是最靠近stun服务器的那一层NAT映射后的公网地址。服务器将映射后的IP地址和端口复制并填写到Binding Response消息中发送给客户端。
   当客户端接收到Binding Response后，将解析出来的IP地址和端口与本地IP地址和端口进行比较，如果不匹配，则表明stun客户端处于一层或多层NAT之后。此时只是表明stun客户端处于NAT之后，还无法判断NAT的类型，为了进一步决定NAT的类型，客户端会发送第二个Binding Request，这一次是往不同的ip地址发送，如果Binding Response中的IP地址和端口和第一次的Binding Response的IP地址和端口不一样，那么stun客户端处于对称型锥的NAT之后，为了判断是否是完全型锥的NAT，客户端可以发送一个Binding Request并要求服务端用一个不同的IP和端口发送Binding Response，换句话说，如果客户但使用IP为X端口为Y向IP为A端口为B的主机发送请求，stun服务器使用IP为C端口为D向客户端发送回应，如果客户端能收到回应则表明其处于完全型锥。客户端也可以要求服务器使用相同的IP地址但端口不同来发送回应，以此来判断是处于端口限制型锥还是限制型锥。

2.TURN协议

2.1 TURN介绍

通常stun和turn是放在一起使用的

2.2 TURN原理简介

TURN服务是建立在STUN之上的，消息格式使用STUN的消息格式

TURN协议相当于在服务端架设的一个TURN服务，相当于一个中介，客户端在无法NAT穿越的时候，首先将媒体数据首先传递给TURN服务，通过TURN服务转发给其他的接收者

TURN分为Client端和Server端

TURN Client 会向 TURN Server 发送一个请求，TRUN Server收到请求后，会根据该请求建立一个公共的IP地址和端口Port，用于接收和发送数据

TURN实例如图（50000端口与3478端口形成通道）

2.3 TURN传输层协议

① TURN Client 向 TURN Server 发送数据：UDP、TCP、TLS over TCP（加密后的TCP）
② TURN Server 向 peer 发送数据：UDP

2.4 client与server建立链接并保活

① TURN Client 向 TURN Server 发送 Allocate 请求
② TURN Server 对 TURN Client发送过来的请求做鉴权处理
③ 如果请求没有响应的权限，返回401，标识未授权
④ TURN Client 收到 TURN Server发送的未授权响应后，会重新向 TURN Server发送请求信息，本次请求信息中包括鉴权信息
⑤ TURN Server 对 TURN Client 响应成功应答
⑥ TURN Client 会向 TURN Server 定时发送 Refresh 请求，为了保活

allocate建立连接，refresh request是用来保活的心跳

2.5 TURN发送机制

Send 和 Data，步骤如图所示
send表示上行，data表示下行，当数据转发到peer时，需要去掉turn头（30字节头），仅传输udp数据

采用通道机制传输：
Channel（创建一个channelID，与peerA绑定，在管道内发送数据，无需携带turn头），步骤如图所示：
send与channel可以并存

2.5 TURN在webRTC的使用

五、ICE框架

1.ICE介绍

ICE全称Interactive Connectivity Establishment，即交互式连通建立方式，它是根据RFC5245实现，是一组基于Offer/Answer模式解决NAT穿越打洞的协议集合

2.ICE作用

1.让左侧peer获取到所有能够连接到右侧peer的通路
通路1：局域网内本机的IP地址。通路2：通过nat打洞。通路3：通过relay中转。
2.双方将所有通路收集后，传给对方
3.对三种通路进行尝试

3.ICE候选者

每个 Candidate 是一个地址，例如： a = candidate:…UDP…192.169.1.2 18106 typ host
每个 Candidate 包括：协议、IP、端口和类型Candidate类型，通过信令中的SDP发送给对方：
类型包括三种
① 主机候选者：网卡自己的 IP 地址
② 反射候选者：经过 NAT 之后的 IP 地址
③ 中继候选者：通过 TURN 服务开通的 IP 地址和端口

4.ICE做了什么

1.收集 Candidate、
① 主机候选者（Host Candidate）：获取本机所有 IP 和指定端口
② 映射候选者（Reflexive Candidate）：使用 STUN 或 TURN 发起请求的时候，获取到的映射后的 ip 和端口、
③ 中继候选者（Relay Candidate）：通过 TURN 服务，发送 accolate 请求申请的 IP 地址和端口

2.对 Candidate Pair 排序
① 一方收集到所有候选者后，通过信令传给对方
② 同样，另一方收到候选者后，也做收集工作
③ 当双方拿到全部列表后，将候选者形成匹配对

3.连通性检查
① 对后选对进行优先级排序
② 对每个候选对进行发送检查
③ 对每个候选对进行接收检查
④ 联通性检测过程如图所示

六、webRTC端到端交互讲解

1.整体流程

A是发起端，B是接收端，分别与信令服务器建立连接。
A创建PeerConnect，通过getUserMdedia拿到本地视频流，将流添加到连接中去；
A调用create offer来创建SDP，并将SDP设置到槽中，底层发送binding请求，去sturn收集候选者；并将SDP发送到信令服务器；
信令服务器对SDP进行中转给B；
B对SDP做一系列处理，此时B存储两个SDP，自己的SDP以及远端的SDP。底层发送binding请求，去sturn收集候选者；并将SDP发送到信令服务器；
信令服务器对SDP进行中转给A，A再进行存储SDP；
sturn服务将候选者返回给A（onIceCandidate）；
A再将候选者发送给信令服务器转给B；
B调用AddIceCandidate方法将A的候选者数据存储，B从sturn受到自己的候选者数据后再转发给A；
A调用AddIceCandidate方法将B的候选者数据存储；
此时webRTC底层就会进行候选者检测，生成候选者对，排序，连接检测，找到最优线路；
建立P2P通路后，A将流传输到B，B收到onAddStream事件后，可以对流进行显示，渲染等操作；

2.媒体协商

SDP的交换过程即为媒体协商。
A首先通过setLocalDescription收集候选者（通过STUN和TURN服务拿到候选者），同时创建一个offer，形成SDP报文，通过云端的信令channel传给B。
B收到数据后，调用setRemoteDescription将SDP信息存储到槽中。
B再创建一个answer形成B的SDP，同时也会调用setLocalDescription收集B的候选者，通过云端的信令channel传给A。
A收到数据后，调用setRemoteDescription将SDP信息存储到槽中。
最终A和B都会存储两个SDP，对两个SDP取交集，拿到最好的组合数据

协商过程中的状态机如下图：

PRAnswer是一个中间状态（还没有准备好数据），它仅回复候选者等信息，不包含媒体相关信息，表示自己仅能发送数据，还没做好准备，等用户开启媒体权限后，就可以传输媒体数据了。
好处是可以提前建立连接，包括ICE，DTLS跟链路相关的协商都已经建立好了

3.SDP

3.1 webRTC的SDP结构

3.2 SDP规范

会话层：

包含：会话的名称与目的，会话的存活时间，会话中包括多个媒体信息

媒体层：

包含：媒体格式（音视频），传输协议（RTP，UDP等），传输IP和端口，媒体负载类型（编码类型）

SDP格式

SDP结构分为会话描述，时间描述和媒体描述

会话描述中的type：SDP版本，会话owner和session标识，session名称，连接信息（ip地址，端口，地址类型，网络类型等），全局的属性（用处不大）

时间描述中的type：存活时间，重复次数

媒体描述中的type：媒体名字和传输地址，连接信息，带宽信息，属性（最复杂的）

3.3 实际分析offer和answer的SDP

1.Offer的SDP

o中的2表示SDP的版本，每使用一次SDP，版本加1，用于区分不同的session

group：BUNDLE 0 表示有一个流进行绑定，如果有音频流，或其他流，则0后面会跟随1 2，BUNDLE表示这些流在一个连接中传输

msid表示媒体流ID，WMS是webrtc media stream缩写

SAVPF 安全，音视频，协议族

ufrag和pwd是在链路检查时，对有效性进行验证，类似用户名和密码

options的trickle，不必等候选者全部收集完再进行连通性检测，在setlocalDesc后每收到一个候选者就筛选一次

fingerprint是指DTLS证书的指纹，当进行证书交换时会验证对方证书的指纹是否一致

setup：actpass是指媒体协商过程中既可以作为服务端，也可以作为客户端，由answer来选定

mid是指媒体ID

extmap是指对于媒体的rtp头的扩展

sendrecv是指既可以发送也可以接收

rtcp-mux是指复用rtp端口

rsize是指回的rtcp消息能不能减少，告诉对方仅发送丢包多少，收包多少。不发送网络状况，带宽等信息

rtpmap是指对96媒体格式进行说明，rtcp-fb是指支持的rtcp反馈信息

rtpmap的rtx是指在发生丢包时，支持重传，apt是指对96的重传

fec是指冗余包，防止丢包，red时冗余丢包的策略

ssrc是指vp8,vp9,h264等的标识