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

在 WebRTC 项目中，又拍云团队做到了覆盖系统全局，保证项目进程流畅。这牵涉到主要三大块技术点：

网络端、服务端的开发和传输算法

WebRTC 协议中牵扯到服务端的应用协议和信令服务

客户端iOS、安卓 H.264 编解码技术

△ WebRTC 技术点

实时音视频互动必须遵守三大点

必须基于 UDP 协议，否则不要谈实时

因为 TCP 协议的重传机制（传输保障）会导致累积延迟问题，用 UDP 协议没有传输保障机制，但需要自行完善丢包容错逻辑。

又拍云音视频互动方案是基于UDP 协议，使用 TCP 协议无法保障实时性。

TCP 协议有包重传机制，保证传输内容100%传输到目的地，这个特性导致延时增加。当然，由于UDP协议没有包重传机制，需要完善业务的容错性。目前来说，UTUN 网络提供的两种配置，都可以保证数据100%传输。

在极差的网络状态下，可以选择容忍丢包，使用算法保障90%以上的数据包正常到达，以此达到200ms以内延迟。

UDP协议相比TCP协议具有多链路传输的优势。

TCP协议只支持单一链路传输。当连麦、音画同时需要传输时，TCP协议只有一条通道进行数据传输。而通过UDP协议，音视频可以通过两个节点将数据一分为二来传输，A路传输50%数据包，B路传输50%数据包。终端收到两路数据流，再合并放到应用层做解码处理。

考虑多终端适配，使用 WebRTC 协议

客户端网络跨地区和跨运营商信号很差，所以不能使用 P2P 模式。目前包括苹果Safari 在内的所有的桌面端浏览器都已支持 WebRTC 协议。

网络层使用 P2P 模式无法解决跨地域、跨 ISP 的跨运营商网络问题，会导致延时过高的情况产生。如果一直纠结于P2P模式，那么QOS码率控制、包容忍等问题就无法在算法上有所突破。

云服务化

单机、单机房存在硬件瓶颈，唯有云服务化才能按需做到横向扩展。

随着用户量的提升，单台服务器所能支撑的并发量直播有限，RTMP Server、WebRTC Server一般八核服务器能承受的并发量只有2000~4000路，单机房也会成为硬件瓶颈，而公有云能承受几十万甚至上百万的数量压力，所以机房中不能存在单点，必须是云服务化分布式的。

云服务化非常重要，上文提到的 UTUN 网络属于完全分布式网络，分布在又拍云两百多个节点，四千台服务器上。只需要接入又拍云任意边缘服务器，就可以做到自主服务，自动选择出一条甚至数条路径，让用户与通讯网中任何地点的人交互。

又拍云 WebRTC 架构中遇到的经验和问题

又拍云 WebRTC 相比外部的 WebRTC 有较大的差别。即使你在同一个地方、同一个服务商、同一个无线信号下，又拍云都没有使用P2P模式，都是通过云服务来进行网络传输的。

我们严格遵循官方标准搭建包括服务端、客户端在内的 WebRTC 体系。目前 WebRTC 版本为可变性非常大的1.0版本，未来该技术可能会有革命性的迭代。如果采用自研的方式，会有无法跟进版本技术更新的风险。再者如果完全自主编写 Server 端或者客户端势必要投入非常大的精力和研发时间。

因此又拍云选择紧跟官方的步伐，无论官方有何种bug修复，都选择同步更新。

又拍云在实践中遇到的问题：

当 iOS 端使用新版本 WebRTC 时，由于音频处理部分导致的 Bug，会导致 CPU 占用率过高；

服务 Server 端由于编码传输时 WebRTC 是可变码率、可变帧率的，但是内核代码在进行传输时却使用了固定帧率操作，时间戳不一致的 Bug 导致了音视频不同步的情况，声音与画面不同步最大延时可以达到数十秒，不断累积。为了解决这个 Bug 需要把视频时间戳进行修正，统一使用音频的时间戳，来保证音视频同步；

Android 端不支持高通外的芯片硬解码，又拍云在近期把各个 Android 端编解码功能完善，目前已经能够适配华为、MTK、三星等品牌的机型；

目前客户端解码能力有限，会话人数最好控制在8个人以内；

自动根据参与人数控制总带宽在2Mbps以内；

美颜、滤镜等功能的接入会增加延迟，加入额外功能不能过度消耗客户端 CPU 资源。

音视频互动最大的难点——业务信令

目前业务信令还没有一套完整的解决方法，业务信令在 WebRTC 中虽然是开源的，但是没有形成标准的信令协议，这个部分需要我们自行构建。

架构网络电话场景时，牵扯到三个信令：呼叫、等待接听、通话。

但是实际中会有更多信令，假设一个会议场景，A邀请参会B，A会设置多个邀请途径：1.A直接将B拉到会议室；2.A把会议室号码给B，B自行进入；3.A配置房间权限控制，需要得到授权才能进入房间等。随着业务的发展，业务信令会不断增加，我们需要构建一套完善的信令体系显得非常重要。

我们在编写信令系统时，把信令系统分成了两类：1.底层系统信令，2.公共业务信令。

底层系统信令只需编写公共业务信令的总通道协议和 API 接口，让应用程序对接，将业务信令进行统一标准化。比如在房间里，发送一条广播给所有参会者的业务信令S，而业务信令S只想传达给B，但是C在同一个会议室也听到了，C会选择性的对业务信令S忽略以此达成这个业务功能。

目前来说必须面临的现实问题：

1.客户端硬件性能未能支持高清码率：多人互动不可能做到720P分辨率，一般来说都是在320P或者460P分辨率。一般手机因为客户端的解码能力支撑不了多路高清解码，达到6路以上码率只能做到300K以下；

2.硬编解码兼容性差：Android 机型太多，仅能有限支持H.264硬编解码，同时iOS和Android 端均不支持 H.265 硬编解码；

3.手机发热、耗电量大：参加会议iPhone电量支撑两、三个小时。桌面端耗电、发热最严重，测试时使用Chrome硬解码电量只能支持两个小时。

以上三点是目前整个业内所都要面临的最大的问题，只能等待终端的解码能力提升，相信到明年手机解码能力就可以支持多路高清互联。