WebRTC 服务端实时音视频概述

本文对 WebRTC 使用过程中涉及到的四种服务器:：信令服务器、NAT 穿越服务器，媒体服务器和网关服务器做入门级的介绍。

背景介绍

目前在线直播应用上课的产品中, 实时视频流功能，增加视频流，对提高老师学生的上课体验，帮助老师更好的掌控课堂能起到一定的帮助；但另一方面对服务的稳定性，抗弱网环境的能力等又带来了挑战。

实现一对一 & 一对多视频流的一种方式是使用 WebRTC, 所以我想提前调研一下如果使用 WebRTC 实现 P2P 的视频, 服务端要做哪些工作。

WebRTC 为什么需要服务端?

P2P 和信令

通常, 介绍 WebRTC 时会强调它是一个 Peer to Peer 的实时传输框架, 能在浏览器和浏览器, 或浏览器和移动端之间点对点地传输流媒体数据.

它的核心架构如下图所示:

从上图可以看出, WebRTC 的核心功能是在客户端之间建立三种点对点的实时数据通道, 包括:

视频通道(video channel)
音频通道(audio channel)
自定义数据通道(data channel)

但在建立 P2P Channel 之前, 客户端需要用某种手段来交换各自的信息, 这一信息叫做信令(signaling), 信令包括客户端的 ip, 端口号, 支持的音视频编解码格式等内容.

WebRTC 规定了信令的格式和内容, 但没有规定客户端用何种手段来交换信令. 理论上讲, 可以用邮件, 微博等任意方式交换信令. 例如, 在 WebRTC 官方 Demo WebRTC samples Munge SDP 中, 由于 P2P 通道的双方在同一个程序中, 它们可以直接通过调用对方的方法, 来交换信令.

但是实际上, 任何一个不是 Demo 的 WebRTC 系统, 都要通过一个独立的信令服务来交换信令的. 所以, WebRTC 不完全是 Peer to Peer, 它最少需要一个信令服务器的支持.

实际生产环境中的 WebRTC 服务

实际生产环境中的 WebRTC 更为复杂, 涉及到多种服务器, 下图来自 w3c 的 WebRTC 规范文档 , 介绍一次 “简单的” WebRTC P2P 通道建立流程, 图中用红圈圈起来的, 都是服务器:

实际生产环境中, 我们主要会遇到以下四种服务器:

信令 (Signaling) 服务器 (一定需要)
NAT 穿越服务器 (生产环境需要)
媒体服务器 (视 App 情况而定)
网关服务器 (视 App 情况而定)

信令服务器

什么是信令?

信令 (signaling) 这一概念来自于通信系统. 在通信网络中, 传输着各种信号, 其中一部分是我们需要的 (例如打电话的语音，上网的数据包等等); 另一部分是我们不(直接)需要的, 它们专门用来控制电路, 这一类型的信号就称之为信令, 常见的例如无线核心网的空口信令.

WebRTC 中的信令概念也很类似, 它包含的不是流媒体数据, 而是流媒体的参数, 使用的协议是 SDP (Session Description Protocal), 用来协商媒体类型, 格式等参数. SDP 是一个通用的流媒体参数描述协议, 在 RTP, RTSP, SIP 中都有广泛的使用, 并不限于 WebRTC.

SDP 的内容很复杂, 此链接解释了 SDP 的基本内容, 截图如下:

一般, 我们不需要去修改 SDP 的参数, 甚至也不需要关注 SDP 的内容. 我们需要关注的, 是怎样在客户端之间传递 SDP.

offer & answer 过程

WebRTC 的 SDP 传递是一个简单的 offer & answer 过程, 如下图所示:

在官方 Demo WebRTC samples Munge SDP 中, 依次展示了建立 Peer to Peer 通道的步骤, 下图中用蓝色框住的部分, 就是在做信令处理:

信令服务器的特点

实现一个只具备基本的信令交换能力的服务器, 是很简单的, 我们只需要考虑一下两点:

数据传输方式, 可以用 HTTP 轮训, WebSocket, gRPC(HTTP/2) 等方式, 其中 HTTP 轮训性能差实现复杂, 一般不用
数据传输格式, 可以用文本协议(XML, json等), 也可以用二进制格式(Protobuf 等)

但信令服务器一般还需要考虑一些 WebRTC 之外的业务逻辑, 例如:

用户鉴权: 哪些用户能够建立会话
安全和访问控制: 信令的加密, 不同的用户都能做哪些操作等等
推送: 针对移动端, 信令最好通过推送下发

由于这些业务功能, 信令服务器一般需要共享状态, 依赖同一个数据库, 使得它水平扩容 (Scale out) 比较困难.

