WebRTC是什么？

WebRTC是由Google主导的，由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端之间）的音频、视频及数据共享。WebRTC不需要安装任何插件，通过简单的JavaScript API就可以使得实时通信变成一种标准功能。现在各大浏览器以及终端已经逐渐加大对WebRTC技术的支持。下图是webrtc官网给出的现在已经提供支持了的浏览器和平台。

WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。谷歌2011年6月3日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD（伯克利软件发布）式的许可证向用户提供。开发人员可访问并获取WebRTC的源代码、规格说明和工具等。
WebRTC使用安全实时传输协议（Secure Real-time Transport Protocol，SRTP）对RTP数据进行加密，消息认证和完整性以及重播攻击保护。它是一个安全框架，通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分，其基础全部围绕实时传输协议（Real-time Transport Protocol）进行。

官方资料

https://www.w3.org/TR/webrtc/

相关术语解释

RTP协议(RFC3550)

实时传输协议（RTP）是专为多媒体电话（VoIP，视频会议，远程呈现系统），多媒体流（视频点播，直播）和多媒体广播而设计的网络协议。比如大家想一下：简单的多播音频会议。语音通信通过一个多播地址和一对端口来实现。一个用于音频数据（RTP），另一个用于控制包（RTCP）。

RTP被划分在传输层，它建立在UDP上。同UDP协议一样，为了实现其实时传输功能，RTP也有固定的封装形式。RTP用来为端到端的实时传输提供时间信息和流同步，但并不保证服务质量。服务质量由RTCP来提供。

RTP包的封装格式如下图：

版本号（V）：2比特，用来标志使用的RTP版本。

填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。

扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。

CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。

标记位（M）：1比特,该位的解释由配置文档（Profile）来承担。

载荷类型（PT）：7比特，标识了RTP载荷的类型。

序列号（SN）：16比特，发送方在每发送完一个RTP包后就将该域的值增加1，接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。

时间戳：32比特，记录了该包中数据的第一个字节的采样时刻。在一次会话开始时，时间戳初始化成一个初始值。即使在没有信号发送时，时间戳的数值也要随时间而不断地增加（时间在流逝嘛）。时间戳是去除抖动和实现同步不可缺少的。

同步源标识符(SSRC)：32比特，同步源就是指RTP包流的来源。在同一个RTP会话中不能有两个相同的SSRC值。该标识符是随机选取的 RFC1889推荐了MD5随机算法。

贡献源列表（CSRC List）：0～15项，每项32比特，用来标志对一个RTP混合器产生的新包有贡献的所有RTP包的源。由混合器将这些有贡献的SSRC标识符插入表中。SSRC标识符都被列出来，以便接收端能正确指出交谈双方的身份。

SDP(RFC4566)

个人理解：就是管理Session的信息。
SDP全称是Session Description Protocol，主要用于两个会话实体之间的媒体协商。SDP的主要作用是为了解决参与会话的各成员之间能力不对等的问题，如果参加本次通话的成员都支持高质量的通话，但是我们没有去进行协议，为了兼容性，使用的都是普通质量的通话格式，这样就很浪费资源了。

SDP定义了会话描述的统一格式,但并不定义多播地址的分配和SDP消息的传输,也不支持媒体编码方案的协商,这些功能均由下层传送协议完成。

SDP协议主要包含：

  1. 会话的名称和目的
  2. 会话存活时间
  3. 包含在会话中的媒体信息，包括：
    • 媒体类型(video,audio, etc)
    • 传输协议(RTP/UDP/IP,H.320, etc)
    • 媒体格式(H.261 video, MPEG video, etc)
    • 多播或远端（单播）地址和端口
  4. 为接收媒体而需的信息(addresses, ports, formats and so on)
  5. 使用的带宽信息
  6. 可信赖的接洽信息（Contact information）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//直播编码器生成的sdp文件
v=0
o=- 2545495921 1885424500 IN IP4 192.168.225.158
s=111
c=IN IP4 192.168.225.153
b=RR:0
t=0 0
m=video 5088RTP/AVP 96
b=AS:949
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4D4015;sprop-parametersets=Z01AFZZWCwSbCEiAAAH0AAAw1DBgAHP2AOg1cABQ,aO88gA==;packetization-mode=1
a=cliprect:0,0,576,352
a=framerate:25.
a=mpeg4-esid:201
a=x-envivio-verid:0002229D
m=audio 5090 RTP/AVP 97
b=AS:50
a=rtpmap:97 mpeg4-generic/24000/2
a=fmtp:97 profile-level-id=15; config=1310;streamtype=5; ObjectType=64;
mode=AAC-hbr; SizeLength=13; IndexLength=3;IndexDeltaLength=3
a=mpeg4-esid:101
a=lang:eng
a=x-envivio-verid:0002229D

TURN(RFC5766)

