WebRTC 从零学习笔记①-超详细版

什么是WebRTC

        想要直接用浏览器打电话给另外一个浏览器？WebRTC正是你所需要的，并且可以让你完成以前做不到的很多事情。比如说浏览器内的音视频通话，文件传输，屏幕共享，或者服务器低依赖聊天。WebRTC有着无尽的可能性，并且孕育出了全新的使用案例，比如p2p-cdns greta.io或者peer5，以及像TokBox和agora.io这样的公司。

        webRTC是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流/音频流或者其他任意数据的传输。

        WebRTC是一个免费的开放项目，它通过简单的API为浏览器和移动应用程序提供实时通信(RTC)功能。

        WebRTC（网页实时通信技术）是一系列为了建立端到端文本或者随机数据的规范，标准，API和概念的统称。这些对等端通常是由两个浏览器组成，但是WebRTC也可以被用于在客户端和服务器之间建立通信连接，或者在任何其他可以实施WebRTC标准的设备之间进行通信建立。

WebRTC发展前景

        WebRTC虽然冠以"web"之名，但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备(Android或IOS）还是loT设备，只要IP连接可到达且符合WebRTC规范就可以互通。这一点释放了大量智能接冬端(或运行在智能冬端上的app）的实时通信能力，打开了许多对于实时交互性要求较高的应用场录的想象空间，譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。
 

        全球领先的技术研究和咨询公司Technavio最近发布了题为"全球网络实时通讯(WebRTC)市场，2017-2021"的报告。报告显示，2017-2021年期间，全球网络实时通信(WebRTC)市场将以34.37%的年均复合增长率增长，增长十分迅速。增长主要来白北美、欧洲及亚太地区。

国内方案厂商

声网、即构科技、环信、融云等公司都在基于WebRTC二次开发自己的音视频通话方案。

RTMP（不考虑实时交互，不考虑低时延）：可以多及拓展服务器，只要cdn够宽，就可以实现上万人直播

WebRTC（考虑实时互动）--abc可以互动交流

WebRTC优缺点

优点

• 跨平台(Web、Windows、MacOS、Linux、iOS、Android)
• 免费、免插件、免安装，得到主流浏览器支持
• 强大的打洞能力，包含 STUN、ICE、TURN 的关键 NAT 和防火墙穿透技术

缺点

• 缺乏服务器方案的设计和部署
• 音频的设备适配问题

WebRTC框架

上图的框架对于不同的开发人员关注点不同:

1. 紫色部分是Web应用开发者API层
2. 蓝色实线部分是面向浏览器厂商的API层
3. 蓝色虚线部分浏览照厂商可以自定义实现

特别是图中的PeerConnection为Web 开发人员提供了一个抽象类，从复杂的内部结构中抽象出来。我们只涨要关注PeerConnection这个对象即可以开发音视频通话应用内。

WebRTC架构组件介绍

Your Web Appl

Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

Web API

面向第三方开发者的WebRTC标准APl (Javascript )使开发者能够容易地开发出类似于网络视频聊天的web应用，最新的标佳化进程可以查看这里。

WebRTC Native C++ API

本地C++API层，使浏览器厂商容易实现WebRTC标准的Web APl，抽象地对数字信号过程进行处理。

Transport / Session（传输/会话层）

会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议

voiceEngine 语音引擎

音频引学是包含—系列音频多媒体处理的框架。

PS: VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VolP上，技术业界领

Opus:支持从6 kbitis到510 kbitls的恒定和可变比特率编码，帧大小从2.5 ms到60 ms，各种采样率从8 kHz 到48 kHz (20 kHz带宽，可复制人类听觉系统的整个听力范围)。由IETF RFC6176定义。

NetEQ模块是Webrtc语音引擎中的核心模块，一种动态抖动缓冲和错误隐藏算法，用于隐藏网络抖动和数据包 ,丢失的负面影响。保持尽可能低的延迟时保持最高的语音质呈。

VideoEngine（WebRTC视频处理引擎）

VideoEngine是包含一系列视频处理的整休框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

VP8（视频图像编解码器）

是WebRTC视频引擎的默认的编解码器

VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。

应用场景

• 远程访问主机
• 在线教育（直播连麦，屏幕录制，共享远程桌面）
• 点对点通讯：WebRTC 支持浏览器之间进行音视频通话，例如语音通话、视频通话等；
• 电话会议：WebRTC 可以支持多人音视频会议，例如腾讯会议、钉钉会议等；
• 屏幕共享：WebRTC 不仅可以传输音视频流，还可以用于实时共享屏幕；
• 直播：WebRTC 可以用于构建实时直播，用户可以通过浏览器观看直播内容。

WebRTC通话原理

首先思考的问题:两个不同网络环境的（具备摄像头/麦克风多媒体设备的)浏览器，要实现点对点的实时音频视频对话，难点在哪里?

1、媒体协商 sdp

彼此要了解对方支持的媒体格式

找到双方共同支持的媒体能力，如双方各自支持的编解码器，音频的参数采样率，采样大小，声道数、视频的参数分辨率，帧率等等。

1. A端视频采用VP8做编码，然后发送给B端,B端怎么去解码?

2. B用VP9做编码，发给A,A怎么去解码？

比如: Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证两端都正确的编解码,最简单的办法就是取它们的交集H264
注:有一个专门的协议，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

媒体协商过程

一对一通信中，发起方发送的 SDP 称为Offer(提议)，接收方发送的 SDP 称为Answer(应答)。

每端保持两个描述：描述本身的本地描述LocalDescription，描述呼叫的远端的远程描述RemoteDescription。

当通信双方 RTCPeerConnection 对象创建完成后，就可以进行媒体协商了，大致过程如下：

1. 发起方创建 Offer 类型的 SDP，保存为本地描述后再通过信令服务器发送到对端；
2. 接收方接收到 Offer 类型的 SDP，将 Offer 保存为远程描述；
3. 接收方创建 Answer 类型的 SDP，保存为本地描述，再通过信令服务器发送到发起方，此时接收方已知道连接双方的配置；
4. 发起方接收到 Answer 类型的 SDP 后保存到远程描述，此时发起方也已知道连接双方的配置；
5. 整个媒体协商过程处理完毕。

代码实现媒体协商过程

通过 MDN 先了解下我们需要用到的 API：

• createOffer用于创建 Offer；
• createAnswer用于创建 Answer；
• setLocalDescription用于设置本地 SDP 信息；
• setRemoteDescription用于设置远端的 SDP 信息。

2、网络协商 candidate

彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路

1. 获取外网IP地址映射;
2. 通过信令服务器(signal server）交换"网络信息"

理想的网络情况是每个浏览器的电脑都是私有IP，可以直接进行点对点连接。
 

WebRTC 音视频通信基本流程

1. 一方发起调用 getUserMedia 打开本地摄像头
2. 媒体协商（信令交换）
3. 建立通信

实际情况是:我们的电脑和电脑之前或大或小都是在某个局域网中，需要NAT(Network Address Translation ,网络地址转换)，显示情况如下图:

A端10.1.1.2不能与B端192.168.1.1不能直接连接（局域网IP）

理想状态：得到两个外网ip ：113.246.153.46的60端口与113.246.115.54的60端口是否可以相通，如果可以相通，就可以通过端口映射实现A与B的点对点传输

在解决WebRTC使用过程中的上述问题的时候，我们需要用到STUN和TURN。
 

STUN

        STUN(Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。

        在遇到上述情况的时候，我们可以建立一个STUN服务器，这个服务器做什么用的呢?主要是给无法在公网环境下的视频通话设备分配公网IP用的。这样两台电脑就可以在公网IP中进行通话。

        通过STUN获取外网的IP+端口的映射

        使用一句话说明STUN做的事情就是:告诉我你的公网IP地址+端口是什么。搭建STUN服务器很简单，媒体流传输是按照P2P的方式。
        那么问题来了，STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的，P2P在传输媒体流时，使用的本地带宽，在多人视频通话的过程中，通话质量的好坏往往需要根据使用者本地的带宽确定。那么怎么办?TURN可以很好的解决这个问题。

        对称型NAT的路由器只接受来自之前已经与内部节点通信过的外部节点的数据包。如果一个新的外部节点尝试向内部节点发送数据包，即使它知道了内部节点的公网IP和端口，也无法成功，因为路由器会拒绝这个新的外部节点的数据包。

        对于对称型NAT，内部设备可以主动向外部发送数据包，然后外部设备就可以回复这个数据包。但是，如果一个外部设备试图主动向NAT内部的设备发送数据包，而之前没有对应的映射条目（也就是说，内部设备并没有首先向这个外部设备发送过数据包），那么NAT设备就会拒绝这个数据包，因此无法建立通信。这就是为什么对称型NAT需要使用像TURN这样的技术来帮助实现NAT穿透，因为TURN可以让两个内部设备先与TURN通信，从而让TURN能够作为中转打通对称NAT的通信。

TURN

        TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay（中继）功能。如果终端在NAT之后，那么在特定的情景下有可能使得终端无法和其对等端(peer)进行直接的通信（打洞失败），这时就需要公网的服务器作为一个中继，对来往的数据进行转发。这个转发的协议就被定义为TURN。
在上图的基础上，再架设几台TURN服务器:

        如果上述外网映射通信不通的话，这时候需要公网作为一个中继，对来网的数据转发，这个转发的协议被定义为TURN

服务网络（200kbps单向通信一对一带宽为良好的通信）

        在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承担，在多人视频聊天的时候，本地带宽压力较小，并且，根据Google的说明，TURN协议可以使用在所有的环境中。（单项数据200kbps一对一通话）

 以上是WebRTC中经常用到的2个协议，STUN和TURN服务器使用coturn开源项目来搭建。

补充:ICE跟STUN和TURN不一样，ICE不是一种协议，而是一个框架(Framework)，它整合了STUN和TURNcoturn开源项目集成了STUN和TURN的功能。

在WebRTC中用来描述信息的术语叫candidate。

媒体协商+网络协商数据的交换通道

从上面1、2点我们知道了两个客户端协商媒体信息和网络信息，那怎么去交换?是不是需要一个中间商去做交换?所以我们太要一个信令服务器(Signal server）转发彼此的媒体信息和网络信息.。

如上图，我们在基于WebRTCAPI开发应用(APP)时，可以将彼此的APP连接到信令服务器(Signal Server，一般搭建在公网，或者两端都可以访问到的局域网)，借助信令服务器，就可以实现上面提到的SDP媒体信息及Candidate网络信息交换。

信令服务器不只是交互媒体信息sdp和网络信息candldate，比如:

1. 房间管理：支持不同的人的通话
2. 人员进出（属于房间管理的一部分）

WebRTC APIs

1. MediaStream—MediaStream用来表示一个媒体数据流(通过getUJsenMediae接口获取)，允许你访问输入设备，如麦克风和Web摄像机该API允许从其中任意一个获取媒体流。

   用于表示每个媒体输入/输出设备的信息，包含以下 4 个属性：

   1. deviceId: 设备的唯一标识；
   2. groupId: 如果两个设备属于同一物理设备，则它们具有相同的组标识符 - 例如同时具有内置摄像头和麦克风的显示器；
   3. label: 返回描述该设备的字符串，即设备名称（例如“外部 USB 网络摄像头”）；
   4. kind: 设备种类，可用于识别出是音频设备还是视频设备，是输入设备还是输出设备：audioinput/audiooutput/videoinput

   可以在浏览器控制台直接输入navigator.mediaDevices.enumerateDevices()

2. RTCPeerConnection—RTCPeerConnection  对象允许用户在两个浏览器之间直接通讯，你可以通过网络将捕获的音频和视频流实时发送到另一个WebRTC端点。使用这些Api，你可以在本地机器和远程对等点之问创建连接。它提供了连按到远程对等点、维护和监视连按以及在不再需要连接时关闭连接的方法。
3. pc.createOffer：创建 offer 方法，方法会返回 SDP Offer 信息
4. pc.setLocalDescription：设置本地 SDP 描述信息
5.  pc.setRemoteDescription：设置远端的 SDP 描述信息，即对方发过来的 SDP 信息
6. pc.createAnswer：远端创建应答 Answer 方法，方法会返回 SDP Offer 信息
7. pc.ontrack：设置完远端 SDP 描述信息后会触发该方法，接收对方的媒体流
8. pc.onicecandidate：设置完本地 SDP 描述信息后会触发该方法，打开一个连接，开始运转媒体流
9. pc.addIceCandidate：连接添加对方的网络信息
10. pc.setLocalDescription：将 localDescription 设置为 offer，localDescription 即为我们需要发送给应答方的 sdp，此描述指定连接本地端的属性，包括媒体格式
11. pc.setRemoteDescription：改变与连接相关的描述，该描述主要是描述有些关于连接的属性，例如对端使用的解码器