WebRTC 学习报告

作者: 耦耦 | 来源:发表于2018-04-02 20:42 被阅读218次

刚开始接触webRTC，会遇到很多问题。webRTC移动端兼容性检测，如何配置MediaStreamConstraints，信令(iceCandidate, sessionDescription)传输方式的选择，iceCandidate和sessionDescription设置的先后顺序，STUN和TURN的概念，如何实现截图及录制视频及上传图片和视频功能，如何高效跟踪错误等等。笔者带着这些问题来写这个笔记，敬请指教！

一、introduction

WbRTC是Web Real-Time Communication的缩写，顾名思义，也就是web实时通讯技术，它允许网络应用或站点，在不借助中间媒介、不安装任何插件或者第三方软件的情况下，建立浏览器之间P2P链接，实现视频流或者其他任意数据的传输。而Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序调用相应的接口即可实现。

说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间P2P的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备（包括PC端和移动端）的摄像头、话筒，使得浏览器之间可以传递音频和视频

WebRTC 是一组开放的 API，用于实现实时音视频通话并且已成为 W3C 标准草案，目前是WebRTC 1.0版本，Draft 状态。

webrtc几个相关概念

SDP(Session Description Protocol)
SDP是一种会话描述协议，用来描述双方的IP地址和端口号，通信所使用的带宽，会话的名称、标识符、激活时间，双方所要传输的媒体类型（视频、音频、文本）、媒体格式等等。该协议仅包含所要传递的媒体的描述信息，而不直接传递媒体内容。
ICE（Interactive Connectivity Establishment）
ICE是一种以UDP为基础用于实现穿越NAT网管或者防火墙的协议。
TURN&&STUN
两种协议都是用来明确自己的外网地址的，差别是如果要服务器辅助进行数据交换则设置TURN服务器，不需要则设置STUN服务。

二、兼容性

目前主流浏览器对 WebRTC 标准的支持情况如下（目前主要支持chrome和Firefox）：

浏览器	支持情况
Chrome（29+）/Opera（36+）	支持
Firefox（45+）	支持
Android Browser	支持（5.0+）
Safari/iOS	支持
Edge（14+）	支持
IE	不支持

实时查看WebRTC在浏览器中的支持情况： http://caniuse.com/#search=webRTC

三、WebRTC 系统包含的元素

WebRTC系统所包含的典型元素：

Web服务器
运行于各种设备和操作系统之上的浏览器
台式机
平板电脑
手机和其他服务器
PSTN(公用交换电话网)门户
以及其他互联网通信终端
WebRTC支持上述所有设备之间的通信。

四、WebRTC三个API

1、MediaStream（又称getUserMedia）

通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流

用法

navigator.mediaDevices.getUserMedia(constraints);

一般来说，navigator.mediaDevices.getUserMedia用法：

navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
  /* use the stream */
  /* handleSuccess  成功回调函数*/
})
.catch(function(err) {
  /* handle the error */
 /* handleError   失败处理函数*/
});

之前一直以为getUserMedia()和mediaDevice.getUserMedia()的写法相同，但在实践的时候发现是不可以的。getUserMedia接受三个参数（约束条件、成功回调函数、失败回调函数），mediaDevice.getUserMedia只接受一个参数，其他处理函数是以.then和.catch来实现的。

常见的错误可以点击这里进行查看 ==> Common getUserMedia() Errors

注意：~~navigator.getUserMedia~~此方法已经被navigator.mediaDevices.getUserMedia取代。

三个参数

(1)constraints：约束项
- 属性：约束项可以具有下面这两个属性中的一个或两个：
  - 1.audio—表示是否需要音频轨道
  - 2.video—表示是否需要视频轨道
    - 分辨率：width、height
    - 关键字：min、max、exact、ideal
    - 获取移动设备的前置或者后置摄像头
      使用视频轨道约束的facingMode属性。可接受的值有：user（前置摄像头），environment（后置摄像头），left和right。
    - 帧速率：frameRate
    - 使用特定的网络摄像头或者麦克风。
(2)handleSuccess：成功回调函数
如果调用成功，传递给它一个流对象
(3)handleError：失败回调函数
如果调用失败，传递给它一个错误对象

约束对象可定义如下属性：

属性	含义
* video:	是否接受视频流
* audio：	是否接受音频流
* MinWidth:	视频流的最小宽度
* MaxWidth：	视频流的最大宽度
* MinHeight：	视频流的最小高度
* MaxHiehgt：	视频流的最大高度
* MinAspectRatio：	视频流的最小宽高比
* MaxAspectRatio：	视频流的最大宽高比
* MinFramerate：	视频流的最小帧速率
* MaxFramerate：	视频流的最大帧速率

