字节跳动千万用户量级直播活动技术保障实践
还有转码故障。转码故障可能导致用户看不了转码流，只能观看源流。这种情况下，一般码率比较高，用户会感到明显的卡顿。
除了这些节点故障，还有跨网传输。刚才讲到边缘节点一般是离用户最近的，同网、同运营商、同区域内。但是如果 DNS 解析不正常，出现了跨网传输，就会极大影响体验。比如北京联通的用户，从北京移动去拉流，这样的网间传输就会带来非常大的质量问题，可能会拉不到流，或者是直播画面变得非常的卡顿。
还有一种情况是带宽不足。我们一些大型的直播，它的人数是非常多的，可能是上千万人，这样的话，是任何一家 CDN 都扛不住的。然后还会有些区域覆盖，特别是有些区域的 CDN 节点比较少，这样就会有一些跨网的覆盖，或者是跨运营商的覆盖，用户量也是会感到有明显的质量的变差。
那我们如何去评价直播的质量？一个就是 QoS 指标，QoS 就是服务质量，目前有五个指标：拉流成功率，百秒卡顿时长，百秒卡顿次数，端到端延迟，首帧时长。
拉流成功率表示用户能够成功拉到流的比例是多少，拉流成功率低，说明这个流几乎是不可用的。百秒卡顿时长和百秒卡顿次数直观的描述了用户观看的过程是否流畅。端到端延迟，也叫挥手延迟，就是说主播在这端挥挥手，到用户能够看到这个挥手的动作，中间所持续的时间是多长，主要需要降低端到端延迟。首帧时长是从点开直播，到看到了第一帧画面中间所持续的时间。
这些 QoS 指标，我们会更细化到一些维度上面去，比如就是直播流、清晰度、主备线路、CDN、应用、省份、运营商、操作系统、版本号等等。我们通过这些维度能够很快的归因出，目前影响直播质量的到底是哪一个环节。
还有 QoE 指标，就是体验质量。QoE 指标有次均观看时长，同时在线人数，还有万条评论报卡率。特别是次均观看时长和同时在线人数这两个是比较相近的，如果它出现较大的变化的时候，比如用户突然之间走了并不一定是服务出现问题，它也可能是直播内容不够精彩，这时候次均人员观看时长、同时在线人数就会有一个明显的下降。
但是反过来，如果要是 QoS 指标出现问题，那么它一定会影响到 QoE 指标。比如说拉流成功率突然降低了，CDN 的结点出现故障了，这时候很多用户是被强迫卡出去的，并不是我们的内容不精彩，在同样内容情况下，是用户看不到流了进不来了。这时候我们的次均观看时长会降低，同时在线人数也会降低。这两者有相互借鉴的一个作用，应该两个结合起来去看问题，
然后万条评论报卡率就是我们发评论的时候，主播可能是看不到的。比如主播是在全屏分享 PPT，但是大家可能会在评论区发一些关于直播内容的消息，比如他们会说“好卡，已经卡了”。这些其实是非常重要的一些信息，我们可以把这个评论的内容收集过来，作为一个 QoE 指标，将这些报卡的用户比例与百秒卡顿时长、百秒卡顿次数这些 Qos 指标相互借鉴，我们会发现，报卡率也是一个非常正向的，非常有借鉴意义的一个 QoE 指标。
还有清晰度的问题，比如说画面质量模糊，有马赛克，看不清，这些也是一些 QoE 指标。我们目前也在梳理这些，我们也想把它作为一个评论画面质量相关的一个 QoE 指标。这个 QE 指标我们也把它细分到好多个维度：直播流，清晰度，主备线路，CDN 度，应用。
刚才给大家简单介绍了直播的全链路是什么样子，也列出了各个环节可能造成的质量相关的问题的风险点，以及如何用 QoS 和 QoE 指标去评价直播的质量，对直播的质量进行量化，如何去优化这些直播的质量，现在我们就来看一下字节跳动在事件直播的过程中一些重保实践。
首先说一下什么是事件直播。简单举几个例子，比如抖音盛典，西瓜 Play，头号英雄，头条盛典，跨年直播，火山盛典，LiveXlive48 小时不间断直播，罗永浩的首秀，当然还有一些明星的直播，比如汪峰、王祖蓝、陈赫、AngelaBaby、张庭，他们都进行过直播带货。除此之外，还有草莓音乐节，SpaceX 发射，清北网校在线课堂等等，这些都是属于事件直播。
通过这些关键词，我们可以简单的概括事件直播是由组织发起的、非日常的开播，不是一个人对着手机或者是游戏的开播。它的目的性比较强、主题比较明确，比如明星直播带货，它的目的就是直播带货；头条盛典，火山盛典，抖音盛典，它们都是一场晚会。还有一个特点是影响力比较大，受众广泛。每一场事件直播都有很大的目标群体，动辄就是几十万，上百万，甚至近千万的用户观看。
对我们而言，事件直播是值得花大力气去保证的直播。这么多的直播类型，形式都非常的不一样，有的是一个机位，有的是多个机位，很难面面俱到的去覆盖每一场场景，很难有一个统一的重保规范去覆盖这些场景。重保需要 case by case 的去分析，梳理过程中可能存在的风险点，然后制订一些重保方案。
通过这些的重保活动，我还是梳理出了一个比较通用的直播重保架构。
大家可以看一下上面这个图，首先信号采集部分，可能会有多个机位，多个信号源。信号源把信号传输到导播台，导播台进行信号切分，最终会把信号传到延迟器。延迟器把信号传到推流器，推流器进行音视频的编码，压缩，然后把它推到 CDN 网络上去。上行是一个 CDN，下行可能会挂在多个 CDN 去分发，就是多条线路，然后用户从这些线路里面去选择其中的一个去进行观看，这是主
要的流程。
通过上图，大家可以看到，其中比较明显的是从导播台出来的信号是完全翻成了左右两部分，就是主、备线路。左边是个主线路，右边是个备线路，主备是完全正交的。左侧任何一个节点出现问题，都可以让用户去用备线路去拉流，这个也是自动实现的。
那么导播台这个地方为什么没有去用主备导播台呢？主要是因为导播台是有旁通的功能，它都是一些硬件设备的，至少目前是没有出现过故障的，还有就是如果即使换成主备导播台，就要求主备导播台出的信号完全一致，但这个不是能够轻易现实的。
然后延迟器，上图虚线部分，意思是说延迟器我们是可以选择的。延迟器的作用，主要是对内容进行容灾。比如有些舞台事故不希望让用户看到，就会在延迟器里把事故的片段切掉，这样用户看到的是一段跳过去的内容。还有就是垫片，我们把它同时放到了导播台、推流器、上行 CDN。有些不同的容灾的级别，比如传入的信号出现了问题，这时候用导播台去推垫片，然后把垫片放到推流器，我们容的是导播台、延迟器这一层面的故障。也就是说进推流器的音视频信号出现问题，我们就用推流器去推这个垫片，让用户看到的主备还是一样的。不至于看到一个空白的黑屏，或者是说是一直在那里转圈圈。
还有大家可以看到导播台出来了一个旁路信号，就是进了监视器，这个监视器代表着从导播台出来的信号是被用户可以看到的内容。
我们这里能够完整呈现包括导播台输出的音视频的信号，一个是有个画面显示，另一个是有一个录制功能，能够在这里把信号录下来。前面提到的一个活动上出现的音频反向，就是通过这个监视器录制的信号，让导播团队知道是他们导出来的信号有问题。且不是在延迟器，或者是推流器，或者是 CDN 这一层面出现的反向问题。还有主备 CDN 下面会挂载多个线路，是为了容灾，每个线路都是一个 CDN 进行分发，其中线路一出现了问题，我还可以让用户切换到线路二和线路三去。
另外一些大型直播的用户量级非常大，一条 CDN 线路是没法承载这么多用户的。所以也得需要多个线路、多个 CDN 去共同承担用户的直播分发。我们有专门的人员划分去进行不同的重保。人员划分主要分为上行容灾、下行容灾，还有体验容灾。对直播上行来说，主要是容的网和电。我们会在现场备一个 UPS，就是不间断电源。即使市电断了，我们也可以再用 UPS 撑很长一段时间。网络一般看活动的重要程度，有可能会拉专线，也有可能是用 4G 和 Wi-Fi 互备。当然也有可能是用聚合路由把信号聚合起来。
除了网和电的容灾，还有是对内容的容灾。比如推垫片，还有延时器的裁剪，这些是上行的一些容灾措施。
下行的保障，主要是通过链路层面的保障能正常推到 CDN 上去。但是用户观看可能是受影响的，这时候我们可能会有一些主备切换。
另外还有清晰度的降级，主要转码流故障，或线路的调整，或 CDN 线路出现问题，我们会切换到另一个 CDN 线路上去。
还有一部分是负责体验容灾的，就是体验保障。当用户反馈卡顿，或者是不清晰，这时候会设置播放器的缓存，通过增加缓存来减少用户的卡顿。还有区域运营商线路调整，当用户在某一个区域运营商的时候比较卡顿，比较有集中性，那我们就会把这一个区域运营商的用户换 CDN 去覆盖。节点的调整，是某一个节点下的用户出现问题，就让用户去用别的节点去覆盖，从别的节点去拉流。降级的操作主要有音视频信号的同步处理，音频单声道拷贝，主备切换，拉流转推，设置房间默认清晰度，降低转码码率，摘除转码，调整 CDN 权重。设置播放缓存，区域运营商切换 CDN，节点优选，下掉 CDN 节点等等。
直播质量的优化，首先是对普通用户的优化，就是转码档位设置。提升清晰度，一般情况下是提升码率或者分辨率。但是什么样的码率配置什么样的分辨率是需要去做尝试的。首先我们得有一个平台把不同编码的左右两个图片参数编出来，然后进行对比打分，同样的码率下是 480P 还是 540P 更加好一些。
除了主观打分，还有一些客观的质量评判标准来进行评判。我们可以看到，并不是随着码率升高，清晰度是一直往上增加的，达到了一定的程度后，其实会趋于平缓，这时人们就感受不到码率变高带来的清晰度的改善。然后我们的经验是说在 1M 以下，会分发 480 P。在 1-2M 之间，可能会分发 540 P。在 2M 以上，可能就会分发 720 P。
还有针对一些弱网的用户，是网络不太好的用户，比如 4G 用户到了月底限流了，只能用几百 K 的速度带宽去观看直播，这种情况我们其实也有一些优化，通过传输协议和丢帧策略优化。
现在国内主要就是 FLV，然后还有 HLS，RTMP，但是所有底层的传输协议还是用的 TCP。TCP 的超时重传、拥塞控制都不是那么好改变。除了 TCP 还有 UDP。UDP 没有三次握手，包头会比较小一点，这样传输会更快一些。比如 KCP， QUIC，是基于 UDP 实现的可靠传输。
丢帧策略有优雅丢帧、传输层丢帧、音视频分离。音视频分离其实是一种更极端的丢帧方式。在非常卡的情况下，我们可能只播放音频，不播放视频，这样的话相当于把视频全丢掉。
具体怎么样选择协议和策略，我们可以通过上图来看。首先我们对用户的播放器日志进行收集和数据分析。通过时段、设备类型、国家城市、运营商、观看时长这些，最终去进行识别分类出一些指标，比如 RTT、丢包率、带宽、活动周期、码率、观看时长、卡顿数据、清晰度。然后把这些指标应用于模型训练。通过模型我们进行策略的匹配与下发。决策出当前用户在当前的网络下，用 TCP 还是用基于 UDP 的 KCP 、QUIC，以及初始参数、拥塞策略、丢包策略。同时根据最终用户的观看效果，QoS 指标和 QoE 指标效果反馈到网络模型上去进行进一步的优化。
除此之外我们还有对一些特征的私有化部署。之前我们有一场发布会活动，我们没有想到用户会有那么多，当时几乎是所有的同事在办公环境下一起观看直播，分配下来每一个人几兆带宽。因为都是从公司的入口网关处拉流进来，这样最先崩溃的是我们公司的网络入口。这种情况下，我们就需要通过私有化部署来解决这个问题。现在我们内网的一些分享之类的全都通过私有化部署来解决了。
私有化部署是把 CDN 的边缘节点部署到人员比较密集的地方去，比如每个办公区部署一个节点。比如图中紫色的部分，就是边缘节点，绿色的就是一个办公区。所有办公区的用户，我们通过 DNS 劫持，把他们通过同一个播放地址去拉流。私有化部署带来的好处一个是信息安全，防止泄露，有一些活动分享其实是有保密性的，不希望能够被外界感知到，所以私有化部署就很好地解决这个问题，并能解决入口带宽的瓶颈。
赋能的一个比较典型的例子，就是在疫情期间，一天时间我们让清北网校拥有了空中课堂的直播能力，并且保证了直播的稳定和质量。上图是清北网校的网站，首先给直播开辟了一个单独的入口，为全国中小学生免费提供直播系统。快速搭建清北网校主要得益于下面 5 点：
一个是快速搭建页面的能力，就是所见即所得。
页面组件化，一行代码能够迁入。
完善的直播保障和容灾体制机制。
支持推拉入等多种开播方式。
支持字节旗下的多平台互通分发。
我们会用一个平台重保管理，有一些操作都能够自动进行，比如可以通过指示灯表述直播状态。我们还可以进行自动巡检，判断是否可以自动做一些降级操作。我们还可以记录历史的报警信息等等。同时我们也提供了这个直播伴侣，客户端，用直播伴侣客户端可以直接进行开播操作。
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论