TURN 协议允许 NAT 或者防火墙后面的对象可以通过 TCP 或者 UDP 接收到数据。TURN方式解决NAT问题的思路与STUN相似，是基于私网接入用户通过某种机制预先得到其私有地址对应在公网的地址（STUN方式得到的地址为出口NAT上的地址，TURN方式得到地址为TURNServer上的地址），然后在报文负载中所描述的地址信息直接填写该公网地址的方式，实际应用原理也是一样的。

TURN 的全称为 Traversal Using Relay NAT ，即通过Relay方式穿越NAT，TURN应用模型通过分配TURNServer的地址和端口作为客户端对外的接受地址和端口，即私网用户发出的报文都要经过TURNServer进行Relay转发，这种方式应用模型除了具有STUN方式的优点外，还解决了STUN应用无法穿透对称NAT（SymmetricNAT）以及类似的Firewall设备的缺陷，即无论企业网驻地网出口为哪种类型的NAT/FW，都可以实现NAT的穿透，同时TURN支持基于TCP的应用，如H323协议。

1
略

ICE(RFC5245)

ICE全称Interactive Connectivity Establishment：交互式连通建立方式。ICE参照RFC5245建议实现，是一组基于offer/answer模式解决NAT穿越的协议集合。它综合利用现有的STUN，TURN等协议，以更有效的方式来建立会话。客户端侧无需关心所处网络的位置以及NAT类型，并且能够动态的发现最优的传输路径。

1
略

ICE的基本思路是,每个终端都有一系列 传输地址 (包括传输协议,IP地址和端口)的候选,可以用来和其他端点进行通信。

其中可能包括:

  • 直接和网络接口联系的传输地址(host address)
  • 经过NAT转换的传输地址,即反射地址(server reflective address)
  • TURN服务器分配的中继地址(relay address)

可以说，ICE的本质就是一种规范，用于NAT环境之下的多终端通信链路的查找。

WebRTC架构


相关组件介绍：

  1. Your Web App
    Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音
    频的实时通信应用。
  2. Web API
    面向第三方开发者的WebRTC标准API（Javascript），
    使开发者能够容易地开发出类似于网络视频聊天的web应用。
  3. WebRTC Native C++ API
    本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。
  4. Transport / Session
    传输/会话层：会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议。
    Muti-Platform API：这一层 API 是提供给不同平台应用软件开发者使用的 API，这些API 都会提供三个功能接口，分别是MediaStream、RTCPeerConnection和RTCDataChannel。MediaStream接口用于捕获和存储客户端的实时音视频流，便于客户端的进行音视频采集和渲染。RTCPeerConnection接口是WebRTC 的核心接口，它封装了WebRTC连接的管理，是承载着 WebRTC 连接机制的接口。RTCDataChannel接口是进行WebRTC 连接数据传输的数据通道接口。多平台API有很多，上图的WebAPI和 iOS API 分别是网页和移动端平台的一个代表，分别是用 JavaScript 和 Objective-C语言进行编写，让前端开发者和iOS原生应用开发者可以便捷开发出基于 WebRTC 技术的实时音视频应用程序。
    WebRTC C++ API：这一层的API是提供给浏览器厂商、平台SDK开发者使用的 C++ API，不同的平台可以通过各自的C++接口调用能力，对其进行上层封装，满足跨平台的需求。
    Session management/Abstract signaling：该层是WebRTC的会话层，主要用于进行信令交互和管理 RTCPeerConnection的连接状态。
    Voice Engine：音频引擎模块是一系列音频多媒体处理框架，包括Audio Codecs、NetEQ for voice、Acoustic Echo Canceller（AEC）和Noise Reduction（NR）。其中，Audio Codecs是音频编解码器，当前 WebRTC 支持ilbc、isac、G711、G722和opus等等；NetEQ for voice 是自适应抖动控制算法以及语音包丢失隐藏算法，用于适应不断变化的网络环境；AEC 是回声消除器，用于实时消除麦克风采集到的回声；NR是噪声抑制器，用于消除与相关 VoIP的某些类型的背景噪音（嘶嘶声、风扇噪声等等）。以上多项音频处理技术集成在一起，使得WebRTC在确保音质优美的同时还减小了缓冲延迟。
    Video Engine：视频引擎模块是一系列视频多媒体处理框架，包括Video Codec、Video Jitter Buffer和Image Enhancement。其中，Video Codec是视频编解码器，当前WebRTC 支持VP8、VP9和H.264编解码；Video Jitter Buffer是视频抖动缓冲器，用于降低由于视频抖动和视频信息包丢失带来的不良影响；Image Enhancement 是图像质量增强模块，用于对摄像头采集回来的图像进行处理，包括明暗度检测、颜色增强、降噪处理等。以上多项视频处理技术集成在一起，使得WebRTC在确保画面优美的同时还提高了流畅度。
    Transport：数据传输模块是WebRTC对音视频进行P2P传输的核心模块，包括SRTP、Multiplexing和P2P。其中，SRTP是基于UDP的安全实时传输协议，为WebRTC中音视频数据提供安全单播和多播功能；Multiplexing 是多路复用技术，采用多路复用技术能把多个信号组合在一条物理信道上进行传输，减少对传输线路的数量消耗；P2P是端对端传输技术，WebRTC 的P2P技术集成了STUN、TURN和ICE，这些都是针对 UDP 的NAT的防火墙穿越方法，是连接有效性的保障。

