WebRTC服务端工程实践和优化探索

本文来自即构内部音视频框架设计的开发同学在2020年关于《WebRTC服务端工程实践和优化探索》的技术分享；

希望本次分享能给大家在WebRTC服务端实现或者项目选型时带来一些思考。

接下来进入主题，今天的分享主要分为三个部分：

WebRTC服务器架构介绍及设计思路；

开发WebRTC服务器所需的技术和面临的难点；

QoS服务质量的实现及优化。

WebRTC服务器架构介绍和设计思路

我们首先要想一下，为什么需要WebRTC服务器？WebRTC服务器它的作用是什么？

在大家的认知里面，WebRTC是谷歌开源的一个协议，是现在大家比较熟悉的一个点对点通讯方案。点对点通讯方案是指双方浏览器之间是直接互联的，如果在多方会议或多方通话的情况下，每个通话者之间都是直连的，没有经过第三方。

下面来看一下它的优劣势： 

优势

第一，简单。这个模型非常简单，点对点，没有经过中间的一些服务器。

第二，延迟小。既然是直连的，我们可能理所当然地认为中间除了这些路由节点之外，就没有其他地方会增加延时了。但是我后面加了一个问号，也就是说未必是这样的。

熟悉我们国内运营商网络情况的都知道，联通，移动，电信之间的通信可能是不对称的，如果我是联通，你是移动，咱们直连的话，延迟未必是小的，这个就是我加了一个问号的原因。

第三，端对端带宽适应。这个指的是WebRTC可以根据会话者之间的网络情况、带宽情况进行适应。比如当你的接收带宽不够时，我可以降低上行编码码率来适应你，从而达到一个更好的通话效果。

劣势

第一，连通性能差。点对点之间，由于所有的网络不是在一个防火墙后，我们可能需要打洞，甚至有一些防火墙非常严格的话，我们连打洞都没办法完成，这会极大的影响服务的连通性。

我们首先要发现对方，然后要打洞，如果打洞不成功，还需要通过中转服务器来进行媒体的传输，这个过程可能会快则几秒钟，慢则几分钟。也就是说我们从会话开始到双方建立通信，整个过程是非常复杂、耗费非常长的时间。

第二，带宽占用高。所有的与会者是直连的，带来的一个问题是，如果我要看到其他所有人的视频，那么每个人都需要推一路流给我。同样的，其他人也是需要接收除他以外的所有流，这时候我的上行带宽占用是非常高的。在视频会议场景下，少则十几多则二十几个人，现在几百个人的会议也是很常见的。按照我们现行的带宽，是达不到的。

第三，编解码压力大。既然每个人的流要单独发送给其他与会者，那么也要单独编解码，要发送N路就要编N路，并且编解码压力是非常大的，不仅我们的移动端没办法承受，甚至我们的PC端也是没办法承受的，这是它很大的一个劣势。

在我们实际的应用场景上，如果没有服务器，那么我们也没办法进行录制，无法实现视频回播、鉴黄以及CDN分发等功能。综合考虑，我们就会发现点对点方案可能并没有很好的满足我们当前实际的应用需求。

所以这里就要引入一个服务器方案的架构，根据刚才提到的点对点三大劣势，我们来重点看看新方案是如何解决的。

连通性

通常我们的服务器都会架构在公网上，所以各个会话者是直接跟我们在公网上的服务器建立连接，省掉了打洞，直接一步到位。

网络带宽占用高

假设当前我们这个会议有四方会话，那我的与会者有三路，我只需发一路到服务器上，通过服务器把我这一路转发给其他三路的与会者就可以了，不需要再去多发两路，这样我的上行带宽就从原本的三路变成了一路了；而接收端，引入MCU的概念，为了节省下行带宽，我们可以将这三路混流，再转发给我，那么我的下行也只有一路。

编解码压力小

通过优化架构带宽，编解码从原来的N路变成一路，也同步缓解了编解码压力。

既然服务器能更好的满足我们的实际应用，那么WebRTC服务器应该怎么进行架构设计呢？开发WebRTC服务器需要哪些技术以及可能会面临哪些难点？以及WebRTC服务端QoS（服务质量）的实现及优化有哪些重点要注意的？

篇幅关系，关于《WebRTC服务端工程实践和优化探索》的完整内容，大家可以通过我们的活动资料包获取，资料包中还有视频回放、演讲PPT等资料。