网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？

本文整理自RTC大会，陈功的演讲《网页端实时音视频服务架构与实践》。

1、分享者

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

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_aa.jpeg

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_aa.jpeg

▲ 本文分享者：陈功

2、网页端的实时音视频的特点

网页端的实时音视频有什么特点：

首先-在浏览器端：
依赖于浏览器获取音视频的能力，以及强大的网页上的渲染能力，所以，就能够为高清的通信体验打下基础。同时，相比移动端来说，屏幕比较大，视窗选择也比较灵活；
第二-跨平台：
大家都了解浏览器对各个终端的特殊性，不止PC上有浏览器、移动端上有浏览器，甚至是一些知名的社交APP也嵌入了浏览器。这需要一个跨平台的体验，现在支持WebRTC的浏览器也越来越多了，这也是网页实时通信的一个特点；
第三-免安装，方便接入：
随着WebRTC的普及，它不需要安装任何插件就可以实现网页端的实时通信。

3、网页端实时通信可以应用在什么场景

首先是直播，直播非常火。直播的主播端会有需求，在网页端进行开播，因为网页端的屏幕比较大、视频比较清晰、处理能力比较强。同时，也非常有意思，我们一个客户也在用我们网页端的SDK做直播的监控。大家也知道，直播开播的房间数很多，在一个网页上可以监控40-50个房间，来做直播的巡视员，用网页端的实时音视频SDK是比较方便的。

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

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

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

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_1.jpg

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

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

5、WebRTC是否已经成熟，是否可以产品化？

5.1WebRTC浏览器支持情况

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

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

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_2.jpg

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_2.jpg

▲ WebRTC的浏览器支持情况

如上图所示，我们看一下这几个浏览器在市场上的占有情况，不难看出，现在除了占百分之8点几的IE之外不支持，其他的其实都已经支持了。

我们再从协议栈的角度来看一下。WebRTC 1.0 Spec已经基本定稿了，除了一些比较细节的问题还没有最终确认。各个浏览器对标准的支持也越来越好。虽然谷歌自己也在推广这个技术，但是谷歌自己的浏览器Chrome对WebRTC 1.0的支持并不是很好，这是因为谷歌在内部对WebRTC做了很多实验性的东西。Chrome团队对外声称，会在今年底，完全跟上WebRTC 1.0的标准。

5.2WebRTC的开源社区现状

另外一个方面，看一下开源社区，举几个比较典型的开源项目：

Kurento：它是功能比较强大的一个多媒体处理框架，支持WebRTC协议栈。它可以作为Media server，后台有转码的能力，并且有OpenCV处理能力；
Licode：可以作为WebRTC的轻量通信平台，是纯转发的服务器处理模式；
Janus：可以作为WebRTC通信网关，比较轻量；
React-Native-WebRTC：值得关注的是React-Native-WebRTC，现在越来越多的开发者开始转向前端，JS。这种情况在国外更为普遍。在开源社区上出现了这么一个项目，封装了一个WebRTC的模块，开发者就可以很方便的在手机上来实现带有实时通信能力、兼容WebRTC的应用。

5.3WebRTC生态圈

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_3.jpg

▲ WebRTC的生态圈

市场分析对WebRTC非常看好，预计到2022年市场规模将达到64.9亿美金。总的来说，WebRTC技术现在处在一个最好的时代。

6、如何能够构建起一个WebRTC的系统？

对于开发者来说，如何用这个技术、如何能够构建起一个WebRTC的系统？其实是有一段必经之路。

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

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_4.jpg

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_4.jpg

▲ WebRTC的P2P模型

那么，完全基于点对点之间通信的架构有什么特点？延时会比较小。但是，有一个很大的缺点。这种点对点音视频流的传递，每一个用户都要给另外一个用户传自己的视频流，这样对它上行带宽的压力很大。并且，每一路视频流都是独立进行采集编码，这对浏览器端编码压力的考验也很大。有人会问，能不能只采集一次编码，然后就把这个流发给不同的终端接收者？很遗憾，这是不行的。因为WebRTC的协议是做端到端的质量策略优化，所以它有一些策略调整，都是端对端的RTCP来实现，必须要经过多次的编码，然后分别传输给不同的接收者。

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

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_5.jpg

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_5.jpg

▲ WebRTC的通信架构占比

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

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

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

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

7、WebRTC背后的技术难点

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_6.jpg

▲ 网页端实时音视频技术难点

上图是从一个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：看起来很美，但离生产应用还有多少坑要填？_7.jpg

网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？_7.jpg

虽然主流的浏览器都开始支持WebRTC，但是，其实所谓的支持WebRTC还是有很多兼容的问题。上图黄色代表的是部分兼容，在这里只有Firefox支持的比较好。目前炒的比较热的是Safari，在这里可以看到种种的技术难点，做WebRTC，在Demo产品化的时候我们就必须要去面对。

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

8、本文小结

上面说了这么多，我可以很清晰地感受到：要从一个WebRTC开发的Demo到真正成熟的产品服务的话，首先要有一个专业团队。这个专业团队要覆盖音视频的专业人才、专家，还要有音视频通信的、视频传输领域的专家，需要很强的行业经验，高可用运维、实时监控、调查工具这些，都需要真正的工程师、专家在日积月累的工作当中积累下来的经验。

当然，实时音视频门槛高是公认的，但技术上来说，厚积薄发，不积跬步无以至千里，只要静下心知其然而知期所以然，问题也都能一一得到解决，必竟各种开源技术和库层出不穷，就看你能否用好它们。

（原文链接：juejin.cn/post/684490… ，有改动）