WebRTC核心通信原理

媒体协商

借助SDP协议完成多媒体信息的交换。

网络交换

思考一个问题：WebRTC可以实现P2P的数据传输，那还需要网络服务器吗？网络服务器主要的作用是
什么？

STUN

NAT为设备提供内网IP地址，以便在专用本地网络中使用，但是这个地址不能在外部使用。对于WebRTC而言，没有公共地址，点与点之间就无法直接进行通信。为了解决这个问题，WebRTC采用STUN技术。很多内网的设备可以给公网地址发送数据，并不知道公网是用什么的地址来识别自己的，STUN服务器在收到查询请求的时候会告诉这个设备它的公网地址是啥样子的。设备拿到这个地址把这个地址发送给需要建立直接联系的其他设备。

STUN服务器对计算性能和存储要求都不太高，因此相对低规格的STUN服务器可以处理大量请求。根据webrtcstats.com的统计，有86％的WebRTC应用使用STUN成功建立连接，在内网端点之间的呼叫可能会更少，因为不用考虑防火墙和NAT地址转换。

TURN

TURN服务器具有公共地址，因此即使端点位于防火墙或代理之后，也可以与其他端点进行通信。TURN服务器虽然只有这么一个简单的任务 —— 中继流， 但与STUN服务器不同，它们本身就消耗了大量带宽。换句说，TURN服务器需要更强大。RTCPeerConnection尝试通过UDP建立点与点之间的直接通信。如果失败，RTCPeerConnection将转向TCP。如果TCP连接失败，可以将TURN服务器用作回退，在端点之间中继数据。

信令服务器

信令

信令用于协调通信，WebRTC应用开始通话之前，客户端需要交换一些信息（信令）：

  1. 用于打开或关闭通信的会话控制消息。
  2. 错误信息。
  3. 媒体元数据，例如编解码器和编解码器设置，带宽和媒体类型。
  4. 用于建立安全连接的的秘钥信息。
  5. 主机的IP和端口等网络信息。

为了避免冗余并提高与已有技术的兼容性，WebRTC标准未规定信令方法和协议。

在WebRTC中需要理解信令服务器的主要作用：

  1. 业务上的的隔离，比如对于房间的管理，会有类似群的逻辑概念。
  2. SDP的交换

WebRTC 1V1通话原理

主要过程如下：

  1. 双方先调用getUserMedia打开本机摄像头
  2. 向信令服务器发送加入房间apply_join请求
  3. 信令服务器通知本人加入成功(joined)，同时向其它人广播加入消息(other_joined)
  4. 二端开始创建peerConnection连接
  5. peerB端创建offer，同时将SDP保存到本机(setLocalDescription)，并通过信令服务器传递到peerA
  6. peerB在setLocalDescription后，会异步触发“候选网络链路”收集，大致是通过Stun确定自己所有的NAT映射出口，如果Stun返回NAT是“对称型”的，基本上就没法穿透了，会再通过Turn拿到中继reply地址，并通过信令服务器，将网络候选链路信息发到peerA(即：开始网络协商）。
  7. peerA收到的peerB的SDP后，开始回应(createAnswer)，仍然通过信令服务器，将SDP发送到
    peerB
  8. 同时peerA也会开始网络候选链路的收集，并将自己的网络信息，通过信令服务器，发到peerB(即：
    网络协商)

这样peerA，peerB就相互交换了媒体信息及网络信息，就可以开始通讯了。

本地音视频采集浏览器标准API

https://developer.mozilla.org/zh-CN/docs/Web/API/MediaDevices

核心API理解：
MediaDevices接口提供访问连接媒体输入的设备，如照相机和麦克风，以及屏幕共享等。它可以使你取得任
何硬件资源的媒体数据。

getSupportedConstraints()

约束：可以获取浏览器的UA所支持的约束。（aspectRatio、autoGainControl、brightness、
deviceId等）

MediaDevices.getUserMedia()在用户通过提示允许的情况下，打开系统上的相机或屏幕共享和/或麦克
风，并提供 MediaStream 包含视频轨道和/或音频轨道的输入。MediaStream可以获取音频轨道信息。

MediaDevices.enumerateDevices()请求一个可用的媒体输入和输出设备的列表。