如果网页使用了getUserMedia，浏览器就会询问用户，是否许可提供信息。如果用户拒绝，就调用回调函数handleError。发生错误时，回调函数的参数是一个Error对象，它有一个code参数，取值如下：

PERMISSION_DENIED：用户拒绝提供信息。
NOT_SUPPORTED_ERROR：浏览器不支持指定的媒体类型。
MANDATORY_UNSATISHIED_ERROR：指定的媒体类型未收到媒体流。

配置MediaStreamConstraints

所谓MediaStreamConstraints，就是navigator.mediaDevices.getUserMedia(constraints)传入的constraints，

对于移动端来说控制好视频图像的大小是很重要的，例如本项目中想要对方的图像占据全屏，这不仅是改变video元素的样式或者属性能做到的，首先要做的是改变MediaStreamConstraints中的视频分辨率(width, height)，使其长宽比例大致与移动端屏幕的类似，然后再将video元素的长和宽设置为容器的长和宽(例如100%)。

另外对于getUserMedia一定要捕获可能出现的错误，如果是老的API，设置onErr回调，如果是新的(navigator.mediaDevices.getUserMedia)，则catch异常。这样做的原因：getUserMedia往往不会完全符合我们的预期，有时即使设置的是ideal的约束，仍然会报错，如果不追踪错误，往往一脸懵逼。这也是后文要提到的高效追踪错误的方法之一。

兼容浏览器的getUserMedai的写法

var getUserMedia = (navigator.getUserMedia ||
                    navigator.webkitGetUserMedia ||
                    navigator.mozGetUserMedia || 
                    msGetUserMedia);

检测webRTC的可行性

主要从getUserMedia和webRTC本身来入手，示例代码如下：

function detectWebRTC() {
  const WEBRTC_CONSTANTS = ['RTCPeerConnection', 'webkitRTCPeerConnection', 'mozRTCPeerConnection', 'RTCIceGatherer'];

  const isWebRTCSupported = WEBRTC_CONSTANTS.find((item) => {
    return item in window;
  });

  const isGetUserMediaSupported = navigator && navigator.mediaDevices && navigator.mediaDevices.getUserMedia;

  if (!isWebRTCSupported || typeof isGetUserMediaSupported === 'undefined' ) {
    return false;
  }

  return true;
}

HTMLMediaElement.srcObject

接口的srcObject属性HTMLMediaElement设置或返回作为媒体源的对象HTMLMediaElement，该对象可以是a mediaStream、a mediaSource、a blog 、a file。

用法

var mediaStream = HTMLMediaElement .srcObject
 HTMLMediaElement .srcObject = mediaStream

例

这个例子使用srcObject并优雅地回退到src如果srcObject抛出错误。

const mediaSource = new MediaSource();
const video = document.createElement('video');
try {
  video.srcObject = mediaSource;
} catch (error) {
  video.src = URL.createObjectURL(mediaSource);
}

URL.createObjectURL()

注意：使用一个~~MediaStream~~对象作为此方法的输入正在被弃用。这个方法正在被讨论是否应该被移除. 所以，你应当在你使用MediaStream时避免使用这个方法，而用HTMLMediaElement.srcObject() 替代.

getUserMediaMedai的实现简单代码

navigator.getUserMedia = navigator.getUserMedia ||
                         navigator.webkitGetUserMedia || 
                         navigator.mozGetUserMedia ||
                         navidator.msGetUserMedia;

var constraints = { // 音频、视频约束
  audio: true, // 指定请求音频Track
  video: {  // 指定请求视频Track
      mandatory: { // 对视频Track的强制约束条件
          width: {min: 320},
          height: {min: 180}
      },
      optional: [ // 对视频Track的可选约束条件
          {frameRate: 30}
      ]
  }
};

var video = document.querySelector('video');

function successCallback(stream) {
  if (window.URL) {
    video.src = window.URL.createObjectURL(stream);
  } else {
    video.src = stream;
  }
}

function errorCallback(error) {
  console.log('navigator.getUserMedia error: ', error);
}

navigator.getUserMedia(constraints)
.then(function(){
    successCallback(stream);
})
.catch(function(){
    errorCallback(error)
});

如果本机有多个摄像头/麦克风，这时就需要使用MediaStreamTrack.getSources方法指定，到底使用哪一个摄像头/麦克风。

2、 RTCPeerConnection（核心API）

