WebRTC介绍及简单应用

WebRTC介绍及简单应用

---

WebRTC，即Web Real-Time Communication，web实时通讯技术。简单地说就是在web浏览器里面引入实时通讯，包括音视频通话等。

• WebRTC实时通讯技术介绍
• 如何使用
• 媒体介绍
• 信令
• STUN和TURN介绍
• 对等链接和提议/应答协商
• 数据通道
• NAT和防火墙穿透
• 简单应用
• 其它

---

WebRTC实时通讯技术介绍

WebRTC实现了基于网页的语音对话或视频通话，目的是无插件实现web端的实时通讯的能力。

WebRTC提供了视频会议的核心技术，包括音视频的采集、编解码、网络传输、展现等功能，而且还支持跨平台，包括linux、windows、mac、android等。

1. WebRTC三角形

2. WebRTC梯形

3. WebRTC的多方会话

WebRTC支持多个浏览器参与的多方会话或会议会话，要创建这类会话有以下两种模式：

4. WebRTC新功能特性

---

如何使用WebRTC

WebRTC易于使用，只需极少步骤即可创建媒体会话。有些消息在浏览器和服务器之间流动，有些则直接在两个浏览器（成为对等端）之间流动。

一、创建WebRTC会话

创建WebRTC链接须要以下几个步骤：

• 获取本地媒体（getUserMedia()，MediaStream API）
• 在浏览器和对等端（其它浏览器或终端）之间创建对等链接（RTCPeerConnection API）
• 将媒体和数据通道关联至该链接
• 交换会话描述（RTCSessionDescription）

• 浏览器M从Web服务器请求网页
• Web服务器向M返回带有WebRTC js的网页
• 浏览器L从Web服务器请求网页
• Web服务器向L返回带有WebRTC js的网页
• M决定与L通讯，经过M自身的js将M的会话描述对象（offer，提议）发送至Web服务器
• Web服务器将M的会话描述对象发送至L上的js
• L上的js将L的会话描述对象（answer，应答）发送至Web服务器
• Web服务器转发应答至M上的js
• M和L开始交互，肯定访问对方的最佳方式
• 完成后，M和L开始协商通讯密钥
• M和L开始交换语音、视频或数据

WebRTC三角形会话具体的调用流程：

说明：
    SDP对象的传输多是一个来回反复的过程，而且该过程采用的协议并未标准化

WebRTC梯形会话方式具体的调用流程：

说明：
    此场景中，浏览器M和L直接交换媒体，只是它们运行的Web服务器不用而已。每一个浏览器的会话描述对象都会映射至Jingle[XEP-0166]session-initiate消息和session-accept方法。

---

媒体介绍

先来看下WebRTC中的本地媒体：

一、WebRTC中的媒体

• 轨道（MediaStreamTrack，表明设备或录制内容可返回的单一类型的媒体，惟一关联一个“源”，WebRTC不能直接访问或控制“源”，对“源”的一切控制都经过轨道实施；一个“源”可能对应多个轨道对象）
• 流（MediaStream，轨道对象的集合）

轨道和流的示意以下：

二、捕获本地媒体

以下代码展现了本地媒体的简单获取，并展现：

// 注意getUserMedia()在各浏览器中的区别  
// Opera --> getUserMedia  
// Chrome --> webkitGetUserMedia  
// Firefox --> mozGetUserMedia  
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;  
  
// 只获取video:  
var constraints = {audio: false, video: true};  
var video = document.querySelector("video");  
  
function successCallback(stream) {  
    // Note: make the returned stream available to console for inspection  
    window.stream = stream;  
      
if (window.URL) {  
        // Chrome浏览器
        video.srcObject = stream;  
    } else {  
        // Firefox和Opera: 能够直接把视频源设置为stream  
        video.src = stream;  
    }  
    // 播放  
    video.play();  
}  
  
function errorCallback(error){  
    console.log("navigator.getUserMedia error: ", error);  
}  
  
navigator.getUserMedia(constraints, successCallback, errorCallback);

运行效果以下：

完整代码查看：https://github.com/caiya/webrtc-demo.git

---

信令

在WebRTC中，信令起着举足轻重的做用。但实现没有标准化，好比http、websocket、xmpp等。

一、信令的做用

