基于 WebRTC 技术的实时通讯服务开发实践

随着直播的发展，直播实时互动性变得日益重要。又拍云在 WebRTC 的基础上，凭借多年的开发经验，结合当下实际状况，开发 UPRTC 系统，解决了网络延时、并发量大、客户端解码能力差等问题。

WebRTC 的前世此生

什么是 WebRTC

2010年5月，Google 花费6820万美圆收购拥有编解码、回声消除等技术的 GIPS 公司。以后谷歌开源了 GIPS 的技术，与相关机构 IETF 和 W3C 制定行业标准，组成了现有的 WebRTC 项目。

WebRTC 全称 Web Real-Time Communication。它并非单一的协议， 包含了媒体、加密、传输层等在内的多个协议标准以及一套基于 JavaScript 的 API。经过简单易用的 JavaScript API ，在不安装任何插件的状况下，让浏览器拥有了 P2P音视频和数据分享的能力。

同时WebRTC 并非一个孤立的协议，它拥有灵活的信令，能够便捷的对接现有的SIP 和电话网络的系统。

WebRTC 具备的优点

成立UPRTC项目前，又拍云通过多重调研和考虑，选择了 WebRTC，主要有三个缘由：

1. WebRTC 是开源、 免专利费的项目， 大大节省了开发时间和成本；

2. WebRTC 由 Google 主导, 技术很是先进；

3. Safari 等浏览器以及其余终端逐渐增强对 WebRTC 技术的支持。

WebRTC 的核心组件

• 音视频引擎：OPUS、VP8 / VP九、H264
• 传输层协议：底层传输协议为 UDP
• 媒体协议：SRTP / SRTCP
• 数据协议：DTLS / SCTP
• P2P 内网穿透：STUN / TURN / ICE / Trickle ICE
• 信令与 SDP 协商：HTTP / WebSocket / SIP、 Offer Answer 模型

 

图1为 WebRTC 内部结构简化图，最底层是硬件设备，上面是音频捕获模块和视频捕获模块。

中间部分为音视频引擎。音频引擎负责音频采集和传输，具备降噪、回声消除等功能。视频引擎负责网络抖动优化，互联网传输编解码优化。

在音视频引擎之上是 一套 C++ API，在 C++ 的 API 之上是提供给浏览器的Javascript API。

△ 图1：WebRTC内部结构

 

图2是 WebRTC 涉及到的协议栈，WebRTC 核心的协议都是在右侧基于 UDP 基础上搭建起来的。

其中，ICE、STUN、TURN 用于内网穿透, 解决了获取与绑定外网映射地址，以及 keep alive 机制。

DTLS 用于对传输内容进行加密，能够看作是 UDP 版的 TLS。因为 WebRTC 对安全比较重视，这一层是必须的。

SRTP 与 SRTCP 是对媒体数据的封装与传输控制协议。

SCTP 是流控制传输协议，提供相似 TCP 的特性，SCTP 能够基于 UDP 上构建，在 WebRTC 里是在 DTLS 协议之上。

RTCPeerConnection 用来创建和维护端到端链接，并提供高效的音视频流传输。

RTCDataChannel 用来支持端到端的任意二进制数据传输。

△ 图2：WebRTC 协议栈

基于 WebRTC 的 UPRTC

为了使 WebRTC 协议更适用于实时互动直播，又拍云在 WebRTC 协议的基础上进行改造优化，搭建了又拍云 UPRTC 。支持多种应用场景，包括一对1、一对多和多对多等应用场景。

• 传统的 WebRTC 应用模式是 P2P 的， UPRTC 则是服务器中转模式。

由于又拍云拥有性能优异的 CDN 资源，将 WebRTC 改形成服务器中转模式以后，采用彻底分布式系统，部署到全国全部边缘节点，经过内部加速网络 UTUN 加速，将转发、并发压力转移到服务端，保证 UPRTC 终端能够承受更多路并发。

• 加入网络拥塞自适应控制，较强的弱网适应能力。

以移动设备从 WIFI 网络切换到 4G 网络为例，又拍云服务器能够察觉到带宽变化，统计丢包和延时，进行动态码率调整，保证在弱网环境下也能进行正常通话。

• 对底层开源组件优化改造，支持高并发业务场景。

又拍云设计了一套灵活高效的业务信令，用于敏感信令鉴权。

 

图3为 UPRTC 技术组成：

1. 媒体通道、数据通道，信令通道；
2. 数据加密模块；
3. 码率自适应控制模块；
4. 又拍云加速网络；
5. P2P打洞服务；
6. 房间应用业务；
7. 机器人（自动管理功能和互动功能）。

△ 图3：UPRTC技术组成

总结

虽然 WebRTC 源代码相对成熟，可是在实际应用中依旧须要解决如下问题：

1.音频处理过程当中消耗 CPU 太高；

2.音视频不一样步的BUG；

3.安卓端 WebRTC 源码对H.264支持并不全面，仅默认支持高通的芯片；

4.服务端架构过程当中须要加入码率自适应算法，动态控制总码率带宽在 2M 之内。

 

推荐参考文档：

W3C API 相关文档: https://github.com/w3c

IETF 协议相关文档: https://datatracker.ietf.org

 

相关阅读：

实时音视频互动系列（下）：基于 WebRTC 技术的实战解析

WebSocket+MSE——HTML5 直播技术解析

从Html5直播到互动直播，看直播协议的选择