网页端实时音视频服务架构与实践

本文整理自RTC大会，陈功的演讲《网页端实时音视频服务架构与实践》。 欢迎访问 RTC 开发者社区，与更多开发者交流经验，参与更多技术活动。

陈功
负责网页端音视频通讯技术架构。毕业于中国科学技术大学，Ph.D。原英特尔服务器事业部多媒体架构师，主导基于WebRTC的视频会议解决方案搭建。曾任职Marvell视频事业部，研究多媒体系统框架，参与Google TV, OTT等项目
复制代码

网页端的实时通讯有什么特色

首先，在浏览器端，依赖于浏览器获取音视频的能力，以及强大的网页上的渲染能力，因此，就可以为高清的通讯体验打下基础。同时，相比移动端来讲，屏幕比较大，视窗选择也比较灵活。

第二，跨平台。你们都了解浏览器对各个终端的特殊性，不止PC上有浏览器、移动端上有浏览器，甚至是一些知名的社交APP也嵌入了浏览器。这须要一个跨平台的体验，如今支持WebRTC的浏览器也愈来愈多了，这也是网页实时通讯的一个特色

第三，免安装，方便接入。随着WebRTC的普及，它不须要安装任何插件就能够实现网页端的实时通讯。

网页端实时通讯能够应用在什么场景

首先是直播，直播很是火。直播的主播端会有需求，在网页端进行开播，由于网页端的屏幕比较大、视频比较清晰、处理能力比较强。同时，也很是有意思，咱们一个客户也在用咱们网页端的SDK作直播的监控。你们也知道，直播开播的房间数不少，在一个网页上能够监控40-50个房间，来作直播的巡视员，用网页端的实时音视频SDK是比较方便的。

另一个是在线教育，在线教育的老师端通常都在PC上，若是要安装应用程序，有些老师也不是很懂电脑技术，要去配置的话就比较麻烦。若是有网页端免安装的方案的话，他们用起来的话，用户体验也会比较好。在线教育除了音视频，还要求有屏幕共享、白板，由于都是H5的技术，因此与Web端的SDK集成起来的话也会很是方便。

最后就是视频会议，你们在公司里用过浏览器的视频会议的话都会有体验，HR发一个连接，某一个时间点你点这个连接，除此以外还有一些说明，你要安装哪些东西，这个会比较复杂。如今有了免安装的WebRTC以后，你们对视频会议的体验也会上升一个台阶。这边列的这几个是比较典型的场景，其实还有远程医疗、企业协做之类的。

从技术上看，网页端的实时通讯是否已经成熟？是否已经准备好了？

若是说到网页端、浏览器端的实时通讯的话，你们首先会想到的就是Webex，它的体验是很是不错的，也培养了一大群目标用户，让用户认知到在浏览器上就能够进行视频的沟通，打开了一个市场。可是，它有一个缺点，就是必须安装浏览器的插件和扩展程序，和GoToMeeting是同样的，很是不方便。另外一种作法是，在PC上安装一个应用程序，经过这个程序来代理获取、处理音视频的流，网页端只是作渲染和展现。

在很长一段时间里，这些网页端的用户以为这个技术就是这样的，体验就是这样的，没法提高了。直到2011年，WebRTC技术的出现，而且由谷歌作推广。WebRTC带来的体验是由于免安装才受到了关注。如今在差很少6年的发展时间里，其实也有不少的质疑声，好比，Google的项目会不会半途而废，各大浏览器厂商会不会不支持这种打通浏览器生态的想法。

##WebRTC是否已经成熟，是否能够产品化？

首先，来看一下目前知识WebRTC浏览器和平台的状况。

最先支持WebRTC的是Firefox和Chrome，以后是Opera，跟随者chrome支持WebRTC，它们内核是同样的。微软前两年提出了一个ORTC的协议，跟WebRTC有些类似。ORTC发展并不顺利，如今在edge中开始支持WebRTC。近期苹果更新了IOS系统以后，Safari 11也开始支持WebRTC了。在安卓平台上，其实很早就开始支持了WebRTC。

咱们看一下这几个浏览器在市场上的占有状况，不难看出，如今除了占百分之8点几的IE以外不支持，其余的其实都已经支持了。

咱们再从协议栈的角度来看一下。WebRTC 1.0 Spec已经基本定稿了，除了一些比较细节的问题尚未最终确认。各个浏览器对标准的支持也愈来愈好。虽然谷歌本身也在推广这个技术，可是谷歌本身的浏览器Chrome对WebRTC 1.0的支持并非很好，这是由于谷歌在内部对WebRTC作了不少实验性的东西。Chrome团队对外声称，会在今年末，彻底跟上WebRTC 1.0的标准。

