五个方面来给大家介绍CCtalk

关于CCtalk

CCtalk是沪江旗下的支持互动教育平台，它提供网师服务，支持老师签约入驻，拥有基于云，大数据和AI的个性化课程推荐，同时也支持社群化学习，可以通过课前预习，课后答疑和视频回放等来沉淀学习用户，而且还有非常丰富的教学工具，包括实时多向音视频服务，双向白板，屏幕分享，讲义，教学小工具等等。

今天我会从五个方面来给大家介绍：

1，主流直播方案介绍

2，客户端AV引擎

3，服务端架构演进

4，录制回顾以及旁路推流

5，高并发场景案例分析

1、主流直播方案

主流的直播方案，我把它分为四类：RTMP，HTTP-FLV，HLS和RTP

下面介绍一下各自的特点：

1）RTMP

RTMP的优点是CDN加速成熟，成本低，可用的开源库，以及开源工具比较多，延迟一般在2到5秒。

2）HTTP-FLV

HTTP-FLV的原理是服务器在响应HTTP请求时候，不返回Content-length字段，它使用HTTP协议来实现，不容易被防火墙拦截，延迟略低于RTMP，但都是秒级的。

3）HLS

HLS的优点是CDN分发容易，成本低，可以在HTML5页面中直接打开观看，但它延迟一般大于12秒。

4）RTP

RTP一般是各家自研，相比于传统的直播方案来讲，自研方案不支持CDN加速，且成本贵，延迟一般是200到800毫秒之间。

2、客户端AV引擎

教育直播-CCtalk是基于RTP协议自主研发的，它的传输层支持UDP和TCP两种方式，支持网师之间以及任意观众之间的连麦互动，连麦延迟和观众延迟都是毫秒级的，同时它支持PPT，白板笔，答题卡，文字等多种不同形式的教学互动。下面介绍CCtalk的软件架构图：

从图中可以看到，所有的客户端与信令系统之间有一个TCP长连接，来实现PPT、白板笔、答题卡、文字聊天等等教学相关的小工具；所有的用户与媒体服务之间有一路TCP或UDP的连接，实现老师与学生之间的双向实时音视频互动，比如说老师上课的时候，将产生的实时音视频数据发送到媒体系统，媒体系统按照一定的路径将媒体数据发送到学生端；如果学生端也上麦了，那么学生端产生的音视频数据也会经过媒体系统转发到老师端，这样就完成了一个教学场景下的双向音视频互动。同时，媒体服务会旁路推流一路RTMP到CDN，学生端可以在HTML5网页里直接观看实时单向直播，这样就满足了在大型直播中网页传播的诉求。另外媒体服务器会将上课时产生的音视频数据发送一路到录制服务，同时信令系统会将上课时产生的PPT、白板笔以及文字聊天等内容发送一份到录制服务，录制服务收到所有上课内容后，将它们以元素的形式存储下来，存储下来的这个格式叫做OCS回顾，便于课后回顾。

因此教育直播架构须具有的以下特性才能满足需求：

而CCtalk就是这么一个支持多种教学工具的实时大规模并发教学平台。在最开始实现这个平台的时候，我们采用了一些开源方案，如webrtc，但后来发现直接使用开源方案无法为完全满足教育直播的需求，因此我们自研发了一套客户端AV引擎：

下面我会针对引擎的网络部分做一个简单的介绍，主要介绍用到的几个关键的技术。首先思考一个问题：当客户端在使用媒体引擎的服务时，需要做的第一件事是什么呢？

答：需要找一个网络质量较高的边缘节点接入。

如上图所示，假如我们有一百个边缘节点，用户需要从这一百个里面选一个到他的网络质量较高，那么该如何选择呢？可能你首先想到的是DNS解析，但其实只靠DNS解析是不够的，我们还需要一套自动寻路机制，如下图所示：

以小网络为例，它的每次DNS解析的结果可能是变化的，我们无法保证它寻到的结果一定是最优的。当用户接入到边缘节点之后，在使用过程中，用户的网络在不断变化的，因此我们还需要有一个动态检测的机制，如果引擎检测到网络波动较大的情况，那么需要再次启动自动寻路机制，再给它找一个网络质量较高的边缘节点接入。此外，由于网络一直在变化，为了适应这种不断变化的网络，我们还需要一套拥塞控制机制，在这里我推荐Google的GCC拥塞控制算法：

这个拥塞控制可以分为发送端基于丢包的网络估计，以及接收端基于延迟的网络估计两部分，总结下来，就是根据丢包率以及延迟控制发送端的码率。除此之外，当我们的码率开始降低的时候，是不能一直降低下去的，因为码率降低意味着音视频质量的下降。我们还需要另外一套补充机制，叫做消峰处理：

