CCtalk高可用多媒体服务技术选型与实现

  • 时间:
  • 浏览:1
  • 来源:大发5分排列5_极速5分排列3

文 / 杨福强

消峰出理 的原理是将比较大的数据分成若干个包,在一定时间内发送出去。但这会带来延时的增大,否则须要控制发包的间隔大小。最后,当数据在传输当中机会误码等因素原因丢包时,亲们还须要丢包重传的机制来进一步的提升网络的质量。总结下来,真是整个客户端引擎的网络帕累托图,真是只是在 做一件事:在实时性与质量之间权衡,否则某种权衡具有一定的自适应能力。

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

下面介绍一下个人的特点:

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

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

3、服务端架构演进

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

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

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

整个媒体系统设计原则有两点:一是尽最大的机会找二根最优的路径,将数据尽快的发送到对端;二是在服务老出问题图片的前一天,尽量的保证服务的可用性,否则让用户必须 感知。

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

整理 / LiveVideoStack

如上图所示,否则我我亲们有一百个边缘节点,用户须要从某种百个上端选一另俩个 到他的网络质量较高,必须 该何如选则呢?机会你首先想到的是DNS解析,但真是只靠DNS解析是过高 的,亲们还须要一套自动寻路机制,如下图所示:

具体如下,当 Server收到指令以及数据时,会将音视频数据发送到服务端的音视频引擎,服务端的音视频引擎会对哪好多个数据做只是在 理 ,压缩成一另俩个 大视频,将大视频存成MP4,并保存到云端,一块儿,将某种实时的视频流以RTMP的形式推到CDN,曾经,HTML5页面就还能否 在线观看实时的网页直播;一块儿媒体录制服务器会将上课时产生的所有内容以元素集合的形式存储一份,亲们把某种存储格式叫做OCS。下面只是直播或录播的流程图:

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81124938

3)服务并发出理 量过多

亲们还有一套专门的OCS编辑器来帮助对OCS回顾进行二次编辑,编辑器还能否 将编辑前一天的结果再次传到云端,曾经学生就还能否 观看编辑前一天的内容。

2,客户端AV引擎

必须 ,亲们的应对策略是:

1)RTMP

1)客户端传输数率消耗过多

在某种过程中,亲们使用的转码服务,前期用户量不大的情形下,亲们使用CPU转码,单台16核的机器的并发数量还能否 达到40路,上端随着业务增长,对于转码集群的要求不断增大,只是亲们改用了GPU转码,并发情形如下:

2)HTTP-FLV

下面我会针对引擎的网络帕累托图做一另俩个 简单的介绍,主要介绍用到的好多个关键的技术。首先思考一另俩个 问题图片:当客户端在使用媒体引擎的服务时,须要做的第一件事是哪好多个呢?

今天我会从俩个方面来给亲们介绍:

某种拥塞控制还能否 分为发送端基于丢包的网络估计,以及接收端基于延迟的网络估计两帕累托图,总结下来,只是根据丢包率以及延迟控制发送端的码率。除此之外,当亲们的码率开始英语 降低的前一天,是必须时不时降低下去的,机会码率降低原因分析音视频质量的下降。亲们还须要另外一套补充机制,叫做消峰出理 :

高并发场景的案例分析,某种帕累托图与实际的音视频必须 过多的关系,但却发生教育场景当中不得不面对的只是问题图片,我首先举个例子,希望并能对亲们有一定的启发。亲们来想一另俩个 问题图片:同一另俩个 教室里,有115万人一块儿在听课,亲们会遇到哪好多个问题图片,亲们该何如出理 哪好多个问题图片?假设有115万人在同一另俩个 房间,每我个人携带的数据量是200字节(类事:用户列表、用户ID、昵称等等),假设每台网关承载三千人,必须 大约须要66台网关,正常情形下,假设每秒有2000人进出房间,必须 负载到每个网关上只是12人每秒的瞬间吞吐,只是算下来当一另俩个 用户进房间,必须 他拉取的某种数据量只是45Mb,他进房间的某种瞬间须要拉必须 多的数据,每台网关承载的实时的吞吐量是554Mb,当老出异常时,比如说某台网关宕机机会脱离了核心服务,亲们的负载均衡服务会将老出的问题图片的大约三千人负载到剩余的64台服务上,此时的网关负载增量是46.8人,异常时的网关瞬间流量是2Gb。总结下来发生的问题图片如下:

