怎样支持万人直播在线教室?

248

说到线上这个事啊,仔细想想,特别是在近几年对我们的生活简直带来了天翻地覆的改变。


你的一天可能是这样的:早上起床,收拾一番之后出发上班,在路上煎饼摊排队买个早餐,结账的时候拿出手机对着老板贴出的二维码扫码付款,在地铁上,拿出手机逛下淘宝,看看自己喜欢的衣服,想起来自己已经好久没有去实体店购物了。到公司,参加一场线上视频会议,你的与会者正在美国的办公室里与你沟通。晚上回到家,你的孩子正在用布卡直播听一堂名师课。等等。。。。


这些我们已经熟悉的不能再熟悉的场景,其实在前几年对于大部分人来说还是不适应的,一方面是人们对新事物的持观望态度,另一方面是技术局限性,导致一些东西的用体验并不太好,就拿在线直播来说,在线课堂的好处显而易见,但是显而易见的问题也不少。比如如何在改变真实课堂空间的情况下,最大程度实现在线情境的交流互动,还原课堂应有的人性温度?比如如何实现几千人甚至万人的低时延互动直播?这真是产品研发面临的难点。


难点即痛点,破解痛点就要不断升级技术。做好在线直播系统,就是直击痛点。


我们来听一听布卡互动创始人张玺对于布卡互动的技术解读:


教育互动直播平台的基本能力


在线教育领域这几个事情都是要干好的,包括媒体、信令。信令这个有点特殊,在一般的娱乐直播中是用不着的。另外,文档PPT、共享、画笔等要求特别高。最后,教育对录制和点播也是要求特别高。



对在线教育而言,服务需要覆盖六个端,一个端都不能少,在娱乐直播领域很少覆盖这么多,一般没有人在做PC端和Mac端。现在大部分老师在上课的时候,还是用PC和Mac,因为PPT等课件都在电脑里,毕竟手机的屏幕还很小。因此我们花了大量的时间在PC和Mac上。


不卡


音视频传输方面,布卡核心是用的UDP,自己设计了一套基于UDP的低延迟解决方案,大概延时在两百毫秒以内,一来一回两百毫秒以内。音频抗丢包,大概在30到50,视频丢包在10%到20%是看不出来的。信令是控制一些命令,比如说让谁上台发言,让谁下线,把谁踢出去,还包括文档翻页、画笔同步。文档是传PPT实现,实际上是要把文档转成别的格式才能同步分享,否则一个正常PPT是分享不出去的。录制点播就比较简单了。



1,协议与开发语言


协议要选对。如果用TCP玩音视频,就肯定会卡的,所以要用UDP。如果是单向直播,用TCP也好,其实是无所谓的。想低延迟和稳定传输的话,建议还是用UDP。语言,要选一个比较好的语言,性能比较高。比如多线程,包括大并发上来能抗的住,一百个并发和一万个并发,服务器的表现是完全不一样的。

 

网络传输我们用了三种协议,UDP+RTMP+HLS,所有的上传都是用UDP。在服务器把H.264和ACC转成RTMP和HLS,就可以透过网页上去看,并可以把它录制下来。视频的编码器,H.264和H.265我们都支持,我们还做了一个硬件,一个小盒子,专门把编码器独立出来,因为我们发现一个问题,现在普通的PC编个1080P高清的视频,特别是现在教育做得比较火的这种双视直播,他们实现的大部分方案是拿思科的视频会议方案去搭的,成本比较高,如果是使用一个小盒子,相当于一个外置编码器一样,它能够编H.264、H.265的高清。

 

我们的音频编码是用的OPUS+AAC,实际上核心是用的OPUS,因为网页里是不支持OPUS的,我们在Server端做了一下转化,就把OPUS转成AAC了,整个这么搭起来的,这么搭起来以后,你可以说去做多人连麦,包括网页直播,各方面的都可以支持了。

 