RTCPeerConnection的作用是在浏览器之间建立数据的“点对点”（peer to peer）通信，也就是将浏览器获取的麦克风或摄像头数据，传播给另一个浏览器。这里面包含了很多复杂的工作，比如信号处理、多媒体编码/解码、点对点通信、数据安全、带宽管理等等。

不同客户端之间的音频/视频传递，是不用通过服务器的。但是，两个客户端之间建立联系，需要通过服务器。服务器主要转递两种数据。

通信内容的元数据：打开/关闭对话（session）的命令、媒体文件的元数据（编码格式、媒体类型和带宽）等。
网络通信的元数据：IP地址、NAT网络地址翻译和防火墙等。

WebRTC协议没有规定与服务器的通信方式，因此可以采用各种方式，比如WebSocket。通过服务器，两个客户端按照Session Description Protocol（SDP协议）交换双方的元数据。

RTCPeerConnection是在Chrome中和Android设备中使用，经过几次迭代之后RTCPeerConnection现在支持 Chrome and Opera作为webkitRTCPeerConnection，Firefox 作为mozRTCPeerConnection。Google维护一个函数库adapter.js，用来抽象掉浏览器之间的差异。

UDP和TCP的区别

（Transmisson Control Protocol，TCP）传输控制协议，它保证如下几点：

任何送出的数据都有送达的确认
任何未送达接收端的数据会被重传并停止发送更多的数据。
数据是唯一的，接收端不会有重复的数据

（User Datagram Protocol， UDP）用户数据报协议，以下是他不保证的事情：

不保证数据发送或接收扥先后顺序。
不保证每一个数据包都能都传送到接收端吗；一些数据可能在半路丢失。
不跟踪每一个数据包的状态，即使接收端有数据丢失也会继续传输。

TCP的这些限制使得WEBRTC开发者选择UDP作为传输协议，webRTC的音频、视频和数据在浏览器间的传输不需要最可靠但需要最快。这意味着允许丢失帧，也就是说这类应用来说UDP是一个更好的选择。但不意味着webRTC就不使用TCP协议！

如果UDP传输失败， ICE 会尝试TCP: 首先是 HTTP, 然后才会选择 HTTPS。如果直接连接失败，通常因为企业的NAT转发和防火墙，也就是ICE使用了第三方中转。这样一来，ICE首先使用STUN和UDP和直接连接端点，失败之后返回TURN服务器，表达式‘finding cadidates’指向找到的网络接口和端口。

没有服务器的RTCPeerConnection

请求和被请求都在同一个页面，它们可以直接通过RTCPeerConnection对象在页面上交换信息，而不需要使用中介的信号机制。WebRTC samples用的是这种方式，但一般来说，实际开发的时候，这种方式不会用到。只是在学习和测试的时候用的比较多【个人而言】。

有服务器的RTCPeerConnection

在现在的世界里，WebRTC需要服务器，但是服务器配置非常简单，步骤如下：

用户找到对方并交换双信息，比如名字。
WebRTC客户端应用交换网络信息。
两个端交换多媒体数据信息。
WebRTC客户端遍历NAT 网关和防火墙。

其他方面，WebRTC需要四个类型的服务器端功能：

用户连接和通信
信号量
NAT/防火墙转发
如果通信失败再次发送

服务器主要转递两种数据。

通信内容的元数据：打开/关闭对话（session）的命令、媒体文件的元数据（编码格式、媒体类型和带宽）等。
网络通信的元数据：IP地址、NAT网络地址翻译和防火墙等。

WebRTC协议没有规定与服务器的信令通信方式，因此可以采用各种方式，比如WebSocket（HTTP、数据通道等）。通过服务器，两个客户端按照Session Description Protocol（SDP协议）交换双方的元数据。

兼容浏览器的PeerConnection写法

var PeerConnection = (window.PeerConnection ||
                    window.webkitPeerConnection00 || 
                    window.webkitRTCPeerConnection || 
                    window.mozRTCPeerConnection);

信号: session控制，网络和多媒体信息

WebRTC使用RTCPeerConnection进行两个浏览器之间的数据流的通信，但是也需要一种机制来协调沟通控制信息，这一个过程叫做信号。信号的方法和协议不是WebRTC指定的，而是RTCPeerConnection API的一部分。

信号用来交换以下三个类型的信息：

Session控制信息：用来初始化或是关闭通信，并报告错误。
网络配置：本机的IP和端口等配置。
媒体功能：编码解码器配置。

建立webRTC的基本会话流程