另一个方面，看一下开源社区。举几个比较典型的开源项目，一个是Kurento，它是功能比较强大的一个多媒体处理框架，支持WebRTC协议栈。它能够做为Media server，后台有转码的能力，而且有OpenCV处理能力。Licode能够做为WebRTC的轻量通讯平台，是纯转发的服务器处理模式。Janus能够做为WebRTC通讯网关，比较轻量。值得关注的是React-Native-WebRTC。如今愈来愈多的开发者开始转向前端，JS。这种状况在国外更为广泛。在开源社区上出现了这么一个项目，封装了一个WebRTC的模块，开发者就能够很方便的在手机上来实现带有实时通讯能力、兼容WebRTC的应用。

最后，看一下生态圈。在CPaas这一层，有声网、Twilio、Tokbox这样的公司在作贡献。

市场分析对WebRTC很是看好，预计到2022年市场规模将达到64.9亿美金。总的来讲，WebRTC技术如今处在一个最好的时代。

对于开发者来讲，如何用这个技术、如何可以构建起一个WebRTC的系统？实际上是有一段必经之路。

咱们知道WebRTC的底层是基于P2P链接，是点对点的通讯。不少开发者上手的时候，都会去作P2P质量的检验。好比说一个公司的产品经理告诉开发人员说“如今WebRTC很火，你给我整一个WebRTC的系统。”八成的开发人员会交付这样一个网状结构WebRTC的架构。

那么，彻底基于点对点之间通讯的架构有什么特色？延时会比较小。可是，有一个很大的缺点。这种点对点音视频流的传递，每个用户都要给另一个用户传本身的视频流，这样对它上行带宽的压力很大。而且，每一路视频流都是独立进行采集编码，这对浏览器端编码压力的考验也很大。有人会问，能不能只采集一次编码，而后就把这个流发给不一样的终端接收者？很遗憾，这是不行的。由于WebRTC的协议是作端到端的质量策略优化，因此它有一些策略调整，都是端对端的RTCP来实现，必需要通过屡次的编码，而后分别传输给不一样的接收者。

右下角的表格列的是一个权威的行业机构统计的目前在互联网上使用WebRTC的系统架构，纯P2P的只占19%。

若是按刚才介绍的这个架构，开发人员交付给产品的话，确定会打回来的，由于你们都知道，上行带宽很是宝贵，也很是受限。为了解决这个问题，开发人员会作一些深度的研究，发现领域内的WebRTC架构其实中间加了一个点，这个点就是服务器，典型的媒体服务器只作多路流的转发，不作后台的媒体处理和转码。

上文提到的Janus和Licode开源项目均可以实现转发媒体服务器的功能。它的特色是，每一个终端用户只要上传一路流到中间服务器，节省了带宽。同时SFU只是作转发，因此对延时的影响相对比较小。弊端是，若是有两路接收者，下行带宽的能力不同，一个是500K，一个是2m，因为源端发送者只送一路流，因此就很难适配多路的终端。

改为纯转发的媒体服务器以后，它还有一些弊端，开发人员又会想办法说，我在中间这个节点加上混流的功能。你们也能够从这个架构当中看出来，在服务器端收到不一样的两路视频流以后，会分别作解码、拼接合成、编码。根据不一样接收者的带宽状况，分别给不一样的接收者发送不一样profile的视频流。这就解决了，若是是多个接收端的用户，没法作到带宽的适配。这个缺点也很明显，中间作转码必然带来延时，其次是转码服务器的成本很高，可是，确实节省了下行的带宽，

介绍了几种典型的WebRTC的系统架构以后，开发人员能够基于刚才说的几个开源项目，能够很方便的搭建出，或者是不用费太多的时间就能够搭建出这么一个Demo的系统，是否是故事就到此结束了？其实还差很远，这边还有不少隐藏的坑。

背后的技术的难点

上图是从一个Demo作成一个比较稳定的产品，会遇到的坑。

首先是可用性。WebRTC是基于P2P的，P2P的可用性、链接成功率也是你们一直在诟病的，不止是打洞、穿越这些技术。

平台互通：WebRTC出来的时间仍是有限的，不少领域内的公司都有本身自研的通讯协议，这些协议通常是用在Native端，手机端、PC端、mac、windows，这也带来了一些问题，自研的协议跟WebRTC协议之间如何能够作到平台互通？这也有不少的坑在这里面。刚才说它是一个端到端优化的传输策略，你拆开这个端到端，你的上行是WebRTC，你的发送者是WebRTC，接收者是自研的端，这里面有不少策略匹配的工做须要去作。

编码器选择：音视频的编码在实时通讯中很是重要。WebRTC的视频，支持VP8/9,H.264。可能有人会选择H.264，认为它在移动端适应性强。可是H.264在Chrome上不太成熟，因此不少商用产品依然在用VP8，可是涉及到移动端的互通，又得考虑编码器的选择。

弱网对抗：WebRTC有一套本身的传输策略，好比说丢包重传、FEC、带宽检测、动态码率调整。可是，在弱网对抗方面，前面架构图也提到，咱们会在中间加一个转发节点，就作不到端到端的传输链路。因此，弱网对抗又是比较头疼的问题。如何在浏览器上，和转发服务器上，实现上行跟下行链路的分别优化，这里面也有不少难题是须要克服的。

