摘要：相较于秀场类直播，在线教育直播对于直播过程中的互动需求更高，如何用WebRTC实现多人的连麦，如何将多对多高实时模型与一对多高承载模型相结合，如何实现互动白板与文档，将是本次分享讨论的重点。
演讲 / 唐通
出处 / LiveVideoStack
各位下午好，我是CC视频的唐通，先简单介绍一下CC视频，CC视频成立于2005年，实际上做视频领域已经整整11年了，我们公司的目标和愿景主要是为企业提供场景化的视频解决方案，这里面“场景化”就比较关键了，可能是因为我们深入到一些垂直的领域，比如说教育、金融、互联网，今天我主要会聊一些教育方面的，比如说我们在教育方面一些代表的客户，大家都熟知的像新东方、华图，还有类似高顿这样一些客户。
今天的分享主要围绕着三个关键词——在线教育、场景化和互动，我分享的这个标题，也是我们直播中的一些混合互动模型，刚才百家云张总和布卡互动另一位张总，他们都分享了一些教育直播的方方面面，但我的分享侧重点有所区别，我会着重讲一下互动。
这是我分享的一个目录，首先我们先由需求出发，讲一下教育直播用户他有什么诉求，然后依次来讲几种互动：视频互动，文档和白板的互动，还有我们的一些信令服务如何来架构，以及未来我认为的教育行业的一些趋势、教育行业直播的一些趋势。
教育直播的用户诉求
首先是教育类直播它的用户诉求，直播的技术架构需要什么？因为刚刚我们一直在讨论直播，这里可以捋出很多词来：可扩展、网络适配、高并发、开放、实时、可运维、低延迟、服务化、高可用，还在这里着重的写了一个稳定，这些可能是我们一般通用直播技术架构的一些特性，但对于教育类直播来说，我认为有一点是非常重要的——也是直播相较于比如点播的一点，核心的区别就在于互动，就是让老师和观众能互动起来，能让课堂不像点播那么枯燥。
1.连麦互动
在互动方面，我们都有些什么？首先是连麦，它的一些场景，像教学答疑，有些学生上完课之后还有些疑问，他就会需要答疑，再比如我们的双师教学，这个场景的难点在于实时性和跨平台，这样的教育场景可能使得我们做2B业务跟2C的不太一样，2C业务可以规定几个平台，但我们做2B业务是一定要做到全平台，全平台刚刚也有分享，就是我们常用的那六大平台。
2.文档和白板互动
其次是文档和白板的互动，我们上课的时候肯定要有课件，需要在上面勾勾画画，这样能让老师教学更容易，学生也能更容易理解，这个场景就是我们课件的一些教学，还有白板的一些互动。这部分的难点在于一个同步性，还有回放的留存。
3.其他互动
此外还有一些其他的形式互动，比如我们还能设置抽奖，它是为了能够活跃课堂气氛，还有像签到，像答题等等，这些我就不一一列举了。这些场景主要是帮助我们来做一些教学质量的评估，也就是我要知道这节课的签到率是多少，有多少人没在，比如说人并不在电脑前只是开视频挂机，我一签到肯定就被抓出来了。说了这么多种互动，实际上这一切都是为了我们要做到一个事——达到在线教育也要做到身临其境的上课体验，就是要让他感受跟在线下课堂一样的体验。
视频互动
接下来我会具体分享一下这几种互动是怎么来实现的，这里可能更多的会从架构上来做分享，也是我们一路走过来踩的一些坑。视频互动的协议和框架，我们最早尝试过用RTMP来进行连麦，后来我们使用了WebRTC，还有一些私有协议，大家都知道RTMP是基于TCP的，用它来做连麦，延迟是比较大的，而WebRTC是完整的一套方案，但它有很多信令交互的地方是比较麻烦的。在视频互动模型的选择上，有网状模型、星状模型、还有混屏模型，接下来我就着重讲一下这三种模型。
1.网状模型
实际上这三种模型我们都实践过，首先是网状模型和直播的结合，为什么叫做网状呢？实际上就是我们进来的所有人——参与互动、参与视频互动、参与连麦的所有人之间都得互相建立连接，所以它看起来就像一个网一样，这就叫网状模型。网状模型，实际上是基于点到点的，也就是没有中心服务器的这样一个模型。在这个模型里面，单个终端网络负载，大家可以很容易想到，我要把这个视频发给除我以外的所有其他人，我也要去拉取其他所有人的这个视频，如果是n个终端进入就是n-1路上行和n-1路下行，这样整个网络的负载是非常高的。第二个，如果我们想把它和直播结合起来，我们还想让互动过程让其他人看见，我们还要实现在客户端混屏，因为其他人不可能也同时来拉这么多路流，这个是一个比较乌龙的事情，所以要混屏。在PC端混屏还好一些，如果我们码率和分辨率这些比较低一些的话，PC端还是能承受的，但如果我们是在移动端，在安卓、iOS上它机器性能毕竟是有限的，混屏就会非常麻烦。基于这个的模型，如果我们想互相之间传输消息，实际上是有很多协议的，比如说RTMP是可以做的，但它不是P2P的，还有我们基于WebRTC这套架构，我们也可以做这种基于UDP的传输，当然因为我们是点对点的，还需要P2P的穿透，所以我们需要Stun和Turn这些服务器，以及中间的一些信令服务器，来发它ICE的一些信息，所以整体而言这个模型的架构比较简单，但是实际应用的效果并不是很好，是我们最早实验的一个架构。
2.星状模型
在网状模型实验过后，我们就进入到下一个模型——星状模型，星状模型中间多了一个中心的服务器，它为什么叫星状？就是相当于我们中间有一个核心、一个服务器，我们内部把它叫MCU，这是一个视频会议领域的词汇，就是一个多点控制单元，它指的是我们可以接多路视频进来，然后把相应的视频中间进行一些转发，转给其他人。这个模型跟网状模型，最大的区别就在于，我的视频不是点对点的进行传输了，视频都是先传到服务器上，其他的再去拿这个视频。最大的一个好处，它可能解决了我们P2P网络的一个连通性的问题，大家应该知道，如果我们使用P2P网络，一些小运营商它打洞是很难成功的，是会有很多坑、很多问题的，当然这个模型较上一个模型改进的就是它只用1路上行，就是我只要把我自己的传给中间这个MCU，而不用传给其他的所有端，它解决了上行的问题，但没有解决下行的问题，下行还是n-1路非常多。对于混屏而言，它还是要在客户端来完成混屏，这样的话，我们客户端处理的压力实际上还是非常大的，如果我们在安卓和iOS上想实现多人连麦，超过一个人的连麦，耗的CPU基本都是非常高的。
3.混屏模型
最后这个混屏模型，就是我们的一个服务端混屏的模型，这个模型跟星状模型很像，但它的区别在于我们把混屏的处理放到服务端来做，这个也是目前比较通用的一个方案。我们在服务端MCU会把多个参与互动的端的视频和音频进行混合，视频我们按预先的模板进行合屏，音频我们进行混音，混完之后，我们再通过RTMP推到CDN上，由CDN来进行分发，这样的话，首先我们参与互动的终端，我们能拿到的就是这个互动的视频，并且我们能承载大并发量的观看端，因为我们中间经过了CDN，CDN它能承载，它有更广的网络资源，所有终端能拿到这个合屏的视频它看的会更全。这样的模型，它是1路上行和1路下行，他解决了多个互动端之间的网络问题，也就是它不用再拉那么多路流，而且它不用再在客户端来合流，这个是一个非常好的事情，即便我们在移动端也能实现多人的的合屏连麦。
4.各模型优缺点
各自模型的一个优缺点在这总结一下，对于网状模型而言，当然是架构比较简单，我们基于现有的WebRTC做一些改动，在客户端我们实现合屏连麦就完成了，不过它存在很多缺点，比如说连通性的问题，我们需要P2P打洞，在一些小运营商、一些非对称的NAT上它是非常难通的，特别是在那些小运营商比如说宽带通这些，它本身就是在一个大局域网内的，网络负载和各个端的负载比较高，而且我们需要在客户端合屏，这就同时占用我们两个可贵资源，一个CPU，一个网络IO。星状模型它解决了上行的问题，就是我刚说它只用传一路视频到MCU上，它解决了上行的问题，不需要打洞，但还是没解决下行的问题，仍然需要在客户端来进行合屏。最后混屏模型的上下行我们都只用一路流，且不用在客户端来合屏，但是想把它做好，实际上架构还是比较复杂的，而且它不支持单独获取某一个客户端的流，也就是说我能拉倒的一定是合屏之后的流，而不是单个的，比如说我单向看某一个学生或者某一个老师的流，这个是没法实现。因此我们最终采用的方案是星状模型和混屏模型两种混用，保证既可以拉混屏后的流，又可以拉单个学生的流，而且我们混屏的这种方式还支持输出多种模板，比如说一个混屏的模板我们把两个老师混进去了，另一个混屏的模板我们把所有人混进去了，我都可以单独来拉。
5.WebRTC MCU
然后简单介绍下我们要实现一个WebRTC MCU，需要实现的一些点，我们这个是基于WebRTC来讲的，因为WebRTC帮我们做了很多事，虽然它也有很多坑，刚之前分享者也说了。首先客户端的话，我们在全国布很多接入的节点，这些接入的节点是多协议适配的，它是可以接入WebRTC，基于RTP、RTCP、UDP的这种传输，当然我们也可以接其他流媒体协议比如说RTMP，这样的话，我们在全国布上这些接入节点，它能保证我们的上行传输，我们能有覆盖，但这还需要调度。客户端，我们通过WebRTC里面的RTP、RTCP、UDP传到我们的WebRTC的接入节点——分布在全国，然后这些接入节点会把流传到媒体处理中心——我们有一个机房专门处理流媒体，在这个媒体处理中心，我们会把音频和视频分开处理，音频进行混音，视频进行合屏，处理完之后我们又混成一路，之后再进行其他的一些服务，比如说我们把混完的视频转推出去，我们转推1路RTNP到CDN，让他帮我们再做更深层次的加速，全国节点的一个观看的覆盖。还有录制的服务，比如说我们把这个视频再给录下来。同时我们业务这边，我们还有整个的一个业务中心，它会负责我们中间所有这些过程的信令的交互，因为大家知道这个WebRTC在做的过程中，它是需要很多信令交互的。此外还有调度服务，客户端请求连接，我们会基于它的IP、地域、还有ISP，我们来给它分配指定覆盖的一个节点。还有我们整个的一个机群管理，比如说哪些节点宕了；还有一些API服务。 我们这个WebRTC MCU的架构可以看到最明显的一点，就是把流媒体处理这部分和接入这部分真正网络的承载，CPU敏感的和IO敏感的这两层我们给分开了。
文档互动
接下来是文档互动，这部分内容之前也有分享过，我再来讲一下。我们做CC视频实际上是以点播起家的，2005年开始我们就一直在做2B的点播服务，应该国内是第一家，一直做到现在，种种原因，我们直播是相对起步比较晚的，可能是在15年年初的时候才开始起步，当时面临的问题就是我们怎么来在网页中展示这个文档？
1.如何在网页中展示文档？
大家都知道PPT、PDF、Word在网页里面是没法直接展示的，所以我们需要进行转码，转码我们可以转成很多种方式让它能在网页上来展示。首先是JPG，图片是肯定能在网页上展示的，SWF肯定也是可以的，这两个是我们在PC端展示的；如果想在移动端展示，我们还需要H5，就是转成HTML，还有一种方式我们直接把文档作为视频给传过来，这种方式也是可以的。所以我们中间就面临一个问题，我们如何来进行一个转换，如何让大家都能看到这个转换后的视频。
2.互动文档的架构
这个是我们设计的文档服务的架构，首先主播端，肯定是要提前把文档上传到我们的服务器，我们会有接收的节点在接收之后，通过调度分配到进行文档转换的服务器上，我们会把转换完的文档放到存储服务上，存储服务我们肯定会使用CDN的加速，让所有观众能更快速的能看到这个文档，这还只是我们能让观众看到，如果要做到同步来翻这个文档的话，实际上我们还需要依赖其他的一些信令服务，刚说了我们是要在网页上能看到这个翻页，所以我们会基于WebSocket这种方式，我们来达成一个长连接，来传输一些信令服务，之后的话，也会专门来讲这个信令服务，当然中间的话，我们肯定都会有一个中间调度中心。
3.传输面板信令的方式
我们在做教育行业的文档的时候面临这样一个问题，就是翻页如何来同步，老师嘴上说着“接下来我们来看下一页”，但是这边文档还停留在上一页，这可能因为视频的延迟，以及视频和我们翻页的信令服务，是在两个通道里面传输的，所以这两个通道想做到延迟，实际上是很难的。我们在传输信令的时候考虑过两种方式，第一种是带内传输，什么意思呢？就是我们把文档翻页的信令，直接通过音视频RTMP这个协议内部进行传输——oncuedata，可以传输一些自定义数据，这样我们就能保证翻页和视频是严格同步的，但是它也存在明显的缺点，就是在于它的兼容性，因为我们是对接的CDN厂商，目前很多CDN厂商和流媒体服务器都是不支持的，服务器在收到这样的信息时会选择直接丢弃掉，这个是很麻烦的，而且还有一点我们要做到播放器的兼容，播放器也要能识别这种消息，把它读出来做相应的事件触发，此外还有移动端H5网页，我们刚说了它是通过RTMP这种消息，当然他也可以存到FLV里面，但是如果想在H5上实现，目前还是不行的。我们考虑另外一种传输方式，也就是第二种带外传输，它是通过另外的信道——WebSocket，通过音视频之外的信道来传输，兼容性好，灵活性高，这是在多个端都可以实现的，但缺点的话，就是需要额外实现与视频的同步，也就是说我们可能需要在观看端来计算目前视频的延迟，然后来做这个延迟的显示。
信令服务
接下来说一下信令服务，大家可能看秀场直播看的会比较多一些，秀场上的互动，比如说主播做了一件很牛的事，大家就抠“666”，这个时候弹幕是会刷很多的，在这种情况下，后台的聊天服务器压力是很大的，如果一个聊天室里面同时有两万个人，三万个人，甚至十万个人，他们同时在刷666，这时候不管是我们的聊天服务器的带宽，还是观看端展示所消耗的CPU都是非常高的。在我们教育行业也会面临同样的问题，当然表现形式会不同，教育行业主要面临的一个问题就是老师在讲题的时候，它有ABCD选项，当需要学生作答的时候，所有人就会抠个A或者抠个B，这个时候弹幕的量还是非常大的，我们在这方面也做了很多的优化。
1.教育场景的聊天与信令需求
教育行业的聊天和信令的一些需求，首先是实时，我们要求在一万人的情况下，端到端的延迟要在五百毫秒之内，第二是弹性可扩展，就是在我们突发大并发的这种直播，我们要随时增加服务器来进行热扩容，跨平台和兼容性这个刚刚说了，因为做2B业务，我们需要兼容多个端，我们要跨所有的端，还有就是高可用和流量控制，流量控制就是可根据需求实时控制聊天等流量，对于我们公司也是控制成本，这个聊天的流量实际是非常高的，因为它是一个N×N的关系，这个我后面会讲。
2.信令服务的简单架构
信令服务器的一个简单架构也是分层的，跟我们音视频的架构很像，实际上我们也是有前端的一些节点来承载连接压力，这些前端节点我们也会在全国来进行部署，然后我们有后端的节点来处理一些业务，这中间会有一些消息路由，比如说会有消息队列这样的一些组件来进行消息路由，假如一个主播想和其他人说话的时候，我们会通过这个消息路由传到后端，再传到前端节点进行聊天，当然我们在后端的时候会进行存储，一个消息的留存，这样我们整个回放的功能才能得以实现，就比如说老师翻页的信息，还有学员说的一些话，这些都是要存起来的，在回放的时候，我们重新把它展现出来。在前端节点我们为了兼容多个端也使用了不同的协议，大家知道WebSocket它是H5其中的一部分，但是目前市面上还是有很多老的浏览器，像IE这些，所以我们还是需要一些其他的协议，比如说基于HEP的这种长轮询这种方式，我们来实现推送，但整体我们也有一个调度服务器，当我们前端压力过大的时候，我们直接可以增加前端的聊天节点，承载的节点，来扩展我们整个系统的负载。我们后端的节点是按业务来分的，这种划分方式也是能保证把压力给负载到不同的节点上。
3.如何控制流量？
如何控制流量？假如这样一个场景，有X人的一个聊天室里面同时有Y个人在群聊，就像一个漏斗一样，进入的可能是那Y个人聊的信息，但是我要给所有的X人都群发，如果不进行任何优化的话，就是X*Y，这就是聊天流量大的一个原因，就是它是一个乘积的关系。当然我们就需要考虑其他的一些技术方案了，就比如说我们分为N个桶，分桶是什么意思？就是我们把这X人按照它用户ID的哈希再进行分桶，把某些人分到一个组里面，这样在一个聊天室里面我们又分成很多小组，每个小组内部的人聊天是互相可见的，但是组和组之间他们聊天是不可见的，这样我们分成N个桶，相当于把出口缩小了，他们之间总的消息就变成X*Y/N。然后我们还可以再进一步的优化，就是以M的几率再来一个丢弃，当然这个丢弃不能丢的太狠，因为丢太狠的话可能就被发现了，我们丢弃的话，一定还是要给被丢弃的那个人把这个消息发过去，让他以为这个消息发到了，当然我们的丢弃不是随时开启的，是当我们这个聊天室的人数，比如说超过一万人，我们觉得这个一万人在线聊天的话，这种常场景我不知道大家经历过没有，实际上是没有多大意义的，我们就会再以M的几率去丢弃从而去控制流量。
未来趋势
最后讲一下我认为未来的一些趋势，首先一个趋势就是轻端与重端的分化，一些小班课的教育，我觉得以后可能会越来越轻，我觉得像基于WebRTC或者基于浏览器的一些功能就能完成小班课的教学，所有老师和学生都不用下载客户端去安装，这里面还是存在兼容性和跨平台的一些问题；但是对于一些K12的教育，比如说刚才张总分享的K12的一些教育，他会和硬件进行深度整合，就像我刚提到的双师课堂、还有的全景课堂的产品，这部分是往重端来走的。第二个趋势是从Flash到H5，因为教育行业说实话相对比较土一些，很多还在用PC来看，因为Flash正在走下坡路，一些浏览器目前也正在为难Flash，而且IE的市场份额越来越小，大家知道目前我们视频播放，大部分都还是播放的FLV这个协议，FLV还是Adobe的协议，但是我们知道Flash在走下坡路，它总有一天会死去，新的一些H5的播放技术正在崛起，比如说像bilibili分享的一个flv.js，它就生成基于用原生H5我们就能播flv，flv当然是目前我们CDN支持的最广的一个播放格式。双师教育，就是名师进行网络直播授课，现场再辅以助教进行互动，刚刚张总已经分享了很多。需求的话就是实时的视频互动，以及与硬件的深度整合。好了，这就是我分享的全部内容，谢谢大家。
