初识 WebRTC

 

 

在之前的文章中，我们描述了目前直播常用的协议--RTMP。并也说明了为什么目前主流直播平台没有采用RTP和基于它的WebRTC。但是我们也要意识到WebRTC在实时音视频上的广泛应用，比如视屏会议，屏幕共享等场景。并且目前基于WebRTC进行深度定制的直播平台也越来越多，所以我们也来聊一聊WebRTC。

 

什么是WebRTC

 

WebRTC是Web Real-Time Communication，即网页实时通信的缩写，是RTC协议的一种Web实现。项目由Google开源，并和IETF和W3C制定了行业标准，目前已成为下一代视频通话的标准。

 

浏览器本身不支持相互之间之间直接建立通信，一般都是通过服务器进行中转。这样的问题在于双方的铜线需要通过两段信道，使得通信的效率受到了更多的限制。所以如何建立浏览器之间的点对点传输，一直困扰着开发者，而这就是WebRTC产生的原因。

 

WebRTC允许网络应用在不借助中间媒介的情况下，建立点对点的连接，从而实现音视频流和其他数据的传输。WebRTC这个项目使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。实现方式是通过一系列的信令，建立浏览器之间的信道。这个信道可以发送任何数据而无需经过服务器。

 

当然WebRTC的内容不仅仅包含上面这些，还包含媒体、加密、传输等在内的多项标准和协议。通过提供的原生JavaScript API，在不依赖其他插件的情况下，拥有P2P音视频和数据分享的能力。

 

当然上面所说的不借助中间媒介是指点对点通信时不需要第三方进行转发。而如果需要依赖WebRTC框架，仍需要另外的服务器来传输一些其他的信息，比如双方的基本信息，在没建立连接之前获得对方的IP，协议版本等。

 

WebRTC的设计

 

WebRTC的架构图我们可以在官网（地址见文末）中查到，如下图：

我们可以看到整个架构主要分为几个部分：

 

• Web API： 提供给Web开发者的API层。供开发者开发基于视频和音频等的实时通信应用。标准有W3C联盟指定
• WebRTC C++ API：提供给浏览器厂商的API层，供浏览器厂商实现WebRTC标准的Web API，其中主要是抽象的对数字信号过程进行处理。
• 会话层：一个抽象的会话层，提供会话建立和管理功能，该层协议由应用开发者自定义实现。
• 传输层：主要包含两个部分，一个RTP协议栈，另一个是STUN/TURN/ICE层，主要通过STUN和ICE组件来建立不同类型网络间的连接。
• Engine：音视频引擎，包含一系列多媒体处理的框架，包含从视频采集卡到网络传输等整个解决方案。音频引擎负责音频采集和传输，具有降噪、回声消除等功能。视频引擎负责网络抖动优化，互联网传输编解码优化。这个是WebRTC中极具价值的技术之一，是由Google收购GIPS公司开源的，在整个VoIP界，都算是技术领先的。
• 浏览器设备厂商自行实现的硬件接口：包含音频捕捉模块和视频捕捉模块。以及网络IO接口。

 

基于上面的理解，我们将架构进行进一步简化来梳理WebRTC的流程：

整个流程是：最底层是硬件设备，上面是音频捕获模块和视频捕获模块。中间部分为音视频引擎。在音视频引擎之上是 一套 C++ API，在 C++ 的 API 之上是提供给浏览器的Javascript API。这个就是整个WebRTC的主要流程。

 

WebRTC的协议栈

在 为什么直播系统不用RTP协议 中，我们简单说了主流音视频传输协议在网络协议中的位置： 我们在这张图可以看到WebRTC主要是基于RTP以及它的伴生协议RTCP。这里我们看一下WebRTC主要涉及到的网络协议栈：

这里分为两部分，一部分是左半边的WebRTC框架中依赖的信令服务器使用的协议，这个我们之后再讲。这里我们主要关注右半边WebRTC核心的协议栈，包含以下几个部分：

 

• UDP基础：WebRTC传输层协议主要依靠UDP，这个是关键，和其他基于TCP协议的传输协议相比，传输效率更高，成本也更低。这里WebRTC使用的UDP拓展协议RTP和它的伴生协议RTCP。
• ICE，STUN，TURN：也是传输层协议，主要是用于内网穿透，解决获取与绑定外网映射地址以及keep alive机制。
• DTLS：会话层协议，主要是用于保证数据传输的安全。
• SCTP和SRTP：用于在UDP上提供不同流的多路复用、拥塞和流量控制，以及部分可靠的交付和其他服务。

 

WebRTC的现状

 

WebRTC从发展初期，因为其强大的功能和先进的设计理念。得到很多浏览器厂商的支持，即使是苹果也在2017年宣布Safari 11支持WebRTC。所以目前我们从下图可以看到目前主流的浏览器基本上都支持WebRTC。

 

WebRTC的使用范围

 

通过上面的了解，很多人都认为WebRTC就应该在浏览器端使用，但是现实情况反而是相反的，在浏览器端开发是最简单的，因为提供了非常简单的JavaScript API。但是却受到JavaScript和浏览器的限制，而且如果应用场景足够丰富，那么对于浏览器的兼容性也需要考虑在内。同时浏览器在长时间直播或者会议上可能会有问题，并且功能也较弱，比如分辨率控制、多路语音混音都做不了。当然还有其他问题，比如Chrome同时给6个客户端发视频流就很消耗资源了，所以你如果有超过10个用户收看的话，Chrome很容易崩溃。 那么WebRTC的最佳使用范围是哪里呢？我们从上面架构图可以看到WebRTC提供了两层API，底层是C++写的Native库，上层是JavaScript封装。所以我们完全可以忽略上层的JavaScript限制，直接使用底层的Native库，这样我们可以开发跨平台的APP，并且可以拥有更高的权限和能力。而且Google在开发WebRTC时已考虑用在app，底层C++库的API已做得很完善了。所以对于WebRTC的最佳使用是基于WebRTC Native库来实现各种平台的APP，以达到最佳的体检**。

 

总结

 

今天我们主要简单了解一下WebRTC，包括WebRTC是什么，他的设计理念以及目前的现状。通过这些，我们可以了解现在音视频和直播领域依赖的技术背后究竟是什么。在以后的文章中，我们会继续深入了解WebRTC系统的设计，和其他组件的运用。以及其他相关的知识。

 

 

 

 

 

 

WebRTC架构：https://webrtc.github.io/webrtc-org/architecture/

 

 

 

 

 

 

版权声明: 本文为 InfoQ 作者【soolaugust】的原创文章。