共计 1903 个字符，预计需要花费 5 分钟才能阅读完成。
11 月 7 日，即构和上海 GDG 技术社区联结举办了实时音视频技术云上技术分享专场，来自即构科技和 Bilibili 的资深技术专家进行了深度分享。大会吸引了泛滥开发人员交换、观看，并在流动过程中与分享嘉宾进行了热烈互动，上面咱们整顿了嘉宾们分享的核心内容，错过流动直播的小伙伴能够持续观看学习。
本文是即构科技黄开宁带来的主题为《WebRTC 服务端工程实际和优化摸索》的技术分享。以下为次要的分享内容：
大家下午好，我是来自即构科技的黄开宁，目前在即构科技负责音视频、媒体服务器以及网关的研发和开发，次要是架构的设计和开发，心愿本次分享能让大家在 WebRTC 服务端实现或者我的项目选型时能带来一些思考。
接下来进入主题，明天的分享次要分为三个局部：
第一，WebRTC 服务器架构介绍及设计思路；
第二，咱们开发一个服务器所须要的技术和面临的难点；
第三，QoS 服务质量的实现及优化。
一、WebRTC 服务器架构介绍和设计思路
咱们首先要想一下，为什么须要 WebRTC 服务器？WebRTC 服务器它的作用是什么？在大家的认知外面，WebRTC 是谷歌开发的一个我的项目或者是协定，是当初大家比拟相熟的一个点对点通信计划。点对点计划是指单方浏览器之间是间接互联的，如果咱们在多方会议的多方通话的状况下，咱们各个通话者之间都是直连的，没有通过第三方。
上面来大略看一下它的优劣势：
劣势
第一，简略。这个模型非常简单，点对点，没有通过两头的一些服务器。
第二，提早小。既然是直连的，咱们可能天经地义地认为两头除了这些路由节点之外，就没有其余中央会减少延时了。然而我前面加了一个问号，也就是说未必是这样的。相熟咱们国内运营商网络状况的都晓得，联通，挪动，电信之间的通信可能是不对称的，如果我是联通，你是挪动，咱们直连的话，提早未必是小的，这个就是我加了一个问号的起因。
第三，端对端带宽适应。这个指的是 WebRTC 能够依据会话者之间的网络状况、带宽状况进行适应。比方当你的接管带宽不够时，我能够升高上行编码码率来适应你，从而达到一个更好的通话成果。
劣势
第一，连通性能差。点对点之间，因为所有的网络不是在一个防火墙后，咱们可能须要打洞，甚至有一些防火墙十分严格的话，咱们连打洞都没方法实现，这会极大的影响服务的连通性。咱们首先要发现对方，而后要打洞，如果打洞不胜利，还须要通过直达服务器来进行媒体的传输，这个过程可能会快则几秒钟，慢则几分钟。也就是说咱们从会话开始到单方建设通信，整个过程是非常复杂、消耗十分长的工夫。
第二，带宽占用高。所有的与会者是直连的，带来的一个问题是，如果我要看到其余所有人的视频，那么每个人都须要推一路流给我。同样的，其他人也是须要接管除他以外的所有流，这时候我的上行带宽占用是十分高的。在视频会议场景下，少则十几多则二十几个人，当初几百个人的会议也是很常见的。依照咱们现行的带宽，是达不到的。
第三，编解码压力大。既然每个人的流要独自发送给其余与会者，那么也要独自编解码，要发送 N 路就要编 N 路，并且编解码压力是十分大的，不仅挪动端没方法接受，甚至咱们的 PC 端也是没方法接受的，这是它很大的一个劣势。
在咱们理论的利用场景上，如果没有服务器，那么咱们也没方法进行录制，无奈实现视频回播、鉴黄以及 CDN 散发等性能。综合思考，咱们就会发现点对点计划可能并没有很好的满足咱们以后理论的利用需要。
所以这里就要引入一个服务器计划架构，依据方才提到的点对点三大劣势，咱们来重点看看新计划是如何解决的。
连通性
通常咱们的服务器都会架构在公网上，所以各个会话者是间接跟咱们在公网上的服务器建设连贯，省掉了打洞，间接一步到位。
网络带宽占用高
假如以后咱们这个会议有四方会话，那我的与会者有三路，我只需发一路到服务器上，通过服务器把我这一路转发给其余三路的与会者就能够了，不须要再去多发两路，这样我的上行带宽就从本来的三路变成了一路了；而接收端，引入 MCU 的概念，为了节俭上行带宽，咱们能够将这三路混流，再转发给我，那么我的上行也只有一路。
编解码压力小
通过优化架构带宽，编解码从原来的 N 路变成一路，也同步缓解了编解码压力。
既然服务器能更好的满足咱们的理论利用，那么 WebRTC 服务器应该怎么进行架构设计呢？开发 WebRTC 服务器须要哪些技术以及可能会面临哪些难点？WebRTC 服务端 QoS（服务质量）的实现及优化有哪些重点要留神的？
篇幅关系，对于《WebRTC 服务端工程实际和优化摸索》的残缺内容，大家能够通过咱们的流动材料包获取，材料包中还有视频回放、演讲 PPT 等材料。申请流动材料包链接 https://www.wjx.top/m/9757900…。