另外, 信令服务器要达到健壮和可靠, 还需考虑一些细节, 例如:

消息可达性 (ACK)
系统分片 (Sharding & Partition)
重试和幂等性 (idempotency)

做好这些细节, 是实现信令服务器的难点, 其中的问题和即时通信消息服务要考虑的问题非常类似.

NAT 穿越服务器

WebRTC 的很大一部分功能, 在于确保客户端在各种复杂的网络环境下, 都能顺利建立连接, 这一功能是通过 NAT 穿越服务器 (STUN 和 TURN)来实现.

NAT 穿越问题

传统的 Web 服务, 客户端通过 HTTP, TCP 等访问服务器的公网端口, 如下图所示:

这种情况下, 由于服务端公网地址是已知的, 网关和防火墙也都可自行配置, 建立连接是很简单的.

但客户端一般会在一个 NAT(Network Address Translation) 设备后, 处于局域网中, 要在两个客户端之间建立连接, 则要麻烦很多.

NAT 会带来以下两种问题:

内网 ip 和公网 ip 映射
防火墙问题

或者从另一个角度说, NAT 穿越要解决三种问题: IP 问题(内网 vs 外网), 端口问题(80, 443 …), 协议问题(UDP, TCP…)

ICE (Interactive Connectivity Establishment)

ICE 是给处于 NAT 和防火墙之后的客户端之间建立 Peer to Peer 连接的协议. 在 ICE 协议规范文档 RFC 5245 中, 定义了两种 ICE 服务器:STUN (Session Traversal Utilities for NAT) 服务器和 TURN (Traversal Using Relays around NAT) 服务器, 如下图所示:

简单理解 STUN 和 TURN 服务器的功能:

STUN: 用于客户端获取自己的公网 ip (只支持 UDP).

TURN: 用于转发流媒体数据.

	STUN 服务器	TRUN 服务器
核心功能	返回客户端外网 IP 地址	转发流媒体数据
使用频率	几乎100%要使用	较少使用
使用成本	成本低	成本高
对流媒体质量的影响	无影响	可能有影响

需要使用 TURN 服务器的流媒体数据占比(16年数据):

从上图可看出, 如果不使用 TURN 服务器, 会有 10% 左右的用户无法创建连接, 这在实际生产环境一般是无法接受的.

使用 STUN 和 TURN 服务器

WebRTC 定义了一个 iceServers 对象, 用来描述 STUN 和TURN 服务器信息. 可以通过 REST Api 来获取这一对象, 一个基本的 iceServers 对象如下图所示:

STUN 服务器的定义很简单. TURN 服务器, 因为涉及到转发流媒体的流量, 一般要做鉴权操作, 证书还有超时时间, 避免其它人偷用你的 TURN 服务资源.

TURN 服务的另一个特点, 是它会提供不同的协议和端口, 这是由于防火墙的存在, 一些协议和端口可能无法使用(例如, 很多局域网防火墙会封掉 UDP 端口, 因为 UDP 容易被利用做反射放大 DDOS 攻击), 需要提供多种选择, 最大程度保证连接可建立. 这些不同的连接方式, 被称作 ICE candidate protocols, 常用的有三种:

另一个相关概念是 ICE candidate Types, 也有三种:

host: 本地地址 (例如同一内网的两个用户互连)
srflx: 来自 STUN 服务器的地址
relay: 来自 TURN 服务器的地址

WebRTC samples Trickle ICE 可以用来测试 STUN 服务器和 TURN 服务器. ICE 处理是一个很复杂的有限状态机, 在一个标准的 Peer to Peer 连接建立过程中, 这个复杂的过程都发生在幕后, 由 WebRTC 来替你处理, 基本不需要关心. 但一些更复杂的应用场景, 还是会有自己处理 ICE 协议的需求.

STUN 服务器和 TURN 服务器, 由于是无状态的, 也和业务无关, 水平扩容很简单. TURN 服务器的一个难点是确保流媒体的质量(例如延迟时间)和可用性, 这就经常需要做多地部署, 负载均衡和服务器冗余.

媒体服务器

做一个普通的 P2P 音视频通信App, 是不需要 Media Server 的. 但如果要实现以下业务, 就可能需要要 Media Server:

实现多人音视频通话
需要录制实时音视频
需要做服务端音视频处理(例如图像识别等)
直播服务

多人音视频通话问题

在需要使用媒体服务器的场景中, 最典型的是实现多人音视频通话, 有三种解决方式:

第一种: P2P 网格 (Peer to Peer Mesh)