singing server信令服务器：用来开始和结束通话，即开始视频、结束视频这些操作指令和通信数据的交换等。

注意：使用turn服务器的时候，客户端AB不直接通信，而是分别与turn通信从而建立链接。
使用stun服务器的时候，因为客户端B无法访问客户端A的内网IP，所以A通过stun服务器获得自己的外网IP再发送给B，从而建立链接。

webRTC基本会话流程

首先双方都建立一个RTCPeerConnection的实例，其中一方（称为offer方）用RTCPeerConnection.createOffer()创建一个会话描述sessionDescription，该会话描述包含SDP报文信息和该sessionDescription的类型(type)
接下来调用RTCPeerConnection.setLocalDescription()方法将本地的localDescription设置为刚才创建的sessionDescription。之后将创建的sessionDescription发送给对方（称为answer方），发送方式没有规定，可以通过服务器中转，可以通过IM软件发送(这里使用WebSocket信令服务器)。
answer端接收到sessionDescription后调用RTCPeerConnection. setRemoteDescription方法设置,然后调用RTCPeerConnection. createAnswer方法产生自己的sessionDescription。
再将创建的sessionDescription发送给offfer方，同样发送方式没有规定。offer方接收到sessionDescrip后调用RTCPeerConnection. setRemoteDescription方法设置，这样双方的SDP信息就交换完成了。
在完成SDP的交换后双方还要交换ICE candidate信息。双方首先设置RTCPeerConnection.onicecandidate回调函数，当candidate可用时，双方中的一方将所有icecandidate发送给对方，发送方式同样没有规定，接收方调用RTCPeerConnection.addIceCandidate方法接收candidate信息。经过这些步骤后双方连接就建立完成了。

注意：~~RTCPeerConnection.addStream~~ 被 RTCPeerConnection.addTrack取代;

3、RTCDataChannel （不常用）

RTCDataChannel 使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据。表示连接的两个对等端之间的 双向数据通道。

我们可以使用channel = pc.createDataCHannel("someLabel");来在PeerConnection的实例上创建Data Channel，并给与它一个标签

例子

var pc = new RTCPeerConnection();
var dc = pc.createDataChannel("my channel", dataChannelOptions);

dc.onmessage = function (event) {
 console.log("received: " + event.data);
};

dc.onopen = function () {
 console.log("datachannel open");
};

dc.onclose = function () {
 console.log("datachannel close");
};

dataChannelOptions为数据通道选项，可以自行配置，并且这个配置项是可选的：

//这两个是主要使用的配置项，其他的配置大多在高级应用中才会使用
var dataChannelOptions = {
    reliable: false,    //设置消息传递是否进行担保
   maxRetransmitTime: 3000     //设置消息传送失败时，多久重新发送
}

DataChannel使用方式几乎和WebSocket一样，有几个事件：

onopen
onclose
onmessage
onerror

四个状态，可以通过readyState获取：

connecting: 浏览器之间正在试图建立channel
open：链接建立成功，可以进行通信，可以使用send方法发送数据了
closing：通道正在被销毁
closed：通道已经被关闭了，无法进行通信

两个暴露的方法:

close(): 用于关闭channel
send()：用于通过channel向对方发送数据

当创建一个数据通道后，你必须等onopen事件触发后才能发送消息。在通道打开前发送消息，会抛出一个异常，这个异常指出通道还没准备好发送消息。

语法和websoket比较相似，用了send()和message()方法。

通信是出现在两个浏览器之间的，所以RTCDataChannel会比WebSocket快一些。RTCDataChannel 支持Chrome, Opera和Firefox.。

数据通道支持如下类型

1、String：Javascript 基本的字符串
2、Blob：一种文件格式的原始数据
3、ArrayBuffer：确定数组长度的数据类型
4、ArrayBufferView：基础的数据视图
将需要的变量传入send方法中，浏览器会做剩下的工作。你可以咋接收消息的一边通过测试来确定数据类型：

dataChannel.onmessage = function(event){
    var data = event.data;
    if(data instanceof Blob){
        // 处理Blob
    }else if(data instanceof ArraBuffer){
        //处理ArrayBuffer
    }else if(data instanceof ArrayBufferView){
        // ArrayBufferView
    }else{
        //处理String
    }
}

加密与安全

webRTC运行时，对于所有协议的实现，都会强烈执行加密功能。这意味着浏览器间的每一个对等连接，都自动处于高的安全级别中。所使用的加密技术都应该满足对等应用的以下几个要求：

