互动直播应对卡顿、延迟、掉线的技术难点实践

摘要： 经过6年的发展，布卡互动经历了产品、技术等方方面面的问题与挑战，积累了互动直播和海量直播领域的产品运营经验与技术实战能力。本文根据布卡互动创始人张玺辉在2017年4月22日《LiveVideoStack Meet北京：后直播时代技术》沙龙上的分享整理而成，讲述了布卡互动在教育直播领域的经验与经历。

文 / 张玺辉

整理 / LiveVideoStack

点击观看演讲视频，关注LiveVideoStack，回复『0422资料』，获得此次此次分享的资料下载地址。

大家好，我叫张玺辉，来自布卡互动，我做直播很早了，在2011年我就开始做，但那个时候行业还不是很成熟，另外我个人比较固执，就钻到教育领域去了。我在起步的时候，不是因为技术而去技术，而是想解决教育里面的问题，结果就错过了斗鱼、花椒、映客，结果活的很苦。但是这几年折腾下来还是留下了一些技术沉淀，来跟大家分享一下。

两种技术形态

1，从这两年开始，有的是做PaaS层，提供SDK级别的服务，像腾讯、声网、即构都做得不错。他是专注在PaaS层，全行业全领域都在用，像我们做APP就不用去关注底层的什么TCP\UDP，什么编解码传输等等，人家都做好了，调个API用就行了。

2，SaaS层，衍生出很多很多垂直的机会来，像在线医疗、在线教育、电商、客服、企业培训营销等，实际上是垂直行业的应用，这里面的机会是特别多的，因为音视频和工具是这个行业的基础设施，基础设施建设的好了，这个行业的效率才能提高，才能快速发展。

两条赛道

1，第一个跑道里面，人员的技术素质是远远没有第二个行业高的，好多教育公司里面的CTO是网管级别的，就是装装系统，插插网线那种。

2，第二类是游戏和美女直播，这个商业模式比较成熟，技术沉淀各方面做得还是不错的，我们布卡是从PaaS到SaaS，在在线教育领域做了一套整体方案。在2012年我们就开始在做互动了，当时遇到的一个大问题，就是回声的问题，结果没有处理好。接下来我们又在做直播，行业需要这样一种方案，这个方案是直播和互动混合在一起的，因为有时候场景是需要直播的，比如说我这场活动，有一万个人来听，不可能是互动的。有的K12课程里，包括一些教育机构的小班课一对二、一对六，一个老师带几个孩子一起来学，是需要频繁的互动的。我觉得真正好的解决方案是直播和交互要在一个软件里都要具备的，当然我的假设场景是教育。

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

在线教育领域这几个事情都是要干好的，包括媒体、信令。信令这个有点特殊，在一般的娱乐直播中是用不着的。另外，文档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能够同步。

经验与坑

这几年来，自己去关注这些技术，有几个点还是感触跟深受的：

第一，日志系统。做音视频最好在未做之前，先把日志系统设计好。我们起步的时候就两三个人，也没在意这个事，上来就是先干，结果干完了以后，把系统搭起来的时候，真正运行的时候发现太痛苦了，因为用户说卡了，你也不知道怎么卡，你也不可能把代码再review一下，你也找不到问题的根源，因为音视频有很多环节，到底是媒体、信令，还是服务器之间，各种环节到底是哪一个环节出了问题，定位问题就很麻烦。一个完善的日志系统，对系统的快速开发与故障定位、完善是非常关键的。

第二，产品设计。这个也很关键，我们刚开始想的非常大，我们想把直播和交互合到一个产品里去了，既能做直播又能做交互，可以多人交互，在多人交互的时候，还能做直播，这里面绕了很多的产品逻辑，这让工程师很痛苦，因为人和人直播，和小班互动就是两种场景，你硬把它从产品里面合起来，就会导致技术很复杂，技术的复杂就导致不稳定性。后来，我们就把直播和交互完全分成两个产品，在直播里，我们可以允许一个人当嘉宾去发言，他可以去交互，但是其他的人就老老实实的用网页听就完了，也别想视频发言了。

第三，运维对这个音视频来说还是很关键的。如果运维有比如说百万级的音视频直播的经验的话，还是非常关键的，因为这里面有很多的经验和坑不是光靠学就学的来的，真正你上手操盘和听别人讲故事完全是两回事。

问答时间

Q1：你好，我们都知道回声消除是一个比较大的难点，我想多了解一下，你们对回声消除是怎么样做的一些具体的技术细节？

张玺辉：回声消除这个事呢，我们是从WebRTC里抠出来的，但是WebRTC好多这个做音视频的后期这一帮人都是参考它的，不是说自己写的，但是抠出来以后，WebRTC也是做得比较粗糙，很多场景下面它是解决不了这个问题。另外在各个端，就是Mac和iOS解决的很好，Windows需要去改一些算法，这里边核心就是那个delay值，是要不停的去计算的，根据不同的场景去计算。但有一些场景是无能为力的，比如你说话同时我也说话，两个人在同时说话的时候，它这个表现就会非常差，那怎么办呢？你就静音，先让一个人关了让另一个人说，这个是通策略控制的回声消除。

问题比较大的就是噪声，比如说我敲敲桌子，或者我碰了一下凳子，或者我在跟你视频会议的时候他在旁边说话，把他的声音收进来以后相当于我说话，就把它给消掉了，这里面就很麻烦，需要设一个值，把你认为哪个档次算是噪音，我就直接干脆把它滤掉了。再做得好一点，我看QQ还比较有意思，我一个同事在嗑瓜子，他完全把它给消掉了，包括这种键盘声，消的非常干净，非常好，我们就做不到，后边我们就找了一些人问了一下，还有一个场景噪音消除，这就看什么场景了。

另外就是安卓更痛苦，你做安卓的回声消除，它后来的这些产品，他用的硬件的消除，他加了一个东西，但是不是很好用，还是要有软件的处理，跟PC还是完全是两套算法。

如果还没过瘾，布卡互动将在LiveVideoStack Meet 6月17日杭州站和6月24日上海站两场活动进行现场直播演示，欢迎您到场体验。