《WebRTC权威指南》学习笔记

本篇是WebRTC的一篇学习笔记。

第1章 Web实时通信技术介绍

相关协议：SIP（RFC3261），Jabber（RFC6120），Jingle（XEP-0166），实时传输协议RTP，安全RTP（SRTP），多路复用RTP控制协议（RTCP）。

相关概念：可扩展消息现场协议（XMPP [RFC6120] 也就是Jabber）服务器，Jingle客户端，公告电话交换网PSTN。

注：这里就碰到第一个问题：如何掌握这些通信协议的问题了

下面是WebRTC的一个总览图

总之，WebRTC支持多中设备，多方会话。这个时候多方会话有两种方案：集中式和全网状对等连接。其中全网状的连接把混合数据的操作落在了端上，一旦与会端加多就会带来问题，不适合增加规模。集中式是把数据的混合放在服务端，这样缺点是延迟较大，但是服务器扩容比较容易，所以适合大规模人员参会。

第2章 如何使用WebRTC

建立WebRTC会话有四步：

1. 获取本地媒体：getUserMedia
2. 建立对等连接：RTCPeerConnection
3. 交换媒体或数据：RTCSessionDescription
4. 关闭连接

第3章 本地媒体

WebRTC中的媒体基本单元叫MediaStreamTrack（媒体流轨道，表示一种源返回的单一类型媒体，这个源可能是设备或者是录制内容），而一个MediaStream（媒体流）中可以有若干MediaStreamTrack。

一个媒体流轨道可以是单个立体声源，或者多声道环绕音频信号。

媒体流轨道 MediaStreamTrack的暂停有两种方式：静音（muted）和禁用（enabled）。在WebRTC中使用了不同的参数控制。

创建一个MediaStream有两种方式：请求和访问本地媒体getUserMedia()；通过MediaStream构造函数将现有的对象复制过来，或者通过现有的流对象添加/删除轨道而来。

媒体的选择和控制是通过参数约束来实现的。 约束大体上分为强制约束和可选约束，而具体的约束属性值有两种，一种是枚举类型的，一类是范围的（就是有最小值和最大值限定）。

在源设备获取到媒体流之后通过处理，打包成不同的MediaStream，交给传输管道发往接收端。接收端通过解析不同的MediaStream，根据不同的ID解析到全部MediaStreamTrack，然后选择性地交由不同的播放/渲染设备。

第4章 信令

信令的标准没有确定下来，但是实践中有多个方案。

信令的作用？

1. 在参与会话的两个端之间交换会话描述协议对象中的信息
2. 标识和身份验证
3. 媒体会话控制
4. 双占用分解

信令为什么没有确立标准?

因为不同的浏览器是可以通过向同一个Web服务器请求下载同一份JS代码来使用相同的信令，这样客观上就让信令变成了一种Web服务器相关的标准，无关乎浏览器。既然没有必要，也就没有这样做的必然性了。

信令的传输方法

1. HTTP传输
2. WebSocket
3. 数据通道

信令协议

标准的信令协议有SIP，Jingle等。

具体的方案：

1. HTTP轮询
2. WebSocket代理
3. Google应用程序引擎通道API
4. WebSocket SIP
5. WebSocket Jingle，Jingle是对XMPP的扩展，又称为Jabber
6. 数据通道专有信令
7. 使用叠加网络

一个可运行的信令通道代码

第5章 对等媒体

WebRTC使用对等媒体流，语音、视频、数据的连接都在两个浏览器之间建立。但是由于NAT和防火墙的存在增加了这一方案的复杂性。

下面这种方案由于需要源浏览器发送信息到Web服务器，然后由服务器发往目标浏览器，所以对服务器压力较大。

采用WebRTC架构的媒体流，使用了RTCPeerConnection API，可以建立点对点的连接。这种架构对于浏览器和服务器之间的距离要求也较低。

WebRTC和网络地址转换（NAT）

NAT通常内置于Internet路由器或者集线器中。一个WebRTC要处理的情况如下图：

通过打洞技术可以有下面两种方式实现两个浏览器互联：

STUN服务器

这个是被称作NAT会话遍历使用工具的服务器（Session Traversal Utilities for NAT）。这种服务器有一个公网的IP地址，可以帮助遍历NAT。浏览器通过发送STUN数据包给STUN服务器获取待连接的浏览器的IP地址。