消峰处理的原理是将比较大的数据分成若干个包，在一定时间内发送出去。但这会带来延时的增大，因此需要控制发包的间隔大小。最后，当数据在传输当中由于误码等因素导致丢包时，我们还需要丢包重传的机制来进一步的提升网络的质量。总结下来，其实整个客户端引擎的网络部分，其实就是在做一件事：在实时性与质量之间权衡，而且这个权衡具有一定的自适应能力。

3、服务端架构演进

这张图的上半部分在前面已经介绍过了，就是客户端的引擎部分，下半部分是对应的媒体服务器的一些功能。最初的CCtalk服务系统是由第三方提供的，开发简单，成本低，但确实存在一些问题。后来我们自主研发了一套服务端体系，架构如下：

这个架构分为两大部分：信令系统和媒体系统，整个架构中的所有服务设计功能单一、结构简单，并且所有节点支持线性扩展，理论上它能承载的人数是没有上限的，你只要加机器就可以了，所有的节点支持失效自动转移，这套系统我们用了很长一段时间，但在使用的过程中还是发现了一些问题，以媒体系统为例，首先一个是问题是存在中心节点，这就意味着所有的数据都要先经过代理节点转发到中心节点，再发送到代理节点，最后发送到学生端，并且这个路径是固定的，所有的数据都要走这么长的路径，此外，系统之间有一定的耦合。为了解决这些问题，重新设计了新的媒体架构：

首先，我们把信令系统与媒体系统之间解耦，也就是说他们之间相关的操作如加入房间，建立房间，全部放在客户端的AV引擎去实现；另外，我们去掉了中心节点，加入了转发节点的概念，所有的转发节点都是对等的，并且转发节点会将收到的音视频数据通过一个智能寻路算法自动找一条最优的路径。

整个媒体系统设计原则有两点：一是尽最大的可能找一条最优的路径，将数据尽快的发送到对端；二是在服务出现问题的时候，尽量的保证服务的可用性，并且让用户没有感知。

4、录制回顾以及旁路推流

下面讲一下录制回顾以及旁路推流，架构如下：

具体如下，当 Server收到指令以及数据时，会将音视频数据发送到服务端的音视频引擎，服务端的音视频引擎会对这些数据做一些处理，压缩成一个大视频，将大视频存成MP4，并保存到云端，同时，将这个实时的视频流以RTMP的形式推到CDN，这样，HTML5页面就可以在线观看实时的网页直播；同时媒体录制服务器会将上课时产生的所有内容以元素集合的形式存储一份，我们把这个存储格式叫做OCS。下面就是直播或录播的流程图：

录制OCS回顾视频过程如下：

我们还有一套专门的OCS编辑器来帮助对OCS回顾进行二次编辑，编辑器可以将编辑之后的结果再次传到云端，这样学生就可以观看编辑之后的内容。

在这个过程中，我们使用的转码服务，前期用户量不大的情况下，我们使用CPU转码，单台16核的机器的并发数量可以达到40路，后面随着业务增长，对于转码集群的要求不断增大，所以我们改用了GPU转码，并发情况如下：

5、高并发场景案例分析

高并发场景的案例分析，这一部分与实际的音视频没有太大的关系，但却存在教育场景当中不得不面对的一些问题，我首先举个例子，希望能够对大家有一定的启发。我们来想一个问题：同一个教室里，有20万人同时在听课，我们会遇到哪些问题，我们该如何解决这些问题？假设有20万人在同一个房间，每个人携带的数据量是30字节（例如：用户列表、用户ID、昵称等等），假设每台网关承载三千人，那么至少需要66台网关，正常情况下，假设每秒有800人进出房间，那么负载到每个网关上就是12人每秒的瞬间吞吐，所以算下来当有一个用户进房间，那么他拉取的这个数据量就是45Mb，他进房间的这一瞬间需要拉这么多的数据，每台网关承载的实时的吞吐量是554Mb，当出现异常时，比如说某台网关宕机或者脱离了核心服务，我们的负载均衡服务会将出现的问题的至少三千人负载到剩余的64台服务上，此时的网关负载增量是46.8人，异常时的网关瞬间流量是2Gb。总结下来存在的问题如下：

1）客户端带宽消耗太大

2）进入教室慢

3）服务并发处理量太大

那么，我们的应对策略是：

1）精简信息+详细信息

2）提供数据的版本机制，在一定范围内，只处理变化的数据。