信息在传输过程中被窃取，无法进行读取
第三方不能够伪造信息，是消息看上去像是链接者发送的
消息在传输给另一方时不能进行编辑
加密算法的快速性，一支持客户端之间的最大宽带

为了满足各方面的需求，我们的协议使用的是DTLS

安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。
该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议。
TLS的流行是因为直接嵌入到应用层和传输层，是的很少甚至不需要改变应用本身的逻辑二使应用变得安全。使用TLS的唯一缺点就是它必须基于TCP的应用，但我们的webRTC协议并不是在其基础上工作的，
DTLS(Datagram Transport Layer Security)即数据包传输层安全性协议。
DTLS源于希望能有一个像TLS一样简单易用的协议，但拥有UDP传输层的功能。它吸取了TLS协议许多相同的概念，并增加了对UDP的支持。

到这里最大的收获，你需要知道数据通道和webRTC应用中，数据是安全的。

problem progress

1、信令(iceCandidate, sessionDescription)传输方式的选择

要传输的信令包括两个部分：sessionDescription（也就是你传输的是什么？阿猫阿狗）和iceCandidate（以什么样的方式传输？火车空运）。为了便于传输可将其处理成字符串，另一端接收时还原并用对应的构造函数构造对应的实例即可。

webRTC并没有规定信令的传输方式，而是完全由开发者自定义。常见的方式有短轮询、webSocket(socket.io等)，

短轮询的优点无非是简单，兼容性强，但在并发量较大时，服务器负荷会很重。
webSocket就不存在这个问题，但webSocket搭建起来较为复杂，并不是所有的浏览器都支持websocket

综合来说socket.io是个不错的解决方案，事件机制和自带的房间概念对撮合视频会话都是天然有利的，并且当浏览器不支持websocket时可以切换为轮询，也解决了兼容性的问题。

webSocket属于长链接。

2、STUN和TURN的概念

STUN服务器是用来取外网地址的。
TURN服务器是在P2P失败时进行转发的

stun和turn服务的作用主要处理打洞与转发，配合完成ICE协议。
首先尝试使用P2P，如果失败将求助于TCP，使用turn转发两个端点的音视频数据，turn转发的是两个端点之间的音视频数据不是信令数据。因为turn服务器是在公网上，所以他能被各个客户端找到，另外turn服务器转发的是数据流，很占用带宽和资源。

3、webRTC移动端兼容性检测
文章前面有getUserMedia及RTCPeerConnection的浏览器兼容写法

4、如何配置MediaStreamConstraints
约束项在文章前面部分

5、如何高效跟踪错误
整个双向视频涉及到的步骤较多，做好错误追踪是非常重要的。像getUserMedia时，一定要catch可能出现的异常。因为不同的设备，不同的浏览器或者说不同的用户往往不能完全满足我们设置的constraints。还有在实例化RTCPeerConnection时，往往会出现不可预期的错误，常见的有STUN、TURN格式不对，还有createOffer时传递的offerOptions格式不对,正确的应该为：

const offerOptions = {
  'offerToReceiveAudio': true,
  'offerToReceiveVideo': true
};

这些问题还在思考中：
1、如何实现截图及录制视频及上传图片和视频功能。
2、两个不同的客户端实现对等连接的时候，如何获取对方的视频和音频？
3、iceCandidate和sessionDescription设置的先后顺序

notice

考虑版本向上兼容，更要向下兼容！！！

手动运行demo最简单方法就是cd到HTML文件所在目录下，然后python -m SimpleHTTPServer（装了python的话），然后在浏览器中输入http://localhost:8000/{文件名称}.html

对video元素要特殊处理。设置autoPlay属性，对播放本地视频源的video还要设置muted属性以去除回音。针对IOS播放视频自动全屏的特性，还要设置playsinline属性的值为true。

通常有报道说一个平台支持WebRTC，一般都说他们支持getUserMedia，而不支持其它RTC组件，开发的时候需要先弄清楚。

在非官方文档中，并非所有的信息都是正确的，有分歧的地方要学习实践检验（比如有些文档在使用getUserMedai的时候省略navigator，运行的时候会报错）。所以尽可能多看官方文档！

google提供的实现stun协议的测试服务器（stun:stun.l.google.com:19302）

参考资料：
[1]通过WebRTC实现实时视频通信（三）
[2]webRTC实战总结
[3]WebRTC API
[4]使用WebRTC搭建前端视频聊天室——入门篇
[5]webrtc进阶-信令篇-之三：信令、stun、turn、ice
[6]getUserMedai()视频约束
[7]WebRTC1-原理探究

...还有很多