• 协商媒体功能和设置
• 标识和验证会话参与者的身份（交换SDP对象中的信息：媒体类型、编解码器、带宽等元数据）
• 控制媒体会话、指示进度、更改会话、终止会话
• 双占用分解

简单地说，信令就是协调通信的过程，一旦信令服务创建好了，两个客户端之间创建了链接，理论上它们就能够进行点对点通信了。

二、信令的传输

WebRTC要求在两个对等端创建双向的信令通道，一般有三种方式来传输WebRTC信令：http、websocket、数据通道

http方式以下：

websocket代理信令传输：

三、WebRTC中的服务器

WebRTC提供了浏览器端的P2P通讯，但并不意味着WebRTC不须要服务器。撇开应用服务器不说，至少如下两种服务器是必须的：

• 浏览器之间创建通讯前交换各类元数据（信令）的服务器（信令服务）
• 穿越NAT和防火墙的服务器（stun、turn、rsip等）

说明：
    元数据是经过信令服务器中转发给另外一个客户端，可是对于流媒体数据，一旦会话创建，首先尝试使用点对点链接。简单一点说就是：每一个客户端都有一个惟一的地址，他能用来和其余客户端进行通信和数据交换。
    
    STUN服务器：用来取外网地址的。（见下节）
    
    TURN服务器：在P2P失败时进行转发的。（见下节）
    
    ICE：*Interactive Connectivity Establishment*，即交互式连通创建方式。并不是一种新的协议，它经过综合利用现有NAT穿透协议，以一种更有效的方式来组织会话创建过程，使之在不增长任何延迟同时比STUN等单一协议更具备健壮性、灵活性。

四、信令交互和RTCPeerConnection的创建

WebRTC使用RTCPeerConnection创建链接传送流数据，在创建RTCPeerConnection实例以后，想要创建点对点的信道，须要作两件事：

• 肯定本机上的媒体流的特性，好比分辨率、编解码能力啥的（SDP描述符）
• 链接两端的主机的网络地址（ICE Candidate）

经过offer和answer交换SDP描述符：

• 甲和乙各自创建一个PC实例
• 甲经过PC所提供的createOffer()方法创建一个包含甲的SDP描述符的offer信令
• 甲经过PC所提供的setLocalDescription()方法，将甲的SDP描述符交给甲的PC实例
• 甲将offer信令经过服务器发送给乙
• 乙将甲的offer信令中所包含的的SDP描述符提取出来，经过PC所提供的setRemoteDescription()方法交给乙的PC实例
• 乙经过PC所提供的createAnswer()方法创建一个包含乙的SDP描述符answer信令
• 乙经过PC所提供的setLocalDescription()方法，将乙的SDP描述符交给乙的PC实例
• 乙将answer信令经过服务器发送给甲
• 甲接收到乙的answer信令后，将其中乙的SDP描述符提取出来，调用setRemoteDescripttion()方法交给甲本身的PC实例

经过ICE框架创建NAT/防火墙穿越的链接：

WebRTC使用ICE框架来得到这个外界能够直接访问的地址，RTCPeerConnection在创立的时候能够将ICE服务器的地址传递进去，如：

var iceServer = {
    "iceServers": [{
        "url": "stun:stun.l.google.com:19302"
    }]
};
var pc = new RTCPeerConnection(iceServer);

• 甲、乙各建立配置了ICE服务器的PC实例，并为其添加onicecandidate事件回调
• 当网络候选可用时，将会调用onicecandidate函数
• 在回调函数内部，甲或乙将网络候选的消息封装在ICE Candidate信令中，经过服务器中转，传递给对方
• 甲或乙接收到对方经过服务器中转所发送过来ICE Candidate信令时，将其解析并得到网络候选，将其经过PC实例的addIceCandidate()方法加入到PC实例中

这样链接就创立完成了，能够向RTCPeerConnection中经过addStream()加入流来传输媒体流数据。

---

STUN和TURN介绍

浏览器位于网络地址转换设备（NAT）以后是一种极为广泛的设计。举个栗子：

再来看个图，了解下“公共地址”和“私有地址”：

NAT主要负责维护内部ip地址和端口号与外部ip地址和端口号之间的映射表。

一、STUN服务器

STUN，Session Traversal Utilities for NAT，称为NAT会话遍历实用工具服务器。简单地说，就是获取内网设备的最外层NAT（公共ip地址）信息。