多用户场景：就像是典型的小型直播的场景，有不少的接收者，一个发送者。若是用纯WebRTC的传输策略，由于它多个接收者之间估计出来的下行带宽是不同的，对发送端的要求，发送的码率调整也不同。你们若是有测试经验就会发现，WebRTC作多人的场景，若是接收端的人数超过4个、5个的话，它发送出来的码率就会很是低，因此看到的画面就会很是的糊。

虽然主流的浏览器都开始支持WebRTC，可是，其实所谓的支持WebRTC仍是有不少兼容的问题。上图黄色表明的是部分兼容，在这里只有Firefox支持的比较好。目前炒的比较热的是Safari，在这里能够看到种种的技术难点，作WebRTC，在Demo产品化的时候咱们就必需要去面对。

智能路由：浏览器跟服务器之间进行优化传输，可是服务器跟分布式服务器之间还有一段传输。这就要求提供WebRTC服务的厂商对后台服务器之间的传输有一个很是好的智能路由选择、有一个传输的优化，好比说跨运营商的、跨国的。高可用运维，就不展开说了，要保证服务可用，服务进程不能够挂掉。海量的并发架构，通常提供WebRTC的厂商，是一种on demand扩容的形式，可是也要求你设计的架构可以支持海量并发的扩展。还有全局监控系统，你要对在线上跑的服务质量稳定性的数据能够进行监控。还有一个很重要的问题就是调查工具，当你提供WebRTC实时通讯以后，要有问题调查的能力。好比，在通讯中发生了卡顿、延时，究竟是什么缘由产生的，哪些因素带来了很差的通讯体验，这要有一套很完备的问题调查工具。

说了这么多，总结两点，要从一个WebRTC开发的Demo到真正成熟的产品服务的话，首先要有一个专业团队。这个专业团队要覆盖音视频的专业人才、专家，还要有音视频通讯的、视频传输领域的专家，须要很强的行业经验，高可用运维、实时监控、调查工具这些，都须要真正的工程师、专家在日积月累的工做当中积累下来的经验。

最后介绍一下声网WebRTC的SDK。也是从几个方面来介绍一下：核心质量、集成的简易度、功能的灵活扩展、服务的稳定性跟全局监控的能力。

• 核心质量：声网有一套大网SD-RTN™，能够保障全球传输。Web的SDK用到了分布式网关的架构，网关是接在大网的边缘来部署，能够提高可用性。

• 专一互通：正由于声网有这么一个分布式网关的架构，咱们就能够接收到不一样端上发来的适配信息，能够对各个平台的策略进行灵活的调整。因此，在各个浏览器的监控上，咱们也能够作得相对比较好。

• 灵活配置的传输策略：咱们把整个端到端WebRTC的传输链路改形成端到网关、网关到端。在这里面，咱们也配置了不少FEC、策略上的一些优化。同时，咱们也能够多流发送。 差别化的编码器选择：咱们能够选择不一样的编码器，根据终端的能力进行适配，同时兼顾到端上有没有硬件编解码，和软件的编解码。这些点加起来，保证了咱们声网Web的SDK就能够提高为一个高质量的传输服务。

• 快速集成：很是方便，只须要四行代码就能够接入到咱们视频通讯的频道里，很方便，通常四、5分钟就能够完成一个音视频聊天的小程序。同时，咱们也有完备的文档，很是简单易读的Demo。 功能的灵活扩展：传统的WebRTC是用来作通讯的场景，咱们这个Web SDK，目前也支持直播的场景，支持旁路推流、服务器录制。

• 全局监控的能力：咱们目前提供了Dashboard、服务质量报表，能够看到频道内的传输质量、传输效果、用户接入等各类数据。另外，咱们还有全局网络的指标，包含丢包、延时、抖动的信息。右边这个是问题诊断系统的一部分。为何问题诊断系统重要？当用户接入实时通讯，你发生延时、抖动的时候，咱们就能够知道在什么地方出现了问题，综合这些信息，咱们要很清楚的知道线上的某一个频道的传输渠道出了什么问题，在什么地方能够调优。

课程预告：《从0搭建网页端实时视频通话》

• 时间：11月29日（周三） 16:00-17:00

• 内容：

  • 通讯和直播的必要背景知识
  • Agora SDK API调用逻辑
  • 开发环境
  • demo源代码解读。demo功能包括：建立频道、加入频道、离开频道、开关摄像头、静音、如何测试。
  • 如何测试。视频通话、直播须要进行哪些测试，如何进行简单的测试。

• 参与方式

  本次课程形式为线上直播课。

  • 首先，访问如下连接或点击阅读原文报名，等待课程开始。
  • 在 11月29日 下午3点45分，访问如下连接进入课程便可

• 报名连接

www.itdks.com/liveevent/d…