1、WebRTC入门
1、以下内容来自 零声学院 ,把PDF放到博客上面来,方便以后查看
1.1 什么是WebRTC
WebRTC(Web Real-Time Communication)是 Google于 2010 以 6829 万美元从 Global IP Solutions 公司购买,并于2011 年将其开源,旨在建立一个互联网浏览器间的实时通信的平台,让 WebRTC技术成为 H5标准之一。我们看 官网 的介绍
从官网上的描述我们可以知道,WebRTC是一个免费的开放项目,它通过简单的API为浏览器和移动应用程序提供实时通信(RTC)功能。
1.2 WebRTC框架
上图的框架对于不同的开发人员关注点不同:
( 1 )紫色部分是Web应用开发者API层
( 2 )蓝色实线部分是面向浏览器厂商的API层
( 3 )蓝色虚线部分浏览器厂商可以自定义实现
特别是图中的 PeerConnection 为 Web 开发人员提供了一个抽象,从复杂的内部结构中抽象出来。我们只需要关注PeerConnection这个对象即可以开发音视频通话应用内。
WebRTC架构组件介绍
-
Your Web App
Web开发者开发的程序,Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。 -
Web API
面向第三方开发者的WebRTC标准API(Javascript),使开发者能够容易地开发出类似于网络视频聊天的web应用,
最新的标准化进程可以查看这里。 -
WebRTC Native C++ API
本地C++ API层,使浏览器厂商容易实现WebRTC标准的Web API,抽象地对数字信号过程进行处理。 -
Transport / Session
传输/会话层
会话层组件采用了libjingle库的部分组件实现,无须使用xmpp/jingle协议 -
VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架。
PS:VoiceEngine是WebRTC极具价值的技术之一,是Google收购GIPS公司后开源的。在VoIP上,技术业界领先。
Opus:支持从6 kbit/s到510 kbit/s的恒定和可变比特率编码,帧大小从2.5 ms到60 ms,各种采样率从8 kHz(4 kHz带宽)到48 kHz(20 kHz带宽,可复制人类听觉系统的整个听力范围)。由IETF RFC 6176定义。NetEQ模块是Webrtc语音引擎中的核心模块 ,一种动态抖动缓冲和错误隐藏算法,用于隐藏网络抖动和数据包丢失的负面影响。保持尽可能低的延迟,同时保持最高的语音质量。 -
VideoEngine
WebRTC视频处理引擎VideoEngine是包含一系列视频处理的整体框架,从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。
VP8 视频图像编解码器,是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景,因为它主要是针对低延时而设计的编解码器。
1.2.1 WebRTC发展前景
WebRTC虽然冠以“web”之名,但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备(Android或iOS)还是IoT设备,只要IP连接可到达且符合WebRTC规范就可以互通。
这一点释放了大量智能终端(或运行在智能终端上的app)的实时通信能力,打开了许多对于实时交互性要求较高的应用场景的想象空间,譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。
全球领先的技术研究和咨询公司Technavio最近发布了题为“全球网络实时通讯(WebRTC)市场,2017-2021”的报告。报告显示,2017-2021年期间,全球网络实时通信(WebRTC)市场将以34.37%的年均复合增长率增长,增长十分迅速。增长主要来自北美、欧洲及亚太地区。
1.2.2 国内方案厂商
声网、即构科技、环信、融云等公司都在基于WebRTC二次开发自己的音视频通话方案。
- 声网 https://www.agora.io/cn/
- 即构科技 https://www.zego.im/
1.2.3 WebRTC通话原理
首先思考的问题:两个不同网络环境的(具备摄像头/麦克风多媒体设备的)浏览器,要实现点对点 的实时音视频对话,难点在哪里?
- 媒体协商
彼此要了解对方支持的媒体格式
比如:Peer-A端可支持VP8、H264多种编码格式,而Peer-B端支持VP9、H264,要保证二端都正确的编解码,最简单的办法就是取它们的交集H264
注:有一个专门的协议 ,称为Session Description Protocol (SDP),可用于描述上述这类信息,在WebRTC中,参与
视频通讯的双方必须先交换SDP信息,这样双方才能知根知底,而交换SDP的过程,也称为"媒体协商"。
- 网络协商
彼此要了解对方的网络情况,这样才有可能找到一条相互通讯的链路
先说结论:(1)获取外网IP地址映射;( 2 )通过信令服务器(signal server)交换"网络信息"
理想的网络情况是每个浏览器的电脑都是私有公网IP,可以直接进行点对点连接。
实际情况是:我们的电脑和电脑之前或大或小都是在某个局域网中,需要NAT(Network Address Translation,网络地址转换),显示情况如下图:
在解决WebRTC使用过程中的上述问题的时候,我们需要用到STUN和TURN。
1.2.4 STUN
STUN(Session Traversal Utilities for NAT,NAT会话穿越应用程序)是一种网络协议,它允许位于NAT(或多重NAT)后的客户端找出自己的公网地址,查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。
在遇到上述情况的时候,我们可以建立一个STUN服务器,这个服务器做什么用的呢?主要是给无法在公网环境下的视频通话设备分配公网IP用的。这样两台电脑就可以在公网IP中进行通话。
使用一句话说明STUN做的事情就是:告诉我你的公网IP地址+端口是什么。搭建STUN服务器很简单,媒体流传输是按照P2P的方式。
那么问题来了,STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的,P2P在传输媒体流时,使用的本地带宽,在多人视频通话的过程中,通话质量的好坏往往需要根据使用者本地的带宽确定。那么怎么办?TURN可以很好的解决这个问题。
1.2.5 TURN
TURN的全称为Traversal Using Relays around NAT,是STUN/RFC5389的一个拓展,主要添加了Relay功能。如果终端在NAT之后, 那么在特定的情景下,有可能使得终端无法和其对等端(peer)进行直接的通信,这时就需要公网的服务器作为一个中继, 对来往的数据进行转发。这个转发的协议就被定义为TURN。
在上图的基础上,再架设几台TURN服务器:
在STUN分配公网IP失败后,可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承担,在多人视频聊天的时候,本地带宽压力较小,并且,根据Google的说明,TURN协议可以使用在所有的环境中。(单向数据200kbps 一对一通话)
以上是WebRTC中经常用到的 2 个协议,STUN和TURN服务器我们使用coturn开源项目来搭建。
补充:ICE跟STUN和TURN不一样,ICE不是一种协议,而是一个框架(Framework),它整合了STUN和TURN。coturn开源项目集成了STUN和TURN的功能。
1.2.6 STUN&TURN 概括
STUN(Session Traversal Utilities for NAT)和 TURN(Traversal Using Relays around NAT)是两种用于解决网络地址转换(NAT)环境下通信问题的协议。
一、STUN
-
作用:
- STUN 的主要目的是帮助位于 NAT 后面的客户端发现自己的公网 IP 地址和端口号。这对于建立直接的点对点通信非常重要,尤其是在使用实时通信协议如 WebRTC 时。
- 通过向 STUN 服务器发送请求,客户端可以获取到自己在公网中的可见地址信息,然后将这些信息分享给通信的另一方,以便尝试直接建立连接。
-
工作原理:
- 客户端向 STUN 服务器发送请求消息,其中包含一些特定的信息,如客户端的内网 IP 地址和端口号等。
- STUN 服务器收到请求后,会回复一个响应消息,其中包含客户端的公网 IP 地址和端口号,以及一些其他的属性信息,如 NAT 的类型等。
- 客户端根据收到的响应消息,确定自己的公网地址信息,并可以尝试与其他客户端建立直接连接。
-
应用场景:
- 在 WebRTC 应用中,STUN 服务器通常被用于帮助客户端发现自己的公网地址,以便进行点对点通信。如果两个客户端位于不同的 NAT 后面,但它们的 NAT 类型允许直接建立连接,那么就可以通过 STUN 发现的公网地址进行通信,无需经过中间服务器转发。
- 对于一些简单的 NAT 环境,STUN 可能足以解决通信问题。但在某些情况下,如 NAT 类型限制或网络限制,仅靠 STUN 可能无法实现直接通信。
二、TURN
-
作用:
- 当直接的点对点连接无法建立时,TURN 服务器可以作为中继,转发通信双方的数据。这在 NAT 环境非常严格或者存在防火墙等限制的情况下非常有用。
- TURN 服务器接收来自一个客户端的数据,然后将其转发给另一个客户端,确保通信的持续进行。
-
工作原理:
- 客户端首先尝试通过 STUN 发现自己的公网地址并尝试直接建立连接。如果直接连接失败,客户端可以向 TURN 服务器申请中继服务。
- 客户端将数据发