二、TURN服务器

TURN，Traversal Using Relay around NAT，称为中继型NAT遍历服务器。

说明：
    媒体中继地址是一个公共地址，用于转发接收到的包，或者将收到的数据包转发给浏览器。若是两个对等端由于NAT类型等缘由不能直接创建P2P链接的话，那么可使用中继地址。
    
    ps：相比较直接使用web服务器提供媒体中继理想点。

---

对等链接和提议/应答协商

上一节中有简单介绍对等链接和offer/answer交互流程，这节再说明下。

其实WebRTC定义了两组主要的功能，分别是：媒体捕获（getUserMedia()，前面已介绍）、媒体传输。对等链接和提议/应答协商的概念是媒体传输的核心。

一、对等链接

RTCPeerConnection接口是WebRTC的主要API，用来在P2P端创建媒体链接及数据链接路径。RTCPeerConnection对象的构造函数有一系列属性，最主要的是iceServers属性，表示服务器地址列表。用于帮助透过NAT和防火墙创建会话。

var pc = new RTCPeerConnection({
    iceServers: [{
        url: 'stun:stun.l.google.com:19302'
    },{
        url: 'turn:user@turn.myserver.com',
        credential: 'test'
    }]
})

getUserMedia({
    audio: true,
    video: true
}, successCB, failureCB)

function successCB(stream) {
    // 告知浏览器，我要发送MediaStream
    pc.addStream(stream)        // removeStream()
}

二、提议/应答协商

要在两者之间创建链接，必须在两者之间创建会话。offer/answer是一种“一次性经过”型协商机制。实际中该过程可能会反复屡次。

WebRTC使用RTCSessionDescription对象表示提议和应答。每一个浏览器都将生成一个该对象。

三、JavaScript提议/应答协商控制

本地浏览器只关注两个特定的调用：

// 将个人会话描述告知个人浏览器
pc.setLocalDescription(mySessionDescription)
...
// 将对等端的会话描述告知个人浏览器
pc.setRemoteDescription(yourSessionDescription)

生成提议、应答：

// 生成提议
pc.createOffer(gotOffer, didntGetOffer)

function gotOffer(aSessionDescription) {
    setLocalDescription(aSessionDescription)
    ...
    // 如今能够将会话描述（提议offer）发送给对等端，以便对等端
    // a)、将提议传递给setRemoteDescription
    // b)、调用createAnswer
}

// 生成应答
pc.createAnswer(gotAnswer, didntGetAnswer)

function gotAnswer(aSessionDescription) {
    setLocalDescription(aSessionDescription)
    ...
    // 如今将会话描述（应答answer）发送给对等端，以便对等端
    // a)、将应答传递给setRemoteDescription
}

四、测试demo说明

如下测试demo展现在两个浏览器中进行实时视频通话，源码地址：https://github.com/caiya/webrtc-p2p.git

---

数据通道

RTCDataChannel，数据通道是浏览器之间创建的非媒体的交互链接。即不传递媒体消息，绕过服务器直接传递数据。相比WebSocket、http消息，数据通道支持流量大、延迟低。

注意：
    单个对等链接中的多个数据通道底层共享一个流，因此只需一次offer、answer便可创建首个数据通道。以后再创建数据通道无需再次进行offer、answer交换。
    
    典型应用：游戏实时状态更新。

数据通道的使用

只有在建立完RTCPeerConnection实例以后才能建立数据通道，以下：

pc = new RTCPeerConnection()
dc = pc.createDataChannel('')

一端建立完数据通道后，另外一端只须要监听ondatachannel事件便可：

pc = new RTCPeerConnection()
pc.ondatachannel = function(e) {
    dc = e.channel
}

此时，两个对等端已经彼此创建数据通道，能够直接相互发送消息：

dc.send('i am a text string for sending')
dc.send(new Blob(['i am a blob object'], {type: 'text/plain'}))
dc.send(new arrayBuffer(32))    // 发送arrayBuffer
dc.onmessage = function(e) {
    console.log('收到消息：', e.data)
}

加入数据通道后的测试demo

项目源代码地址：https://github.com/caiya/webrtc-p2p-datachannel

部分截图：

---

做者 @晁州 2017 年 11月 27日