CDN质量检测浅析

前言

对大量使用CDN产品甚至依赖的直播平台而言,CDN的质量问题,一直是一个长期让人头疼的问题。而质量不好,势必影响业务发展的稳定性。

CDN的质量问题表现有以下几点:

一、平台方“不知道有问题”:同时存在的直播间太多,覆盖的用户更多,不知道好不好,也不知道哪里不好。

二、平台方“被知道有问题”:不能第一时间主动感知到质量变化,直到弹幕里被带了节奏才被动知晓,为时已晚。

三、平台方“不知道问题在哪里”:有N条流,分发给N个节点,又分发给N个用户,业务非常复杂,一旦有质量波动,不能第一时间定位原因所在。

四、CDN厂商“也不知道有问题”:CDN厂商更关注的是整个资源盘的质量,颗粒比较粗,加上没有端做数据支撑,往往比平台方更后知后觉。

综上所述,本质原因是数据的量级和业务的复杂度不匹配,要用极少的数据来监控复杂的业务,本身不现实。而业务的复杂性是客观存在,也是业务本身所需,不可更改,那就需要通过增加数据的量级来做匹配,

要提升数据的量级,并完成匹配,必须具备2个条件:负责数据采集的端和负责数据分析的模型。

数据采集

服务端的数据采集,CDN厂商就能做到。但光有服务端的数据,就分析而言,是很单薄的,有点居庙堂之高,未知江湖之远的味道。

因此,地处“江湖之远”的客户端数据就显得尤为重要,是整个数据集合中的灵魂。只有端的数据才是最真实最正确的,其它模拟检测产品的数据再仿真也只是参考,代表的仅仅是可能,而非确凿。

而客户端的真实数据,是CDN厂商所鞭长莫及的,只有平台自己来采集。

那么,具体要采集什么数据呢?

主要采集(即客户端主动上报)在线人次和卡顿事件,细分的数据有以下

1 时间点:精确到秒,一般卡顿事件就会有。
2 用户IP:上报时服务端从底层可以获取,所以不同刻意加上(其实客户端也不知道自己的公网IP)

3 流名:即代表用户所处的直播间,流名应该全平台唯一。

4 端类型:因为不同的端,特性不同,细分开来,还是有助于深入分析的。主要分flash、H5(PC)、iphone、Android、Ipad、Android_Pad、Android_TV、H5(moblie),事先确认好定义。

5 服务器节点IP:一般首次调度使用IP调度方式即可获取,若使用了域名调度,就获取不到,只能忽略。所以,建议使用IP调度方式。

6 CDN:当前服务的CDN厂商编号。

7 协议类型:目前有rtmp、HDL、HLS这3种主流流媒体协议。就直播而言,使用比重较大的是rtmp和HDL。后来有在上面新增一些P2P的技术,可以理解为新的一种协议,作为独立的考察项。

8 行为ID:表示用户本次拉流行为的ID,这个是很重要的值。比如用户可能会在一段时间内多次拉流,就会生成多个行为ID,也会产生多个卡顿事件,用行为ID,就区别不同的行为,以及卡顿分属哪次行为。否则不同的卡顿事件,除了时间点不同外,以上2-7点的数据都可能相同,就无法做进一步区分了。行为ID的生成算法要求客户端随机生成,且相当长的时间(如24小时)内不重复。

一般建议要记录每一次的卡顿事件,再加上带着这些多维度的实时参数,数据量是应该是足够了的,接下来就要看怎么做数据分析了。

数据分析

数据分析比较看重模型。不同的业务要求,会采用不同的模型。

本文作者基于实操的经验,建议采用的分析模式可以是流-节点-用户模型。

什么意思呢?即先观察流的质量,再观察节点质量,最后观察用户本地的网络质量。

为什么要按这个顺序分析呢?因为从业务特性来看,流的质量影响权重是最大的,节点其次,最后才是用户。

比如一个流本身质量变差了,势必当时看这个流的用户都会受影响,无一幸免,也无从逃避;但如果某一节点质量变差,从流的视角看,只是部分用户被影响,不太容易带节奏,且可以通过换节点缓解;而用户本地的网络质量出问题,影响面最小,很可能一个直播间里就他一个人有影响,处理起来也比较简单。

这里把分析的流程图列出来


其中流卡顿超标的原因分析、节点卡顿超标的原因分析以及用户卡顿原因分析,涉及到的细节很多,这边就给出一个思维框架供参考,不做细解。

其它因素

以上说的都是比较简单和纯粹的模型,但其实整个数据采集和数据分析,还需要考虑到其它因素,比如:

1 多CDN的架构。

一般都会采用多家CDN。有些平台采用的是直推一家CDN厂商,其它CDN厂商会去这一家拉流;也有的平台采用的是直推一家CDN厂商,由该厂商转推给其它CDN厂商。不同的架构,对数据的分析会有不同。

2 转码。

转码,即多码率,也是现在直播平台的功能标配,遇到原始码率高的流,为了适应不同带宽的用户需求,会通过云转码的方式转出超清、高清和标清等不同清晰度(背后的码率参数各自定义)。那么分析流质量的时候,就要同时考虑转码流的质量,若转码流质量不好,但源流好的,那说明是转码过程出问题了;又若转码流和源流质量都不好,那很可能是源流问题。

3 多出口。

中国的网络情况很复杂,很多小运营商的存在,导致很多用户的出口表现为电信、联通,其实并非电信、联通用户,容易在调度和定位问题上混淆视听。而且经常是一会电信的出口IP,一会又小运营商自己的出口IP,走位十分飘忽。为了尽可能定位用户真实的运营商归属,建议可以多获取和记录几次用户IP,按照一定规则,来准确定位。

最后的话

CDN的质量检测是一个复杂而需要耐心的工程。

首先,要求相关人员,不仅要了解CDN的基本原理,并且要吃透平台的业务特色。

其次,要制定适合自己平台的分析模型,特别是各个报警阈值的设定。

最后,有了数据采集和数据分析,才能做之后适合自己的调度工作。

调度工作,又是一个很复杂的话题,就不在本文展开,有机会再讲。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 222,378评论 6 516
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,970评论 3 399
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 168,983评论 0 362
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,938评论 1 299
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,955评论 6 398
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,549评论 1 312
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 41,063评论 3 422
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,991评论 0 277
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,522评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,604评论 3 342
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,742评论 1 353
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 36,413评论 5 351
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 42,094评论 3 335
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,572评论 0 25
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,671评论 1 274
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 49,159评论 3 378
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,747评论 2 361

推荐阅读更多精彩内容