为了满足用户量较大且低延迟的需求，针对这种场景七牛云 RTC 提出了新的低延迟解决方案，从「RTC+CDN」模式改为用户直接使用 RTC 的方案，在大大降低用户延迟的基础上，也满足了多用户加入房间的需求。
在「音视频实践日 Live」直播活动中，七牛云音视频资深开发工程师 张卓，为我们就「万人大房间低延迟技术方案实现」话题带来分享，重点介绍了大房间低延迟技术方案对比，大房间信令网关建设和大房间流媒体网关介绍
本文内容基于张卓分享整理，为方便阅读略有删改。
直播间的观众朋友们，下午好。我是七牛云音视频开发工程师，现在主要负责 RTC 产品这块业务。今天我给大家分享的是七牛云在大房间低延迟技术方案的实现。
围绕这个主题，我们分三块内容展开： 第一、大房间低延迟方案对比；第二、大房间信令网关建设；第三、大房间媒体网关介绍 。
一、大房间低延迟方案对比
我们先定义一下大房间。我们知道 WebRTC 主要是用来端到端通话的，当然我们也可以通过 SFU 中转来做一个视频会议场景。但是这种房间一般情况下房间人数不会太多，可能几十个人已经到顶。我们这里说的大房间，一般要求的可能是人数超过上万的情况。
比如，职业教育培训场景。如果培训机构需要的话，可以在全国范围内招比较有名的讲师，然后再对全国的教育培训的网点做一个视频直播。这样，一旦人比较多的话，传统的这种 WebRTC 加入房间，连麦的情况可能就不太适用了。
再比如，我们一个集团，全国都有分公司，如果开集团会议的情况下，我们也不可能说让所有的员工都进入同一个房间连麦，这种也实现不了。
所以我们这里说的大房间概念，一般指的是一个房间人数一定要多，比如说超过几千人，上万人。另外一个就是这个大房间不是所有人都可以发布的，解决的场景是把一部分人的音视频推出去，就是一小部分人推流，绝大部分人拉流的这种情况。
在业内，我们用的比较多的方式，一般是「WebRTC+CDN」。就是几个人连麦，我们可以用 WebRTC 方式做连麦，连麦后的音视频通过 CDN 转出去，这样所有的客户端通过 CDN 去拉流。这个方案现在是比较成熟的一套方案，一方面 WebRTC 本身连麦功能比较成熟，另外 CDN 节点做的比较成熟。
但是这个方案存在一个缺点，存在一定的时延。而且如果是多人，或者如果每个人想看到自己独特画面，这个是实现不了的。因为多人连麦导致出现的画面，首先要经过把多人的画面合成一路流转播出去，没办法针对每一个人，提供一个个性化的展示。
我们在实现大房间的方案是通过「WebRTC+SFU」，也就是 RTC+转发节点的方式。
我们可以对这两种方案做一个对比。如果我们用「WebRTC+CDN」这种方式，优点是能够支持很多人，因为对于 CDN 来说，客户端都通过 CDN 去拉流，那么限制它的只有一个带宽，只要这边厂商的带宽没有啥问题，拉的人数一般不成问题。
但是它也有一个缺点，就是单人直播的时候，直接把这个人的音视频流推出去就可以了，那么如果是多人的情况下，我们可能需要针对自己的业务场景做一次合流，可以在客户端，也可以在服务端去做合流，再把这个流转推出去。所以它中间经转的流程就是先连麦，再合流，再 CDN，再拉流。经过以上四步以后，延迟可能会稍高一点。
如果我们用「WebRTC+SFU」这种方案，第一我们只需要限制一下上麦的人数，具体拉哪些流，可以看每个人的需求，只需要去订阅就可以了，这样就不需要去做合流的操作。也就是每个人根据自己的业务需求去定不同人的视频流。但是这也有一个缺点，传统的 SFU 节点，没有办法承接一万人以上的拉流。这个方案优点就在，如果我们直接使用 RTC 这种方案，延迟会比较低。
所以对比这两种方案，一个延迟稍微高一点，但支持人数比较高，如果我们用 RTC 方案，延迟会比较低，但是对拉流的人数，传统的 SFU 没有办法支持上万人的拉流。所以针对这个，七牛云做了自己的一些优化。
二、大房间信令网关建设
1、大房间信令网关-原架构
我们之前连麦是正常一个用户进来以后，会给它一个房间，就是用户会开一个房间。房间的用户可以相互连麦。首先第一个用户进来以后，会有一个选点的问题。一个用户进来选完点之后，其他用户只要是一个房间，所有的用户都落到同一个 server。这样的话，这台机器的 server 就可以对连上的用户做一个转发。A 用户发的所有的信令消息，同一个房间内的所有用户都可以收到，房间内的其他用户的信令消息，也都可以通过服务转发给所有人。
2、大房间信令网关-原架构问题
这个方案却存在一定的问题。第一个，就是受限于单节点能力，处理能力有限，无法支持大房间。第二个，就是调度能力问题，我们没办法提前知道这个用户分布情况是怎样的，只能确保第一个用户就近，无法保证房间内几方均衡。最后一个，就是抗弱网能力差，依赖加速节点的部署情况。
3、大房间信令网关-新架构
针对上面说的几种问题，如果要实现万人进场的情况下，我们对之前的架构做了一些调整。第一个调整的点是解决调度问题，我们专门搞一个调度的服务。用户进来之前，先会到调度服务上去选取节点，请求调度服务，然后让调度服务分配一个节点。第二，我们对之前单节点业务服务做了拆分。拆分成两块内容，一个是网关，一个是业务处理集群。网关这块主要负责用户的连接。业务集群这块处理跟之前差不多，存储用户房间内的信息。
我们先看调度，调度服务器负责将用户分配到最近节点，解决的主要是就近接入的问题。再看网关，网关负责用户信令和媒体的接入。而业务服务集群，则进行业务逻辑处理和相关信令的转发。
4、大房间信令网关-调度
我们这个调度服务主要做的是针对单用户来说的，我们理解的就是通常情况下，如果用户跟机房的物理距离比较短，本身网络情况也会比较好，用户一旦上来后，请求调度服务的时候，我们能够拿到对应用户的 IP 情况。我们会通过 IP 和 IP 地址库，查找用户所在地区，拿到对应的位置信息。
除了拿到位置信息外，依赖另外一个 IP 质量的数据库，这个质量数据库存储的信息主要是某一个地区，到我们某一个节点的网络情况。这个数据来源有很多种，第一个就是我们通过 SDK 上报，能够实时知道网络情况。另外一方面，我们还有第三方特殊测速工具，针对服务器做测速，来拿到服务器的质量数据。有质量数据之后，我们 IP 数据库拿到对应的地区，再从质量数据库里面挑选出节点比较好的节点做一个排序。这就是服务端的情况。
在 SDK 端上，支持对服务器节点测速选点，并发建立连接，选最快的接入。
调度这块做完之后，我们就能够把用户分散到全国不同的信用网络的节点上。
5、大房间信令网关-拆分
关于服务拆分的情况，我们之前所有服务都是在一起的，也就是转发服务上面，服务器上部署的转发单元，还有业务处理单元。业务处理单元那块，包括信息的存储，用户进来、退出、验证信息。针对这块信息我们发现其实它是不经常变更的，所以我们针对这块信息做了一个拆分，直接把这块信息调到网关层。
就服务集群，主要是做了以下几点：第一个就是全量信息做的集群，我们在服务器这块，会有一个全量的存储，对房间的所有用户信息全量保存。另外一方面，网关上有一些业务信息需要通过服务器进行转发，比如说用户进来之后，我们会把消息通知到集群里，然后集群再中转到所有房间用户，然后 Push 到 SDK。此外，我们还对外承接了一些业务接口。
6、大房间信令网关-角色
刚才我们说到除了对业务节点做一层处理，我们对用户的角色也做了一层处理。正常情况下，我们 WebRTC 进来之后，都会进行订阅和发布。如果真要实现万人房间的话，我们没有办法所有人进来都推流、拉流，所以针对这种情况，我们对用户做了一个角色拆分。第一个正常的情况下，如果需要推流的用户，会有订阅和发布的一个权限。如果其他用户他只能订阅。如果是有发布和订阅权限的，这种人我们把你加到主播类型的，或者是有发布类型的一个人。然后另外一方面我们就直接叫他订阅用户。
我们在处理的过程中，一般如果是主播类型的用户进来之后，会把对应的数据同步到我们业务处理服务器上，通过业务服务器中转给所有这个房间内的信令网关和推到各个用户那里去，这样他们的流和所有的信息，其他用户都能够拿到。但是针对订阅用户，我们只让他连接到对应的网关，不请求中心节点去做处理。这样的话，整个中心节点，对于这个房间的处理，会变得相对简单一点。连上来的这种订阅用户，他是可以接收到所有主播的信息的，他也可以知道所有流的情况。
7、大房间信令网关-优势
总结起来，大房间信令网关的优势在于：「拆」，第一步就是把功能节点拆分，针对万人进房的情况，解决单点容量的情况。「调」，通过我们的调度选线，保障每一个用户都能就近接入，解决弱网问题。「拆」，针对用户角色的拆分，解决消息通知问题。
三、大房间媒体网关介绍
1、媒体网关架构
我们之前媒体网关，就是单节点，所有的人连到同一个 server 拉数据。那么现在拆分网关之后，因为用户登录的是一个不同的网关节点，所以他没办法做到连接同一个媒体节点。假如说连到边缘节点服务器上没有对应流，那么这个时间我们如何把流给转过去，这是一个问题。首先我们推流的用户，还是把自己的流推到对应的一个网关节点，一个边缘节点上。
那么其他用户在其他网关节点上，我们怎么去订阅？首先他连上来之后，他也会去进行订阅操作，他会先看下自己对应的边缘节点上，到底有没有自己需要的流。因为流上来之后，主播类型会推到所有人，那么他拿到这个流来订阅的时候，发现自己对应的边缘节点没有。没有这种情况下，如果当前节点已经有需要的流，直接进行订阅拉流操作；如果当前节点没有，看当前机房是否有相同的流，如果有机房内订阅；如果机房都没有，向路由节点进行订阅。
如果万人实现的话，我们可以使用几个机房边缘节点，都能够支持一个上万人的连接，所以效果还是可以的。
2、媒体网关架构规划
关于万人房间，我们后续还会有一个持续优化过程，大概分这几个方面。首先最主要的还是选线问题，解决使用过程中网络不稳定情况下网络选择问题。
关于媒体转发策略这块，就是我们现在媒体转发策略，也会持续优化，比如说就近接入，或者是找一个最优的转发路径。我们也会利用更多的数据，来选择一个更优的转发路径来减少空间转发或者拉流的策略，从而提高拉流的效率。
另外一方面，信令网关这块，我们接下来准备配套 Quic 协议，之前我们处理得比较多的是媒体。针对信令这块，也会加上其他的信令协议支持，一方面除了支持更多协议便于不同场景下 SDK 使用 ，也会利用其他手段，提升信令抗丢包。
最后，是大量边缘节点的部署，在全国部署更多的节点，支持更多地区的就近接入问题。
我今天的分享，就先到这里，谢谢大家。