语言方面我们是C++和GO混合来开发的,整个音视频的处理是C++,GO负责一些业务逻辑,包括集群、调度。最核心的音视频模块,是用C++去写的。用GO开发的好处是效率比较高,并且多线程比较好用,第三出了问题比较好找。我们第一个版本是用C++写的,但是多线程的实现,没有个十几年功底的C++工程师是Hold不住的,经常崩溃。

 

2,调度和网络


这也是一个很头疼的话题,原来我们想当然做了一个简单的测速,发了几个包出去,谁给我回的快,就连谁。实际上不是这样,现在你的包回来的快,不代表你的丢包率比较低,在实际的连接成功之后的表现是不一样的。其次,运营商的选择。因为存在很多中美之间的教学,跨国的连接也是比较复杂的,怎么去调度?我们现在是测速和调度是合起来,比如判断你是电信的运营商,我给你返回一组,基于地域能覆盖的一组服务器,再进行测速,测速最关键的一点是丢包,音视频的卡顿,延时稍微大一点是没有关系的,只要包不丢,就不用去补,听起来就比较好了。另外,每一次我们测速的时候,都把数据给收集上来了,后面就做了个算法,不断的去优化,包括中间我们也会收集一些数据,看在这个地域下的这个用户连上这个服务器,它的性能怎么样,不断去优化这个调度策略。我们遇到一个小运营商的问题,同行也都遇到了,像长城宽带、电力猫这种网络也不知道什么情况,是从哪拉来的。小运营商的出口就很小,我们在上课的时候,基本上是晚高峰,卡顿率就特别高,这是比较头疼的。


总结下来的策略包括,第一,运营商。让电信连联通的话,肯定效果好不了,你得把它弄到一个运营商里去。第二,地域。说实话,不是一个决定性的维度。第三,服务器负载。因为我们做音视频不可能是一台服务器干活,有好多台服务器,当用户上来以后,把它分配到哪一个服务器上去,是需要看服务器的负载的,CPU、内存、网络如果是已经满负荷了,继续分配过去,肯定也会卡。第四,测速。我们发现把测速做好了优化,还是能解决很大的问题的,我们实际测一下,你今天连着这个服务器好,明天他连就不一定好,互联网这个网络老是变化的。

 

3,重传+补包+动态网络调节


从软件上能做的补救就是重传+补包,在音频和视频上有很多算法。特别是音频,丢了一些包以后,通过调整一些策略,前后拟合后用户也听不出来,我们上课主要是声音,把这个做好了,其实也能增加音视频的流畅度。



动态网络调节还是一个蛮有意思的一个事,当一个听众说,觉得我这边网络接受不了,我本来是500K的带宽,你非得给我传800K,你怎么优化也是卡,这种最简单,最直观的做法,我去告诉这端的发布端,我受不了了,你少发一点包,他给你把带宽降下来,我们做过实验,不加这个策略,其实卡的是非常频繁的,那你在动态的调节以后,包括有一个算法,它能够预测你后面可能会卡,主动的去降,主动的去调节,这个卡顿率会大大的降低。

 

4,噪声


最近我们很困扰的是我们音质导致的问题。我们发现一个客户很卡,但网络很好,江苏电信。最后抓包发现,根本没有丢包,在网络上传输非常好,但到了终端以后,因为我们回声消除做了很多工作,结果导致对方有一些噪音又传过来了,就像那个滴滴声音一样,又把好多说话当中的噪音消掉了一部分,导致声音听起来很不流畅。我们找了好多人,最后发现这个事只能通过一些策略上来去控制。现在好多人在做的时候,干脆长戴耳机,把回声消除关掉,就这么粗暴的干。

 

不掉线


再说说不掉线这个事,做音视频肯定会用到的,因为音视频它是个长连接,不像HTTP访问完了就完了,这里面涉及到这六个方面:




第一,媒体的断线与重连。一个用户一个老师在上课,上课的过程中网断了,这个断了怎么办?或者他不小心碰了一下网线,WiFi就是抖动了一下,就是断了,这个事是需要怎么去判断?


第二,信令。信令这个事很麻烦,因为信令是用TCP来连接的,你不可能用UDP来去做。TCP连接很容易断,你认为是这个用户下线了,还是怎样了?所以说信令断了以后要回过头去看媒体,我看媒体还在发着包呢,还有流量呢,信令就连自己的就行了。这里边,信令和媒体连接综合起来是一个问题,就是你怎么判断用户下线的问题,用户正常的下线是好下线的,我把客户端关了,你肯定是知道的。但是用户突然就崩了,还有一万人在等着看呢,那一万个人怎么办呢?怎么处理呢?他已经断线,信令已经发不出去了,这不是技术问题了,是需要在产品上设计一些逻辑来去让用户体验的更好。


第三,录制断线。我们还遇到了一个录像的问题,你这个媒体断了,他一会儿又连上来了,我的服务器就录了两段,一节课录了好几段,用户点播的时候怎么办?怎么来去记录它是一节课里的视频,而不是两节课里的视频,这个是需要去解决的。


第四,文档请求失败。还遇到了文档的问题,我们把文档转成图片,带动画的转成H5。如果房间里有一万个人,老师打开一个PPT,这个PPT有30多页,这会造成一个流量高峰,是非常危险的。同时,文档经常要HTTP请求,因为各种网络比较复杂,很容易请求不到。比如老师发一个信令告诉你要翻到第三页了,结果这个用户的信令丢了,没有翻页,导致他上课不同步,各种问题就会来了。学生就会在群里说我上不了课了。


第五,服务器之间的上课重连。有的时候我们端到服务器之间做了很多策略,去保障它的稳定性,包括各种的策略的优化,但是服务器之间也不可忽视。我们之前出过很多故障,怎么回事呢?因为服务器与服务器之间不通的,现在比较屌丝,什么阿里云,什么腾讯云,各种云我们都买,买了一堆,我们也不知道它的点到底是覆盖情况怎么样,我们就实际去测,但是云与云之间,它们的点之间经常也是不稳定的,端到服务器稳定了没用,服务器到服务器之间不稳定同样导致这个问题。我们需要一个全拓普才能保证服务器之间,保证到端的稳定性是非常好的。


第六,API接口请求。有一堆API请求,特别是进房间的API是非常关键的,因为一节课并发一上来以后,大量用户在短时间内进来,你要查他有没有钱,他是学生还是老师,在哪个房间里等等,去做状态同步。如果这个API请求失败了,他就进不去了,非常麻烦。

 

不延迟


延迟就比较简单了,原来我们老追求低延迟,到最后发现比人家快3毫秒、5毫秒的也没价值。真正一个好的产品,在于综合的因素,而不是比较单一的去比技术,这个是没价值的。互动的延迟,就是采取刚才说的那些方案的话,能做得效果非常好的,有的时候在局域网内,能控制在100毫秒之内,包括编码、传输、解码等等。


HLS的延迟,大家也没什么好的方案,基本上就是10毫秒、8毫秒的样子。

Web的延迟大概是1到3毫秒。这里面有一个问题,客户端也好,Web也好,它的延迟非常低,老师翻了一页PPT,老师讲了这个章节,但是HLS那端慢了许多,大概慢了个10秒、8秒,你怎么去估这个值,去跟它同步起来?因为老师在做标记的时候,其实他这个时间已经在这个时间下面,而看HLS的那帮学生还没有听到呢,怎么去估算这个延迟?或者从哪里拿到,他能确定这个终端在当前播到那个时间点跟它去同步,跟他听PPT能够同步。



正是因为我们的技术不断在进步,很多看起来不可能的事情才会变为现实,才会为大众所接受。在线直播教育便是这其中一个很好的印证了。