HLS的优点是CDN整理容易,成本低,还能否 在HTML5页面中直接打开观看,但它延迟一般大于12秒。

而CCtalk只是必须 一另俩个 支持多种教学工具的实时大规模并发教学平台。在最开始英语 实现某种平台的前一天,亲们采用了只是开源方案,如webrtc,但如果发现直接使用开源方案无法为全版满足教育直播的需求,否则亲们自研发了一套客户端AV引擎:

以小网络为例,它的每次DNS解析的结果机会是变化的,亲们无法保证它寻到的结果一定是最优的。当用户接入到边缘节点前一天,在使用过程中,用户的网络在不断变化的,否则亲们还须要一另俩个 动态检测的机制,机会引擎检测到网络波动较大的情形,必须 须要再次启动自动寻路机制,再给它找一另俩个 网络质量较高的边缘节点接入。此外,机会网络时不时在变化,为了适应某种不断变化的网络,亲们还须要一套拥塞控制机制,在这里我推荐Google的GCC拥塞控制算法:

2)进入教室慢

3,服务端架构演进

首先,亲们把信令系统与媒体系统之间解耦,也只是说亲们之间相关的操作如加入房间,建立房间,全版上放客户端的AV引擎去实现;另外,亲们加上了中心节点,加入了转发节点的概念,所有的转发节点也有对等的,否则转发节点会将收到的音视频数据通过一另俩个 智能寻路算法自动找二根最优的路径。

这张图的上半帕累托图在前面机会介绍过了,只是客户端的引擎帕累托图,下半帕累托图是对应的媒体服务器的只是功能。最初的CCtalk服务系统是由第三方提供的,开发简单,成本低,但真是发生只是问题图片。如果亲们自主研发了一套服务端体系,架构如下:



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

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

 

1,主流直播方案介绍

否则教育直播架构须具有的以下社会形态并能满足需求:

RTMP的优点是CDN加速心智成熟的句子的句子期图片 图片 图片 图片 期期的句子,成本低,可用的开源库,以及开源工具比较多,延迟一般在2到5秒。

1、主流直播方案

1) 精简信息+全版信息

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

5,高并发场景案例分析

答:须要找一另俩个 网络质量较高的边缘节点接入。

关于CCtalk

某种架构分为两大帕累托图:信令系统和媒体系统,整个架构中的所有服务设计功能单一、社会形态简单,否则所有节点支持线性扩展,理论上它能承载的人数是必须 上限的,你否则我加机器就还能否 了,所有的节点支持失效自动转移,这套系统亲们用了很长一段时间,但在使用的过程中还是发现了只是问题图片,以媒体系统为例,首先一另俩个 是问题图片是发生中心节点,这就原因分析所有的数据也有先经过代理节点转发到中心节点,再发送到代理节点,最后发送到学生端,否则某种路径是固定的,所有的数据也有走必须 长的路径,此外,系统之间有一定的耦合。为了出理 哪好多个问题图片,重新设计了新的媒体架构:

2) 提供数据的版本机制,在一定范围内,只出理 变化的数据。

3)HLS

2、客户端AV引擎

本文来自沪江技术中心开发经理杨福强在LiveVideoStackCon 2017上的分享,并由LiveVideoStack整理而成。杨福强于2012年加入沪江,主要从事教学互动平台CCtalk的开发,今天他将为亲们分享高品质教学平台的只是技术难点和出理 方案。

4)RTP

5、高并发场景案例分析