WebRTC如何在架构中引入服务端

WebRTC如何在架构中引入服务端作为实时音视频领域最火的开源技术，WebRTC点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。即构科技资深音视频架构师黄开宁带来了他的经验分享。为什么需要WebRTC网关在WebRTC1.0标准还没有定稿之前，这个标准只具备雏形，在很多方面都有缺陷。而随着1.0标准的定稿，WebRTC逐渐完善，到现在已经可以在网页端使用，换句话说，已经有基于WebRTC的实际应用。下面主要结合不同的应用场景来说明为什么需要WebRTC网关。针对在线教育或类似的应用场景，我们只需要给准入门槛用户提供一个试用，比如试听课程。但是如果试听课程需要下载APP，对于推销人员和试听用户来说都是繁琐的操作。而基于WebRTC的网页版课程试听，取代了繁重的APP下载，操作简单方便，获客变得更加容易。这个就是即构在成熟的商用系统中加入WebRTC网关的出发点，同时也是客户提出的要求。在线医疗的场景中也有同样迫切的需求。在上个月，我的汽车出了点小意外，在现场等了将近一个半小时后，保险专员才到达现场进行处理。如果能直接通过手机浏览器，接入某个保险公司的客户专员进行在线定险，可能10-20分钟就能解决问题。就像车辆碰撞，生病其实算是一个小概率事件，没有必要在手机中安装一个医疗软件。假如在户外被莫名的东西咬到而出现了敏感的情况，这个时候直接通过浏览器进行在线问诊，显然比安装一个APP要方便的多。这个是从需求上出发，也是浏览器迫切需要WebRTC网关的原因。WebRTC通信模型的对比大家都知道基于WebRTC的延伸，目的是实现实时通话或者是多方通话，是没有服务器的概念。下图是我对WebRTC通信模式的总结，左边是基于P2P方式对WebRTC进行延伸，我把它称为P2P模式，右边则是加入了服务器的模式，我把它称为服务器模式。P2P模式实际上是通过点对点进行传输，不需要经过任何的服务器，除了TURN和STUN服务器之外。在不需要NAT的情况下，两个用户可以直接相连，如果在NAT的情况下，就需要STUN介入。如果打洞无效时，则需要借用TURN。从图上可以看到，借用TURN的P2P模式的拓扑结构，和右边的服务器模式的拓扑结构十分相似，但是他们之间有明显的区别。TURN就像是一个中转站，作用只是简单的转发，而服务器则有更多的功能。这两种模式的优势也不同，由于P2P模式的用户之间是直接相连的，所以从成本上看，P2P模式的成本更低，但是在弱网环境下，P2P模式在连通性上的表现并不理想。现在大家所用的微信，从成本和点对点的沟通方式上看都应该选用P2P模式，但是实际上，微信并没有使用P2P的方式，而是使用服务器模式，这个也是考虑到P2P模式在弱网环境下的表现。接下来以带宽为例，在上下行带宽都为1M的情况下对比这两个通信模式。1V1模型中，在上行带宽为1M的情况下，这两种模型都没有什么区别，上下行带宽都是1M。上图是NVN的模型，一般用于多方会议。在P2P模式中，由于各个点都需要在上行和下行传输，所以带宽是n-1。而在右边的服务器模式中，只需要上传一路到媒体服务器，而下行中通过SFU模型可以选择，接收媒体服务器中全部或者其中某一路。从带宽上看，上行只需要1M的带宽，这种上下行带宽不对称的服务器模型明显比P2P模型更好。而随着这接入服务器的用户数量增加，接入到SFU媒体服务器的服务器模型的优势就更加明显。还有一种是1VN模式，就是我们所熟知的直播模型。P2P模式是根据用户数量进行上行传输，而在直播中，一个直播间的用户数量可能是十万甚至是百万的数量级，所以P2P模式不适用于直播。目前的直播都是使用服务器模式，在上行只有1M的带宽情况下，主播传输视频流到服务器，由服务器进行下行的分发。由于经过服务器，我们可以对服务器的能力进行最大限度的扩充，例如实现多级分发体系等，提高分发的效率。在直播和监控中，这样的多级分发体系应用非常广泛。刚刚说的1V1、NVN、1VN的模型都是在同一个能力级上，就是说在上行和下行中，传输协议、媒体流方式、编解码格式都是一致的，或者说是处在同一个体系中的。而在实际中，上行和下行都一致的情况比较少，很多时候我们需要在中间的服务器中进行转码，从而实现具有不同能力的终端之间进行通信。这种情况下，就需要用到MCU模型。大家都知道现今直播的发展要得益于CDN分发体系，CDN主要通过RTMP协议进行传输，而WebRTC的传输协议是RTP/RTCP，所以如果我们需要使用CDN网络进行分发，就需要在服务器中将RTP/RTCP转成RTMP。在WebRTC中，编码格式是OPUS，而RTMP协议对应的编解码格式一般是AAC，通常这两种编码格式之间的转换也是非常现实的需求。同时，在MCU模型中，我们还可以在服务器中增加录制、混流的功能，在直播连麦的情况下，通过混流的方式可以大大减少下行的带宽。除了实现以上功能外，由于如今的直播中美颜、滤镜几乎成为了标配，所以实现这种附加功能也是市场普遍的需求。虽然在WebRTC中并没有提供实现美颜、滤镜的接口，但是我们可以在服务器端实现类似的附加功能。根据实际的业务需求，通过MCU多点控制单元，可以实现这类附加功能。以上所介绍的模型都有各自的优缺点，大家应该根据具体的业务场景进行选择，所实现的功能也并不是越多越好。刚刚是基于媒体的角度分析了有关WebRTC网关的通信模型，接下来介绍一下SIP信令网关相关内容，尽管目前SIP在国内并不常见，但是在国外还是比较普及的。首先我们需要了解SIP通信模型的概念，其实SIP和WebRTC还是有很多的共同点，例如，上行传输的协议都是用Offer/Answer模型，而底层协议都是RTP/RTCP。如果需要在浏览器两端建立流媒体服务器，只需要简单的几步，但是如果浏览器要和一个SIP终端通信则是非常复杂的，因为信令的不对称，所以需要在信令网关中进行转换。但是信令的转换没有统一的标准，只需要实现通信两端的SDP、Candidate的交换即可。开源VS自研目前市面上有不少的开源系统，这些开源系统有各自的特点，在实际开发过程中应该根据具体的需求进行选择。表格中所列出的开源系统是目前市面上比较常见的，分别从服务器类型、编解码能力、文档的完整性和开发商来进行对比。大家都知道WebRTC的服务器模型有两种，分别是SFU和MCU，SFU实现的是简单转发的路由功能，而MCU可以提供更多扩展性的功能实现，而且MCU型的服务器往往包含SFU，所以MCU的实现难度较大。其次，文档的完整性也是非常重要的，因为对于开发者来说，文档具有非常重要的指导作用。最后是开发商，这个主要涉及到项目的可持续性、升级支持以及版权问题，对于商业机构来说版权的问题需要谨慎考虑。●首先介绍的开源系统是Kurento，这个开源系统是在表格所列出中最全能的一个开源系统。这个开源系统支持转码，同时还有滤镜的附加功能。但是在测试过程中，这个开源系统的稳定性不是很好。这个开源系统同时提供了一个云服务方案，主要是开发商为了推广云服务而开源的系统，所以性能的稳定性还有待提高。●Janus的出发点是网关，它的开发商是Meetecho公司，Slack推出的视频通话方案就是基于这个开源系统的。但在测试过程中发现，这个开源系统在性能上有些问题，而Slack也是对其进行了大量的优化。●Jitsi只是实现了SFU模型，不包含MCU，由于功能单一，只是一个转化路由，所以这个系统是列表中是较为稳定的一个开源系统。如果只是需要实现简单的转发功能，这个开源系统是不错的选择。●Licode具有SFU和MCU功能，它的架构是插件式的，也就是说，如果你想在自己的源代码上附加某些功能，可以直接使用Licode对自己的系统进行补充，既能保留原有系统的特性，又能达到完善功能的目的。●Intel使用Licode实现了一个IntelCSforWebRTC的套件，它是免费的，有提供Client端和Server端的SDK，但是这个系统不开源。我们在一些沙龙活动中会经常看到有关这个系统的介绍，基于这个系统配合使用Intel方案也是不错的选择。这个系统也是列表中唯一支持RTMP转协议的系统。●最后一个开源系统是MediaSoup，这个系统只支持SFU，底层的开发语言是Node.js。对于熟悉Node.js语言的开发人员来说，这个开源系统比较容易学习。但是由于这个开源系统出现的时间不长，系统稳定性还有待提高。既然市面上已经有不少的开源系统，为什么即构还需要自己研发系统呢?首先，目前的开源项目并不能完全满足业务需求。以上介绍的开源系统都不是基于分布式架构，如果要实现大型分布式架构或者后台，需要投入大量的开发人员和时间对现有架构进行改造，从成本和效率上来看，与自研相差不大。其次，通过自研可以深度掌握相关技术，才能根据自身业务特点对框架进行针对性的定制和性能优化。虽然WebRTC的体系非常复杂，但是里面包含的RTP、RTCP、DTLS、NETEQ等技术要点是十分值得学习的。从现实需求看，自研也是十分必要。就像即构通过自研RTMP方案用于实时互动，其最低延时可以达到300毫秒。说明我们对RTMP标准的特性十分了解，甚至可以根据不同的需求对框架进行特有的设计或者是有针对性地进行性能优化，这也是即构的优势所在。最后，无论是开源还是自研，立足点都应该是实际的需求，根据自己的具体需求选择最合适的方案。总的来说，从不同的应用场景看，在系统中加入WebRTC网关几乎已经是大势所趋，对于具体的应用场景，基于WebRTC的延伸可以分为两种通信模型：P2P模式和服务器模式，在实际应用中应该根据不同的需求进行选择。尽管目前市面上已经有不少的开源系统，但这些开源系统都有各自的优缺点，不一定能满足用户需求，在这样的背景下，即构选择了自主研发系统。