TURN服务器

这个是被称作中继型NAT遍历服务器（Traversal Using Relay around NAT）。这种服务器也有一个公网的IP地址，用来转发来自浏览器的数据包，或者向浏览器转发来自服务器的数据包。

第6章 对等连接和提议/应答协商

要建立连接的双方需要先通过协商沟通好支持哪些类型的媒体流，因为浏览器所在设备的支持能力不尽相同。具体过程如下描述：

首先，发起者针对要建立的媒体会话创建描述，以此来发起会话，此即“提议”；通过信令通道发往另一方。对方收到后予以回应，此即“应答”；应答中包含了提议的会话功能特性中，另一方能够和愿意支持的功能；并通过信令通道返回。

WebRTC使用RTCSessionDescription对象来表示提议和应答。

第7章 数据通道

WebRTC中的数据通道不是媒体交互通道，是用来绕过服务器直接交换数据的通道。相比WebSocket和HTTP传输来说，这两者只是传输一些少量的数据，数据通道可以传输流量大，时延低的数据。

创建了对等连接之后才会创建数据通道，而且只需要发起者创建一个数据通道，对端并不需要创建，这个时候就是要给单向通道，对端只是被动接收数据。

pc = new RTCPeerConnection();
dc = pc.createDataChannel("dcl");

数据通道建立之后，可以做一些配置。比如失败重传次数，重试操作最大时长，此二者互斥；还有数据送达之后顺序问题。当然也可以由原来的接收方创建第二个数据通道形成双向通道，但是有点浪费，WebRTC提供了一种方法可以将两个通道关联起来。

// 下面的代码通过设置两个id都为1，将二者绑定在一起

// 本地对等端：创建数据通道的前半部分
properties = {negotionation: true, id: 1, maxRetransmits: 3};
dc = pc.createDataChannel("", properties);

// 远程对等端：创建数据通道的后半部分	
properties = {negotionation: true, id: 1, maxRetransmits: 6};
dc = pc.createDataChannel("", properties);

第8章 W3C文档

主要介绍了一些标准API。

浏览器之间实时通信用到的API，比如核心RTCPeerConnection接口，数据API，DTMF API，统计数据API，身份API。具体可以参考 WebRTC 1.0: Real-time Communication Between Browsers。

媒体捕获和流，比如getUserMedia方法，MediaStream接口，MediaStreamTrack接口。具体可以参考Media Capture and Streams。

流的录制API，参考MediaStream Recording。

图像捕获 MediaStream Capture Scenarios，

第9章 NAT和防火墙穿透

交互式连接建立（Interactive Connectivity Establishment ICE）是一种标准穿透协议。它利用STUN和TURN服务器来帮助端点建立连接。

分述：
收集候选传输地址 一旦A用户要发起与B用户的连接请求，ICE代理A会收集候选地址。而ICE代理B在信令通道中，一旦收到来自A的对等连接请求的时候，也开始收集候选地址。这个候选地址有4种：

交换候选地址 通过信令通道进行，按照上表的顺序从上往下，优先级由高到低。

STUN连接检查 当代理A从代理B收到SDP应答的时候开始检查，代理B在向代理A发送了SDP应答的时候开始检查。检查会剔除一些不可能的连接对，比如IPv4和IPv6地址对。一个目的是减少执行的连接检查数量。同时，为了确保NAT映射和过滤规则不会在会话期间超时，ICE会每隔15秒通过使用中的候选项对发送连接检查。

ICE重新启动 当基地址发生变化的时候，会导致ICE重新开始第一步来收集候选项。这个技术点还在优化中……

相关协议：STUN，TURN，SIP

第10章 协议

与WebRTC相关的重要协议有：

这些协议内容都可以在IETF Document中搜索。

WebRTC协议

第11章 IETF文档

第12章 与IETF相关的RFC文档

实时传输协议：

会话描述协议

NAT遍历协议

编解码器

第13章 安全和隐私

【略】

第14章 实现和应用

目前主流的浏览器中只有Safari，Chrome，Opera支持。

另外，附加一条公司的招聘链接，考虑的小伙伴可以私信我：