这一方案的优点是服务端实现简单, 直接使用 WebRTC 现成的 Peer to Peer Channel 即可. 但它的缺点也很明显:

随着参与人数的增加, 整个网格的复杂度和流量指数级增加
客户端需要处理多路流媒体, 对 CPU 和电量消耗很大

第二种: MCU 服务器 (Multiport Control Unit)

MCU 是传统的解决方案, 由一个中央控制服务器, 将多路视频合并成一个交给客户端播放.

它的最大优点, 是客户端实现很简单, 但它的缺点也很明显:

服务器 CPU 和带宽资源耗费大
服务端要做多路视频合并, 运算复杂, 延迟大
接收的视频布局很难改变, 不够灵活

第三种: SFU 服务器 (Selective Forwarding Unit)

另一种方案是 SFU, 它的基本原理很简单: 客户端负责上传视频流, 服务端将视频流解密后, 广播给所有的客户端.

这种方案的优点:

视频布局灵活
服务器可扩展性强, CPU 资源耗费小
延迟低

这种方案的缺点:

带宽占用非常大
客户端处理多路视频对 CPU 和电量消耗大

为了解决 SFU 带宽占用大的问题, 一种解决方案是 SFU 联播 (Simulcast): 客户端同时上传两路视频流, 一路高分辨率的主视频流, 一路低分辨率的缩略图流; 服务器广播视频流时, 只有一路(当前主讲)需要高分辨率的视频流, 其它人都可以用低分辨率的视频流. 下图是 google hangouts 的截图, 就是使用这种方案实现的:

网关服务器

网关服务器用于连接 WebRTC 和其它的 VoIP 技术, 例如 SIP, 也可以连接 WebRTC 和传统的移动电话网络等, 这涉及到信令的适配和媒体数据的适配. 一般会由三方服务提供商提供网关服务, 如下图所示:

使用 WebRTC 想实现的目标

当前调研 WebRTC, 主要是想实现三个目标:

参考 WebRTC 的架构, 优化实时服务的设计方案
使用 WebRTC 优化上课的音频质量
使用 WebRTC 提供视频画面

其中, 第一条是目前最为重要的, WebRTC 的方案中, 有很多是直播服务可以借鉴的, 例如:

信令服务和媒体服务分离
交换 SDP 创建会话的过程
TURN 服务器通过不同的协议确保连接的建立, TURN 服务器的水平扩容
RTP 协议实现音视频同步

针对这些优化点, 第一步想实现信令服务和直播服务的分离, 改变整个直播连线的机制, 从而使得直播服务可以做健康检查和负载均衡, 也利于实现上课期间的断线重连.

使用 WebRTC 优化音频和增加视频的对比

使用 WebRTC 优化音频和增加视频, 这两个目标的对比如下:

	使用 WebRTC 优化音频	使用 WebRTC 增加视频
需求迫切性	对音频能起到的优化效果未知	产品想做, 但实际对上课和产品推广的帮助有多大, 未知
功能重要性	核心功能, 线上如果出问题, 直接影响上课, 很严重	额外补充功能, 线上出问题关掉即可, 不影响上课
耦合性	在现有服务上修改, 强耦合, Android, IOS, PC 和回放服务必须同时实现, 一起上线	弱耦合, 独立系统, 与现有服务特别是回放无关, 客户端可实现也可不实现
实现难度	需要参考 TURN 服务器实现 Client – Server 连接;需要媒体服务器;可能需要处理 ICE 过程;需要处理 RTP 协议和音频编解码细节;有可能对声音和画板的同步产生影响(例如 jitter buffer);	使用标准的 WebRTC Peer to Peer 连接;无需媒体服务器;无需处理 ICE 过程;无需处理 RTP 协议和视频编解码细节;音画同步暂时无法处理;

总结

根据以上对比, 站在服务端的角度, 使用 WebRTC 增加视频功能, 实现难度低, 对现有服务的影响小, 线上出问题带来的风险小. 所以个人倾向于向通过做 WebRTC 视频功能, 让大家熟悉 WebRTC 相关技术, 了解开发中和线上运行会遇到的坑, 这一步做好之后, 再来使用 WebRTC 优化直播应用音频和上课白板的问题。

参考资料

视频: Servers for WebRTC: It is not all Peer to Peer (Kranky Geek WebRTC Brazil 2016)
视频: How to Build an End-to-End WebRTC Service (Kranky Geek brazil 2016)
PPT: Server-side WebRTC Infrastructure
文章: P2P技术详解(一)：NAT详解——详细原理、P2P简介

作者：ccwRadar | 来源：高性能服务架构