WebRTC原理

WebRTC原理1

1.1什么是WebRTC

WebRTC(Neb Real-Time Communication)是Google于2010以6829万美元从Global IP Solutions公司购买，并于2011年将其开源，旨在1立一个互联网浏览器问的实时通信的平台，让NebRTC:技术成为H5标准之一。我们看官网(https://webrtc.org)的介绍

 

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

(1)紫色部分是Wb应用开发者API层

(2)蓝色实线部分是面向浏览器厂商的AP层

(3)蓝色虚线部分刘览器厂商可以自定义实现

1.3 WebRTC发展前景

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

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

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

声网htps:ww.agora.io/cn/

即构科技https:www.Zeqo.imM

1.5 WebRTC通话原理

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

1.媒体协商

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

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

2.BVP9做编码，发给A,A怎么去解码？

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

2.网络协商

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

先说结论：(1)获取外网P地址映射：(2)通过信令服务器(signal s8rver)交换"网络信息"

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

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

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

STUN

STUN(Session Traversal Utilities for NAT,NAT会话穿越应用程序)是一种网络协议，它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet喘端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC5389定义。在遇到上述情况的时候，我们可以建立一个STUN服务器，这个服务器做什么用的呢？主要是给无法在公网环境下的视频通话设备分配公网P用的。这样两台电脑就可以在公网P中进行通话。

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

TURN

TURN的全称为Traversal Using Relays around NAT,是STUN/RFC5389的一个拓展，主要添加了Relay1功能。如果终诺在NAT之后，那么在特定的情景下有可能使得终瑞无法和其对等端(Pee)进行直接的通信，这时就需要公网的服务器作为一个中继，对来往的数据进行转发。这个转发的协议就被定义为 TURN.

在上图的其础上，再架设几台TURN服务器：

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

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

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

打洞不成功 需要经过中继服务器转发数据包

但转发会十分消耗服务器网络资源

上图演示的是如果你没有P2P成功一对一视频通话情况下总共需要消耗的数据

即单向200kb x 4 =800kb

 

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

媒体协商sdp

网络协商candidate

 

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

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

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

信令服务器不只是交互媒体信息sdp和网络信息candidate,比如：

(1)    房间管理(2)人员进出房间

WebRTC APIs

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

2.RTCPeerConnection一RTCPeerConnection对像允许用户在两个浏览器之间直接通讯，你可以通过网络将捕获的音频和视频流实时发送到另一个 NebRTC端点。使用这些Api,你可以在本世机器和远程对等点之问创建连接。它提供了连接到远程对等点、维护和监视连接以及在不再需要连接时关闭连接的方法。

5.NAT知识补充

具体NAT打洞的知识在本课程不做进一步的讲解，这里提供些链接给大家做参考：

P2P技术详解()：NAT详解一详细原理、P2P简介https://www.cnblogs.com/mlgib/p/8243646.htm

P2P技术详解（二）：P2P中的NAT穿越（打洞）方案详解https://www.jianshu.com/p/9bfbcbee0abb

P2P技术详解（三）：P2P技术之STUN、TURN、ICE详解https:www.jianshu.com/p/258e7d8be2ba

详解P2P技术中的NAT穿透原理

https://www.jianshu.com/p/f71707892eb2

WebRTC原理2

我们知道，基于WEBRTC实现的多对多实时音视频互动通信就必须需要搭建信令服务器作为信令转发操作。那么我首先了解一下，什么是webrtc信令服务器？

在webrtc的规范中，其实是没有将信令服务这一块纳入到整个规范当中的。更多的是规范客户端所有的过程。为什么没有纳入到规范中，这是因为各个公司的业务模型都是不一样的。很难将每个公司的信令都并成一套规范。所以这样，还不如让他们自己去定义。只要是我必须的信息能交换，其他的业务，你自己去定义，这样就比较灵活，各个公司就更容易去接受，这其实是对webrtc整个的推广是比较有好处的。

信令服务器的作用：

 

如果没有信令服务器，各个webrtc之间肯定是不能通信的。

看图，这张图就清晰地表达了信令服务器在整个过程的作用，首先看蓝色部分，一个是发起端，一个是接收端，那么发起端和接收端之前要传输媒体数据的时候，他有两个信息必须要通过信令服务器的相互交换才能实现通信的，那两个信息是什么呢，第一个是媒体信息，这个媒体信息通过什么来表述呢，那就是SDP，这个SDP会在往后的分享会给大家作详细的介绍，可以简单地理解，我们双方需要通信，那么你的编解码器是什么，比如我现在进行视频传输，我的编解码是H264,那么对方也要告诉我你能不能支持h264，这个信息必须要传递的，另外你是否支持音频，是否支持视频，你的编码器是什么，这些信息都是通过SDP协议描述出来，然后通过信令服务器，首先就将这个SDP发送到服务器，然后服务器再中转，再中转到另一端，为什么要通过信令服务器进行中转，这是因为这时候双方还没有建立起连接，相互之间还不知道对方的存在。第二个要传递的是网络信息，大家都知道两个webrtc之间他们会尽可能地选择P2P进行传输，那么在他们进行连接之前，要怎样发现对方呢？那也是通过信令服务器，首先你要将你相关的网络信息传输到信令服务器。那这个信令服务器就帮你交互到另外一端，那这一端拿到你的信息之后，才知道，大家都是处于同一个局域网内，那就直接通过P2P传输就好了，那如果是不同一个局域网内，那么就需要使用P2P穿透，所以这个信令服务器最基础的作用就是一是媒体信息的交换，二是网络信息的交换，再有就是第三个就是我们的具体业务，比如说是加入房间，离开房间，禁言，或者给对方权限发言等，所以这就是整个信令服务器在WEBRTC通信中的作用。

为什么要使用http://socket.io，其中有几个优点

1. http://socket.io 是websocket超集，他身本就有websocket的功能，我们都知道在我们进行传输的时候，一般有两个协议，一个是TCP协议，一个是UDP协议，底层协议里面，一般来说UDP是用于流媒体的传输，音频，视频，还有文本，文字的聊天，但UDP的问题在于，他是不可靠的，他会丢包，这个对于音频和视频来说是没有问题的，当网络状况不好的时候，他可以丢包，我丢了一帧数据，他最多就是卡一下，但对于信令来说，他必须是需要可靠的，我们需要我们的数据发送到哪，从哪来的，这些都是需要可靠的传输协议作支撑，他要的是要么完全接收，要么就是完全不接收。所以对于信令来说是必须要使用tcp,而我们的websokcet是使用tcp的，所以http://socket.io也是使用tcp

2. http://socket.io有房间的概念，我们来想想，如果我们两个人之间进行通信，我们就必须先要进行一个房间里，我们要开会也好，什么也好，首先要聚集在一起，这是一个虚拟的逻辑概念。我们看过webrtc的demo可以知道，他实际上有三种服务器，第一种是room服务器，第二种就是我们的信令服务器，第三种就是流媒体中转服务器。而我们选用的http://socket.io他因为本身就具有房间这么一个概念，也具有信令转发这么一个功能，所以我们就无需再另外搭建room服务器和信令服务器，直接使用http://socket.io就可以了。

3. http://socket.io跨平台，跨终端，跨语言：我们可以用JS，也可以用JAVA，这样就使我们很方便地在各个终端中使用。

 

http://socket.io的工作原理

我们选择了Nodejs中的http://socket.io进行讲解。首先我们将npm的源换成淘宝的，这样下载的时候会快一点

npm install -g cnpm --registry=https://registry.npm.taobao.org

接下来我们使用cnpm的方式进行安装http://socket.io库

cnpm install socket.io

使用http://socket.io发送消息

实际上使用http://socket.io发送消息是的情况有很多，有10多种，但是我们必须要了解的大概也就是4，5种。我们来一个一个看

1. 给本次连接发消息

socket.emit(),把它理解成send就可以了，当我们的客户端发送一条消息给服务器端，服务器端收到消息之后，返一个callback，举个栗子，就是我要加个房间，然后服务器返回一个提示，你已加入成功。我收到这个提示之后，我就进行其他的操作，这一个过程都是异步的。

2. 给某个房间内所有人发消息。

这种情况相当于一个广播，给在房间内的所有人都发消息，包括我自己。还是以上边的栗子说说，我加入了房间，那么给房间内的所有人发一个消息说，这个人加入进来了。当然有些业务就不需要这样，你加入了就加入了，还有一个就是各个用户端都需要维护一个用户列表。那谁来谁走了，都要清楚，这个时候每个人都要收到这个消息，对于发送者来，我们就可以根据这个消息进行处理，比如音视频的处理。对于其他用户来说，收到了这个用户加入来进来的消息，我就更新一下我的用户列表。将这个用户添加我的用户列表里面去。

它用的是 http://io.in(room).emit()，这个IO，解释一下，代表整个这个节点的socket里面的所有用户都包含在内，in(room)就是代表节点某个房间内。也有一种写法是http://io.sockets.in，但这个sockets可写可不写

3. 除了本连接外，给某个房间内所有人发消息。

这种就是，给某个房间内除我自己之外的人发一个消息，比如全体静音，就是不让人说话，只允许我自己说话

使用：

socket.to(room).emit(),to(room)

就是给某个房间内除我自己之外的人发消息

4. 除本连接外，给所有人发消息

socket.broadcast.emit()

跟第三种情况很相似，但，这个是给本人外，这个节点的所有房间发消息。

http://socket.IO客户端处理消息

当我们客户端收到的处理信息之后，怎样处理。

1. 发送action命令

server: socket.emit(‘action’);  // 当服务器发送了个action

client: socket.on(‘action’,function(){}); //  我们的客户端就需要监听这个动作。

2. 发送action命令，还在data数据

server : socket.emit(‘action’,data);

client: socket.on(‘action’,function(data){…});

3. 发送了action命令，还有两个数据

server: socket.emit(action,arg1,arg2);

client: socket.on(‘action’,function(arg1,arg2){…});

4. 发送一个action命令，在emit方法中包含回调函数

server: socket.emit(‘action’,data,function(arg1,arg2){…});

client: socket.on(‘action’,function(data,fn){fn(‘a’,’b’);});

至止，关于使用http://socket.io搭建简单的信令服务器的教程到这里，下一次本光头将介绍实战中如何应用http://socket.io。

WebRTC原理3

说穿透之前，我们首先需要明白关于WEBRTC的一些概念，WEBRTC它是一个支持在browser实现实时音视频通信的一组技术框架，它是一组标准协议，它为开发者，用户提供了视频通信的核心技术，包括采集，编解码，网络传输，渲染等功能，并且是跨平台的。

webrtc是基于P2P的，即点对点通信，与传统的方式有什么不同呢？

(1) 传统的方式以服务器为中介

(2) P2P的连接在数据通道形成的时候，中间是不经过服务器端的

采用P2P的优点是可以减轻服务器压力，但是真的不需要服务器端吗？

这其实是一个走偏了的想法，webrtc仅仅是不需要服务器中转数据。但有两件事情则必须要走服务器端的。

(1) 浏览器之间交换信令

(2) NAT穿透和防火墙

关于信令交换，并不在本篇的重点介绍当中，简单说一下就是A和B需要建立P2P连接，这时候则需要中间服务器（信令服务器）作协调，也需要中间服务器告诉另一端P2P连接断开状态。这些用来控制连接的状态的数据一般称之为信令，而这个与服务端连接的通道，就是信令通道。

关于NAT穿透，则是本章的重点内容，也就是像老鼠一样打洞。NAT是一组网络地址转换的协议，NAT的技术特点会引发外网地址的访问，这时修候就得采用NAT穿透了。

NAT技术（Network Address Translation，网络地址转换）是一种把内部网络（简称为内网）私有IP地址转换为外部网络（简称为外网）公共IP地址的技术，它使得一定范围内的多台主机只利用一个公共IP地址连接到外网，可以在很大程度上缓解了公网IP地址紧缺的问题。

有哪些不需要用NAT穿透的?

(1) 位于同一个私网内，可以直接通过内网IP地址通信

(2) 通信双方都有独立的公网IP地址，可以直接通过公网IP地址通信。

在我们的现实的应用环境中，大多数设备都是位于NAT之后，比如连着同一个基站的移动设备，同一个小区的宽带用户等，NAT的存在使得设备间不能直接进行点对点的通信。这时候我们就需要用到NAT穿透技术，这是为了解决使用了NAT后的私有网络中设备间建立连接的问题，常见的NAT穿透技术方法主要有：

应用层网关；

中间件技术；

打洞技术(Hole Punching)；

Relay(服务器中转)技术。

我们在WEBRTC开发的过程中一般是使用ICE进行NAT穿透。

ICE是一组穿透方法而不是协议，它融合了STUN和TURN，ICE使得两个NAT后设备通信更加便捷，ICE使用STUN进行打洞，若失败，则使用TURN进行中转。

STUN:NAT会话穿透应用程序，它是基于UDP的解决方案，属于打洞技术 ，STUN是一种CS协议，也是一种Request/Response的协议，默认端口号为3478，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的公网端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。

四种主要NAT类型中有三种是可以使用STUN进行穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT，对称型NAT则不能使用。

TURN：通过Relay方式穿透NAT，是一种数据传输协议，它是允许通过TCP或UDP方式进行穿透，它也是一个CS协议，与STUN类似 ，都是通过取得应用层中的公网地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port"，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将数据传送至peer，再由peer转传到另一方的TURN client。

TURN主要用在使用STUN无法穿透的场景下，例如前面说到的对称型NAT，只能通过TURN server进行数据中转。

我们假设jerry和tom要进行通信，这两个位于NAT之后，公网部署了STUN与TURN服务器。

首先客户端要收集候选地址(candidate),这数据结构由IP地址和端口号组成 ，收集的candidate要与对方的candidate组成成对的candidate pair,进行连通性检查。主要有三种：

(1) host candidate:从本地网卡获取的地址

(2) server reflexive candidate (srflx): stun server观察的该client的地址

(3) relay reflexive candidate(relay): turn server为该client分配的中继地址。

client通过向stun服务器发送stun数据包,stun服务器做出回应告知其在数据包中监测到的IP地址以及端口。

连通性检查

收集candidate后把通过信令offer与answer方式双方交换candidate，进行candidate两两配对，然后ICE连通性检查。这个连通性检查按一定规则的。

本地的candidate与远端candidate构成的每一对都有一定的优先级，按优先级排序进行连通性检查。

数据传输

最后从有效的candidate组合中选择优先级最高的作为传输地址，用于数据传输。

Trickle ICE

在WebRTC中使用ICE框架进行P2P通信。前面说到ICE中第一步是收集candidate，需要遍历STUN以及TURN服务器，这一步需要耗费很多时间，导致双方建立通信时间很慢。为了解决这一问题，WebRTC引入了Trickle ICE，这样candidate收集以及连通性检查可以同时进行，加快双方建立通信的速度。