首页 / 专利库 / 作物管理 / / 一种带宽捆绑检测方法和装置

一种带宽绑检测方法和装置

阅读:925发布:2020-05-08

专利汇可以提供一种带宽绑检测方法和装置专利检索,专利查询,专利分析的服务。并且本 发明 涉及带宽检测技术领域,提供了一种带宽 捆 绑检测方法和装置。方法包括以宽带账号为统计维度,若统计出在不同时刻里,不同的多个固定用户ID出现在相同的宽带账号组合中的次数超过第一预设次数,则组合中的宽带账号被标注为第一疑似捆绑;统计同一用户ID,在一天内所有检测周期中出现的次数,按用户ID进行汇总,若判断结果为存在任意连续 指定 数量的检测周期出现在同一宽带账号组合中的不同宽带账号中,则标注所述宽带账号组合为第二疑似捆绑;对于同时满足上述的第一疑似捆绑和第二疑似捆绑的宽带账号组合,则确认为捆绑宽带账号。本发明可以让电信运营商能够有效的发现有捆绑情况的宽带账号。,下面是一种带宽绑检测方法和装置专利的具体信息内容。

1.一种带宽绑检测方法,其特征在于,包括:
以宽带账号为统计维度,若统计出在不同时刻里,不同的多个固定用户ID出现在相同的宽带账号组合中的次数超过第一预设次数,则组合中的宽带账号被标注为第一疑似捆绑;
统计同一用户ID,在一天内所有检测周期中出现的次数,按用户ID进行汇总,判断同一用户ID是否存在任意连续指定检数量的检测周期出现在同一宽带账号组合中的不同宽带账号中;若判断结果为存在任意连续指定数量的检测周期出现在同一宽带账号组合中的不同宽带账号中,则标注所述宽带账号组合为第二疑似捆绑;
对于同时满足上述的第一疑似捆绑和第二疑似捆绑的宽带账号组合,则确认为捆绑宽带账号。
2.根据权利要求1所述的带宽捆绑检测方法,其特征在于,所述第一预设次数具体为5-
10次;所述指定数量具体为3-5次。
3.根据权利要求1所述的带宽捆绑检测方法,其特征在于,在进行所述统计之前,方法还包括:
按照所述检测周期,每一检测周期输出一份用户ID-宽带账号的对应关系表;
根据所述对应关系表,把相同的用户ID的数据项进行合并;其中,在所述合并过程中将同一用户ID所关联的不同的宽带账号记录到过渡表中,在合并过程中删除宽带账号所关联宽带账号数量为1的数据项;所述过渡表用于统计过程中的分析对象。
4.根据权利要求1所述的带宽捆绑检测方法,其特征在于,设定对应IP相同情况的标识为I、对应IP不同情况的标识为i、对应Host-Key相同且Host-Key的value值相同情况的标识为V、对应Host-Key相同且Host-Key的value值不同情况的标识为v,方法包括:
将对应IP相同且Host-Key相同且Host-Key的value值相同情况的标识设定为IV;将对应IP相同且Host-Key相同且Host-Key的value值不同情况的标识设定为Iv;将对应IP不同且Host-Key相同且Host-Key的value值相同情况的标识设定为iV;将对应IP不同且Host-Key相同且Host-Key的value值不同情况的标识设定为iv;
依据IV和iv的参数值越大越优、Iv和iV的参数值越小越优的对应关系,根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分;
根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID。
5.根据权利要求4所述的带宽捆绑检测方法,其特征在于,所述根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分,具体包括:
根据公式Score=(IV*iv)/(Iv*iV)来计算每一组Host-key的得分;或者,根据公式Score=(IV-Iv)*(iv-iV)来计算每一组Host-key的得分;或者,根据公式Score=(IV+iv)/(IV+iv+Iv+iV)*100来计算每一组Host-key的得分。
6.根据权利要求5所述的带宽捆绑检测方法,其特征在于,所述根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID,具体包括:
取Host-Key计算得分位于预设第一排名值之前的Host-Key作为当前数据分析场景动态生成的用户ID;其中,所述预设第一排名值为200-500或者排名位于总的前10%作为所述预设第一排名值。
7.根据权利要求5所述的带宽捆绑检测方法,其特征在于,所述根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID中,具体为针对同一IP地址,需要确定相应IP地址的用户ID时,方法包括:
针对同一IP地址下,将对应的多个Host-Key计算得分进行排序,取其中排名位于第二预设排名之前的Host-Key作为所述IP地址对应的用户ID。
8.根据权利要求4所述的带宽捆绑检测方法,其特征在于,在根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分之前,所述方法还包括:
根据所述Iv和/或iV的参数值在总的统计数量中的占比,确定相应占比是否超过第一预设阈值
若所述Iv和/或iV在总的统计数量中的占比超过所述第一预设阈值,则跳过相应Host-Key组合的得分计算。
9.根据权利要求8所述的带宽捆绑检测方法,其特征在于,若所述Iv和/或iV在总的统计数量中的占比超过所述第一预设阈值,所述方法还包括:
对于Iv在总的统计数量中的占比超过所述第一预设阈值,进一步分析IP相同情况下出现Iv情况的各Key名称;确定其中Key为用户名或者其中Key为设备MAC地址,则在日志中记录相应IP为潜在的工作室。
10.一种带宽捆绑检测装置,其特征在于,所述装置包括:
至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述处理器执行,用于权利要求
1-9任一所述的带宽捆绑检测方法。

说明书全文

一种带宽绑检测方法和装置

【技术领域】

[0001] 本发明涉及带宽检测技术领域,特别是涉及一种带宽捆绑检测方法和装置。【背景技术】
[0002] 在传统的运营商固网业务中,经常会碰到带宽捆绑私接的场景,例如:宽带批发商会把10条100兆的宽带捆绑成1条千兆宽带作为专线提供给用户使用。然而,10条百兆宽带的价格远远低于1条千兆专线,同时电信运营商缺乏有效的手段对带宽捆绑私接进行检测,因此会给电信运营商带来较大的经济损失。电信运营商迫切需要有效的技术手段,发现并
打击带宽捆绑私接的用户。
[0003] 鉴于此,克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。【发明内容】
[0004] 本发明要解决的技术问题是同时电信运营商缺乏有效的手段对带宽捆绑私接进行检测,因此会给电信运营商带来较大的经济损失。电信运营商迫切需要有效的技术手段,发现并打击带宽捆绑私接的用户。
[0005] 本发明进一步要解决的技术问题是如何在不同应用场景下找到可以高效唯一标识用户对象的用户ID对用户进行检测,尽可能的覆盖全部用户。
[0006] 本发明采用如下技术方案:
[0007] 第一方面,本发明提供了一种带宽捆绑检测方法,包括:
[0008] 以宽带账号为统计维度,若统计出在不同时刻里,不同的多个固定用户ID出现在相同的宽带账号组合中的次数超过第一预设次数,则组合中的宽带账号被标注为第一疑似
捆绑;
[0009] 统计同一用户ID,在一天内所有检测周期中出现的次数,按用户ID进行汇总,判断同一用户ID是否存在任意连续指定检数量的检测周期出现在同一宽带账号组合中的不同宽带账号中;若判断结果为存在任意连续指定数量的检测周期出现在同一宽带账号组合中
的不同宽带账号中,则标注所述宽带账号组合为第二疑似捆绑;
[0010] 对于同时满足上述的第一疑似捆绑和第二疑似捆绑的宽带账号组合,则确认为捆绑宽带账号。
[0011] 优选的,所述第一预设次数具体为5-10次;所述指定数量具体为3-5次。
[0012] 优选的,在进行所述统计之前,方法还包括:
[0013] 按照所述检测周期,每一检测周期输出一份用户ID-宽带账号的对应关系表;
[0014] 根据所述对应关系表,把相同的用户ID的数据项进行合并;其中,在所述合并过程中将同一用户ID所关联的不同的宽带账号记录到过渡表中,在合并过程中删除宽带账号所关联宽带账号数量为1的数据项;所述过渡表用于统计过程中的分析对象。
[0015] 优选的,设定对应IP相同情况的标识为I、对应IP不同情况的标识为i、对应Host-Key相同且Host-Key的value值相同情况的标识为V、对应Host-Key相同且Host-Key的value
值不同情况的标识为v,方法包括:
[0016] 将对应IP相同且Host-Key相同且Host-Key的value值相同情况的标识设定为IV;将对应IP相同且Host-Key相同且Host-Key的value值不同情况的标识设定为Iv;将对应IP
不同且Host-Key相同且Host-Key的value值相同情况的标识设定为iV;将对应IP不同且
Host-Key相同且Host-Key的value值不同情况的标识设定为iv;
[0017] 依据IV和iv的参数值越大越优、Iv和iV的参数值越小越优的对应关系,根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分;
[0018] 根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID。
[0019] 优选的,所述根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分,具体包括:
[0020] 根据公式Score=(IV*iv)/(Iv*iV)来计算每一组Host-key的得分;或者,
[0021] 根据公式Score=(IV-Iv)*(iv-iV)来计算每一组Host-key的得分;或者,
[0022] 根据公式Score=(IV+iv)/(IV+iv+Iv+iV)*100来计算每一组Host-key的得分。
[0023] 优选的,所述根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID,具体包括:
[0024] 取Host-Key计算得分位于预设第一排名值之前的Host-Key作为当前数据分析场景动态生成的用户ID;其中,所述预设第一排名值为200-500或者排名位于总的前10%作为所述预设第一排名值。
[0025] 优选的,所述根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID中,具体为针对同一IP地址,需要确定相应IP地址的用户ID时,方法包括:
[0026] 针对同一IP地址下,将对应的多个Host-Key计算得分进行排序,取其中排名位于第二预设排名之前的Host-Key作为所述IP地址对应的用户ID。
[0027] 优选的,在根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分之前,所述方法还包括:
[0028] 根据所述Iv和/或iV的参数值在总的统计数量中的占比,确定相应占比是否超过第一预设阈值
[0029] 若所述Iv和/或iV在总的统计数量中的占比超过所述第一预设阈值,则跳过相应Host-Key组合的得分计算。
[0030] 优选的,若所述Iv和/或iV在总的统计数量中的占比超过所述第一预设阈值,所述方法还包括:
[0031] 对于Iv在总的统计数量中的占比超过所述第一预设阈值,进一步分析IP相同情况下出现Iv情况的各Key名称;确定其中Key为用户名或者其中Key为设备MAC地址,则在日志
中记录相应IP为潜在的工作室。
[0032] 第二方面,本发明还提供了一种带宽捆绑检测装置,用于实现第一方面所述的带宽捆绑检测方法,所述装置包括:
[0033] 至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述处理器执行,用于执行第一方面所述的带宽捆绑检测方法。
[0034] 第三方面,本发明还提供了一种非易失性计算机存储介质,所述计算机存储介质存储有计算机可执行指令,该计算机可执行指令被一个或多个处理器执行,用于完成第一
方面所述的带宽捆绑检测方法。
[0035] 本发明可以让电信运营商能够有效的发现有捆绑情况的宽带账号。实时性高,当天新捆绑的宽带账号,第二天就能被检测出来。效率高,全省数百万宽带账号,数小时能就能检测完毕。
附图说明】
[0036] 为了更清楚地说明本发明实施例的技术方案,下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地,下面所描述的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他
的附图。
[0037] 图1是本发明实施例提供的一种带宽捆绑检测方法流程示意图;
[0038] 图2是本发明实施例提供的一种带宽捆绑检测方法流程示意图;
[0039] 图3是本发明实施例提供的一种用户ID发现方法的流程示意图;
[0040] 图4是本发明实施例提供的一种用户ID发现方法的流程示意图;
[0041] 图5是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0042] 图6是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0043] 图7是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0044] 图8是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0045] 图9是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0046] 图10是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0047] 图11是本发明实施例提供的一种用户ID发现方法的实例中数据内容;
[0048] 图12是本发明实施例提供的一种宽带捆绑检测的装置结构示意图。【具体实施方式】
[0049] 为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
[0050] 在本发明的描述中,术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作,因此不应当理解为对本发明的限制。
[0051] 为了帮助运营商及时发现带宽捆绑的情况,我们发明了一种带宽捆绑的检测方法。该方法采用用户唯一ID+宽带账号+上网时间的交叉分析方法,检测用户上网使用的宽
带账号在时间上和数量上的变化规律。进而有效的发现带宽捆绑的情况。该发明适用于不
同用户规模的业务场景,从几万到几千万的用户规模都可以在较短的时间内发现捆绑的账
号。
[0052] 此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
[0053] 实施例1:
[0054] 本发明实施例1提供了一种带宽捆绑检测方法,如图1所示,方法包括:
[0055] 在步骤101中,以宽带账号为统计维度,若统计出在不同时刻里,不同的多个固定用户ID出现在相同的宽带账号组合中的次数超过第一预设次数,则组合中的宽带账号被标
注为第一疑似捆绑。
[0056] 在步骤102中,统计同一用户ID,在一天内所有检测周期中出现的次数,按用户ID进行汇总,判断同一用户ID是否存在任意连续指定检数量的检测周期出现在同一宽带账号
组合中的不同宽带账号中;若判断结果为存在任意连续指定数量的检测周期出现在同一宽
带账号组合中的不同宽带账号中,则标注所述宽带账号组合为第二疑似捆绑。例如一天48
个检测周期。
[0057] 其中,所述第一预设次数具体为5-10次;所述指定数量具体为3-5次。在具体应用场景还可以根据方法实际使用效果来调整上述参数值,因此,不限于上述给予的参数区间。
[0058] 在步骤103中,对于同时满足上述的第一疑似捆绑和第二疑似捆绑的宽带账号组合,则确认为捆绑宽带账号。
[0059] 本发明实施例可以让电信运营商能够有效的发现有捆绑情况的宽带账号。实时性高,当天新捆绑的宽带账号,第二天就能被检测出来。效率高,全省数百万宽带账号,数小时能就能检测完毕。
[0060] 在本发明实施例上述步骤101-103实现之前,优选的是对原始数据进行一轮筛选,如图2所示,在进行所述统计之前,方法还包括:
[0061] 在步骤201中,按照所述检测周期,每一检测周期输出一份用户ID-宽带账号的对应关系表。
[0062] 在步骤202中,根据所述对应关系表,把相同的用户ID的数据项进行合并;其中,在所述合并过程中将同一用户ID所关联的不同的宽带账号记录到过渡表中,在合并过程中删除宽带账号所关联宽带账号数量为1的数据项(这里表明是正常的,所以删除掉);所述过渡表用于统计过程中的分析对象。
[0063] 实施例2:
[0064] 本发明实施例通过多张数据表格作为实例,阐述实施例1中对原始数据进行筛选的方法中的具体过程;相比较上述的步骤201-202而言,展现的更为详尽,并且,进一步简化了表的呈现形式。
[0065] 首先是原始表(即实施例1中的过渡表的表现内容):
[0066] 按现有程序,每30分钟出一份用户ID-宽带账号的对应关系表。这里设定30分钟主要是考虑同一用户ID合法切换过程中可能产生的时间间隔,例如用户从公司回到家所需的
时间拟定为大于30分钟。把相同的用户ID进行合并,删除宽带账号数量为1的数据。这张表里的用户ID是唯一的。
[0067] 给予的典型表格式为:第一栏为:用户ID,第一栏为:宽带账号数量,第三栏为:宽带账号1、宽带账号2、宽带账号3....。
[0068] 表1:
[0069]1410382011 3 0351001093759,035101603438,tyadsl03515551803
1364292122 3 035601101739,035601105428,035601105431
1356679180 3 035102079880,035102097096,tyadsl03513107606
[0070] 其次中间表:
[0071] 1天48张用户ID-宽带账号的对应关系表,汇总成一张表,加上一列时间。
[0072] 给予的典型表格式为:第一栏为:用户ID,第二栏为:宽带账号数量,第三栏为:宽带账号组合,第四栏为:时间段。例如下表2中所示。
[0073] 表2:
[0074]
[0075] 然后实施例1中对应的分析过程:
[0076] 基于表2,按宽带账号组合汇总,计算相同宽带账号组合数量。
[0077] 给予的典型表格式为:第一栏为:用户ID,第二栏为:相同宽带账号组合数量,第三栏为:宽带账号组合,第四栏为:时间;例如下表3所示。
[0078] 表3:
[0079] 1306060969 4 01077736,035901218335 2019101417754094744 4 01077736,035901218335 2019101506
2186506407 4 01077736,035901218335 2019101506
3618795540 4 01077736,035901218335 2019101507
[0080] 基于表2,统计同一用户ID一天内的出现次数。按用户ID进行汇总,判断同一用户ID是否在任意连续3个时间段出现。
[0081] 给予的典型表格式为:第一栏为:用户ID,第二栏为:用户ID出现次数,第三栏为:宽带账号组,第四栏为:时间(至少有3个连续时间段)。例如下表4所示。
[0082] 表4:
[0083]
[0084]
[0085] 5、基于表3,按宽带账号组合去重,只保留10及10以上的账号组。例如下表5所示。
[0086] 表5:
[0087] 035702241208,035702256990 1852035702187789,035702262661 1484
035101170273,jst351040812 51
035801032209,035801032239 47
[0088] 6、基于表4,先按宽带账号组合去重,完全相同的账号组合只保留1行。例如下表6所示。
[0089] 表6:
[0090]1538075479 3 035700799424,jst357052265
1538075479 3 jst357052264,jst357052265
1579288322 3 035103079172,035103079185
1579288322 3 035103079185,035103089068
[0091] 然后按照用户ID进行合并,相同的宽带账号组合保留一个。输出表6。
[0092] 表6:
[0093]1538075479 035700799424,jst357052264,jst357052265
1579288322 035103079172,035103079185,035103089068
[0094] 最后结果表:
[0095] 基于表5,把宽带账号组合进行拆分,并按宽带账号去重,然后查询AAA里的账号所属区域,加上检出原因“多次和其他宽带账号被捆绑使用”,最终输出结果表7:
[0096] 表7:
[0097] 035702241208 临汾 多次和其他宽带账号被捆绑使用 2019-10-15035702256990 临汾 多次和其他宽带账号被捆绑使用 2019-10-15
035702187789 太原 多次和其他宽带账号被捆绑使用 2019-10-15
035702262661 太原 多次和其他宽带账号被捆绑使用 2019-10-15
035101170273 太原 多次和其他宽带账号被捆绑使用 2019-10-15
jst351040812 太原 多次和其他宽带账号被捆绑使用 2019-10-15
035801032209 大同 多次和其他宽带账号被捆绑使用 2019-10-15
035801032239 大同 多次和其他宽带账号被捆绑使用 2019-10-15
[0098] 基于表六,把宽带账号组合进行拆分,并按宽带账号去重,然后查询AAA里的账号所属区域,加上检出原因“至少连续3个检测周期被同一用户ID切换使用”,最终输出结果表
8:
[0099] 表8:
[0100]
[0101] 捆绑详情,合并结果表1和结果表2,删除重复的宽带账号,删除检出原因(去重)。然后在表5第一列和表6第二列中,查找去重后结果中的每一个宽带账号,查找其所有的直
接关联宽带账号,以及间接关联账号(关联账号的关联账号)。每个账号1行,不能有重复。
[0102] 例如下表,查询宽带035001605355的时候,关联账号要同时显示035001466027的关联账号和035001466043的关联账号如下:
[0103] 当前账号 关联账号035001605355 035001466027,035001466043
[0104] 实施例3:
[0105] 目前运营商产生的HTTP协议流量日志里面可供使用的信息有[流量源IP地址、流量目的IP地址、流量源端口号、流量目的端口号、Host、URI、User-Agent、日志时间戳]这些必要的字段信息。发明人发现在寻找一个能够唯一标识用户的ID的过程中,由于用户ID唯
一性的要求,需要使用[流量源IP地址]作为被标识的对象,因此[流量源IP地址]这个字段
是有用的,而像[流量目的IP地址]、[流量源端口号]、[流量目的端口号]、[日志时间戳]这些字段信息,不论从某个IP发出的流量是单个设备,还是多个设备,其值都会有多个,因此不存在区别性,因此无法利用。而像[User-Agent]字段,相同种类的设备它的值是相同的,不存在区分性,因此作为唯一标识用户的ID不够充分。
[0106] 综上分析Host信息代表流量访问的目标服务器,而URI里面又包含用户查询参数,类似key=value这样的多个键值对,携带出设备、应用、用户等信息。因此通过进一步分析[Host:key=value](代表Host相同情况下的key参数名下的参数值value)的内容,可以用
于进一步挖掘和分析出用户ID的信息。接下来,将进一步阐述其实现机制。
[0107] 在本发明中统一资源标识符(Uniform Resource Identifier,简写为:URI)字段内容以“&”符号分割每一对参数对,又以“=”符号分割参数名(Key)和参数值(Value);通过上述分析可知悉,一条有效的网络消息中,其可以具有多个key=value这样的键值对,用于携带出设备、应用、用户等信息。由于某些参数名Key在不同的应用中含义或名称不同,如key表现为“u”时,在A应用代表“user”,但在“B”应用中代表“url”,这样单以Key作为索引不够唯一,故在本发明各实施例中以“Host-Key”共同作为索引,然后把每一条流量日志数据中出现的源IP、Value和以下4个计数器(对应IV的计数器、对应Iv的计数器、对应iV的计数器、对应iv的计数器初始值为1)追加到对应的索引之后,这样就构成一个字典集合。构造的结构如下表9所示。
[0108] 表9:
[0109]
[0110] 在每个“Host-Key”内作统计时,相同IP内、不同IP之间Value都可能会有相同或不同的值。作为一个唯一标识用户的ID,理想情况是对于大量不同的IP,在相同的“Host-Key”内出现的不同值要多,这说明大量的用户在使用设备时经常会出现这个Key,并且Value值也不同,代表唯一性,同时不同IP间相同值要少,否则这个Key对于不同的设备不具有辨识度;
[0111] 同时,IP相同时在指定的“Host-Key”内相同值的出现次数要高,以确保在有限的采样时间内能够采集到这个key,也就是作为一个唯一标识用户的ID还要能够复现。
[0112] 对IV、Iv、iV、iv的说明:
[0113] (1)IV:相同IP内相同Host-Key的Value出现相同值的个数计数。
[0114] (2)Iv:相同IP内相同Host-Key的Value出现不同值的个数计数。该值越小越好。因为一个用户若是在使用设备时某个Key的值一直变化,那么它就无法作为用户ID去区别用户,比如随机数和当前时间类的Key等,都是一直在变化的。
[0115] (3)iV:不同IP间相同Host-Key的Value出现相同值的个数计数。因为不同用户在使用设备时产生的值尽可能不同才会有大的区分度。
[0116] (4)iv:不同IP间相同Host-Key的Value出现不同值的个数计数。该值越大越能体现这个“Host-Key”在不同的设备上是高频出现的,具有最大的参考价值。
[0117] 本发明实施例1提供了一种用户ID发现方法,设定对应IP相同情况的标识为I、对应IP不同情况的标识为i、对应Host-Key相同且Host-Key的value值相同情况的标识为V、对应Host-Key相同且Host-Key的value值不同情况的标识为v,如图3所示,方法包括:
[0118] 在步骤301中,将对应IP相同且Host-Key相同且Host-Key的value值相同情况的标识设定为IV;将对应IP相同且Host-Key相同且Host-Key的value值不同情况的标识设定为
Iv;将对应IP不同且Host-Key相同且Host-Key的value值相同情况的标识设定为iV;将对应IP不同且Host-Key相同且Host-Key的value值不同情况的标识设定为iv。
[0119] 在步骤302中,依据IV和iv的参数值越大越优、Iv和iV的参数值越小越优的对应关系,根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分。
[0120] 在步骤303中,根据每一组Host-Key的得分,动态的筛选出当前数据分析场景中的用户ID。
[0121] 本发明实施例中对用户ID的发现是通过现场数据学习到的,而非预先设置好的,具有现场自适应性。通过现场数据能够学习到全量唯一标识用户的ID,因此数量较人为定
义更全面、客观、准确。
[0122] 在本发明实施例中,所述根据对应每一组Host-Key统计的IV、iv、Iv和iV,计算每一组Host-Key的得分,具体包括:
[0123] 根据公式一、Score=(IV*iv)/(Iv*iV)来计算每一组Host-key的得分;或者,
[0124] 根据公式二、Score=(IV-Iv)*(iv-iV)来计算每一组Host-key的得分;或者,
[0125] 根据公式三、Score=(IV+iv)/(IV+iv+Iv+iV)*100来计算每一组Host-key的得分。
[0126] 上述三个公式各有特点,其中,公式一的分差最大,适合于当前分析的数据量较大的场景,从而能够拉开不同Host-Key组合的分差;而公式三属于三个公式中计算最为准确的,但是其劣势也在于计算的结果会比较高概率出现计算分值重叠的情况。具体采用哪一
种公式,则根据实际情况中所涉及的数据量的多少、已经数据中的复杂情况而定。
[0127] 在本发明实施例中,所涉及的从而动态的筛选出当前数据分析场景中的用户ID,在实际实现过程中,至少也可以区分为以下两种情况。
[0128] 情况一、
[0129] 取Host-Key计算得分位于预设第一排名值之前的Host-Key作为当前数据分析场景动态生成的用户ID。其中,所述预设第一排名值为200-500或者排名位于总的前10%作为所述预设第一排名值,优选的,还要综合考虑所述第一排名值之前的用户ID,其所对应的流量数据或者数据大小能够覆盖整个当前场景下数据量的80%以上。在具体实现过程中,若
覆盖量低于70%则可以考虑调整所述第一排名值,即调高所述第一排名值,使得更多的
Host-Key组合被筛选出作为用户ID。
[0130] 情况二:
[0131] 具体为针对同一IP地址,需要确定其用户ID时,方法包括:
[0132] 针对同一IP地址下,将对应的多个Host-Key计算得分进行排序,取其中排名位于第二预设排名之前的Host-Key作为所述IP地址对应的用户ID。其中,第二预设排名包括但
不限于10-50之间任一值,还可以根据具体情况进行调整,通常要保证第二预设排名所指定的Host-Key所标定的数据占总数据的百分比达到80%(这里在互联网领域则可指代的是消
息条数,其他领域还可以指代的是数据大小)以上为优,即保证了所选择出来的用户ID在总数据量中的覆盖特性,表明没有遗漏必要的用户ID。
[0133] 上述两种情况差异在于,情况一是基于数据中IP作为数据标识,并未被所有的携带在各数据中;此时,就需要根据本发明实施例提出的方法,通过直接计算各Host-Key分
值,来得到用户ID。而情况二则是在确保IP被有效携带在数据中,而需要明确出一个可以代替IP成为用户ID的或者是一个在局域网环境下,多终端共用一个IP场景下,如何快速确定
出一个Host-Key,可以用于表征该局域网环境下各个用户的ID。
[0134] 在本发明实施例中,所述Host-Key中的Key包括但不局限于设备MAC地址、手机号、用户名、应用ID、IMEI号、位置信息中的任意一种。
[0135] 在本发明实施例中,为了便于数据的统计,对于获取到数据,按照统计出的Host(i)-Key(i),根据公式:
[0136] Host(i)-Key(i):[IP(1),Value(1),IV(1),Iv(1),iV(1),iv(1)],
[0137] [IP(2),Value(2),IV(2),Iv(2),iV(2),iv(2)],…,[IP(j),Value(j),IV(j),Iv(j),iV(j),iv(j)]进行数据梳理;其中,i为Host-Key组合的标志号,j为对应各Host-Key组合下具体的IP数量。上述公式尤其适用于针对IP分析出可替代所述IP作为设备或者用户标
识的用户ID。
[0138] 实施例3:
[0139] 在本发明实施例中,在使用实施例1所阐述的方法进行测试时,尤其是在实施例1的情况二中进一步寻找唯一ID时,发现一问题,参考如下表二示例:
[0140] 表二:
[0141]Host Key value IV Iv iV iv
dns.weixin.qq.com uin 1305491620 50 3 1188 24332
[0142] 表二中“uin”这个Key经过验证是微信号,可以看到,当iV取最大值时,竟然出现1188个不同IP下的相同微信号,这与实际不符,经查看这1188个出现在不同IP间的相同的
微信号是“0”,显然不是一个真正的微信号,是一种特殊值。所以,为避免在其他Key中出现类似的统计偏差,对4个计数都选取了以次大计数值作为最终统计结果,且经检验效果很
好。
[0143] (1)IV:相同IP内相同Host-Key的Value出现相同值的个数计数,对这些计数值按大小排列,取次大值作为最终结果。取次大值的原因:由于该值越大表明用户在使用设备时都会产生这个值,但当取最大值时可能会导致一些特殊值引入的偏差。
[0144] (2)Iv:相同IP内相同Host-Key的Value出现不同值的个数计数,对这些计数值按大小排列,取次大值作为最终结果。
[0145] (3)iV:不同IP间相同Host-Key的Value出现相同值的个数计数,对这些计数值按大小排列,取次大值作为最终结果。
[0146] (4)iv:不同IP间相同Host-Key的Value出现不同值的个数计数,对这些计数值按大小排列,取次大值作为最终结果。
[0147] 相应的方法过程如图4所示,包括以下步骤:
[0148] 在步骤401中,输入上述构造好的数据进行对比。
[0149] 构造方式具体如实施例1中所展示的,按照统计出的Host(i)-Key(i),根据公式:
[0150] Host(i)-Key(i):[IP(1),Value(1),IV(1),Iv(1),iV(1),iv(1)],[IP(2),Value(2),IV(2),Iv(2),iV(2),iv(2)],…,[IP(j),Value(j),IV(j),Iv(j),iV(j),iv(j)]进行
数据梳理;其中,i为Host-Key组合的标志号,j为对应各Host-Key组合下具体的IP数量。上述公式尤其适用于针对IP分析出可替代所述IP作为设备或者用户标识的ID。
[0151] 在步骤402中,IP相同且Host-Key相同,统计Value值相同的个数赋值给IV。
[0152] 在步骤403中,IP不同且Host-Key相同,统计Value值相同的个数赋值给iV。
[0153] 在步骤404中,IP相同且Host-Key相同,统计Value值不同的个数赋值给Iv。
[0154] 在步骤405中,IP不同且Host-Key相同,统计Value值不同的个数赋值给iv。
[0155] 在步骤406中,IV、Iv、iV、iv计数进行运算后筛选出最终ID。
[0156] 实施例4:
[0157] 本发明实施例,进一步针对实施例21中所提出的ID发现方法,做不同度的实例测试和验证。具体如下:
[0158] 针对实施例2中步骤303中“根据每一组Host-Key的得分”后,进一步的按iv降序排列,可以选出出现频次高的ID,它们在一定程度上反映覆盖网络用户的情况,既应用时的覆盖度或者效果。我们先选出传统ID(IMEI,MAC,IP,IDFA,IMSI等知其意义的ID),再对剩余的进行人为判别得到所有的ID。
[0159] 传统ID的不完全Key列表:
[0160] 'imei','imsi','uuid','idfa','idfv','deviceid','androidid','mac','ip','userid','user_id','uid','token','phone','phone_num','openudid','
deviceId','device_id','android_id','_mac','_imei','username','user ip','
userId','user','uniqueId','uname','uin','udid','ucid','tk','suu id','suid','
signature','sign','openid','openUDID','nickname','model','mobile','mid','
macid','macaddress','mac_address','dviceid','device_type','device_type','
device','dev_id','d_model','cuid','cpu','clien tid','client_userid','_
device','_androidId','UID'
[0161] (1)GET类型数据的分析
[0162] 在Uri ID列表中,对iv大于50的ID,先选出所有的传统ID如MAC地址、IMEI号等(传统ID里也可根据计数器的情况,判断出假ID的情况,既其值并非真如Key名所示)。非传统ID的筛选思想:iv值要大,IV值要大,iV值越小越好,Iv值越小越好,IvAll与iv相差要大,这样再结合Host、Key名称和Value形式等综合选出非传统ID。
[0163] iv越大代表检出率越高,IV越大在采样时间内采集到的概率越大,所以把得到的uri_get终表里这个两个值最大的两个ID作为代表来进行分析:
[0164] 方式一、iv最大的ID:
[0165] 图5是原表(包含所有ID的列表)排名靠前的部分ID截图。图6是uri_get终表(包含所选出uri_get ID的列表)排名前3的ID截图。
[0166] 在uri_get终表(图6)排名第1的ID在原表(图5)排名第8。为验证我们测试时使用iOS系统手机对爱奇艺APP抓包大约5分钟,在该完整pcap包中,域名为
“t7z.cupid.iqiyi.com”Key为“f”的ID,其值总等于域名为“t7z.cupid.iqiyi.com”Key为“idfa”的ID的值(如图7和图8所示),这说明每个设备产生的“f”值唯一,此时Iv值即为某个IP下共享设备的台数,IvAll值即所有IP下发生设备共享上网的IP个数。若“f”的值在每个设备上不唯一,即存在多值,那么Iv就不能代表该IP下共享的设备台数,并且观察发现,这种情况下其Iv值往往会比较大,图5中前7个ID即可说明。
[0167] 统计发现域名“t7z.cupid.iqiyi.com”共出现75次,“idfa”出现20次,“f”出现50次,即说明“f”这种ID的检测率大于“idfa”,并且在原表中“idfa”排名为73(“f”排第8),如图9:
[0168] Key为“f”时其iv值为10597,而“idfa”的iv值为1884,可以得出“f”的检测率约为“idfa”的6倍;Key为“f”时其IvAll值为2988,为“idfa”时其IvAll值为99,可以得出“f”的共享检测率约为“idfa”的30倍。因此从整体来看,仅使用传统ID其检测范围会比较狭隘,检测度不够,增加了非传统ID后其检测率会提高很多。在原表(图5)中,排名10和11的“kp”和“g”,在数据包中发现其值也等于“idfa”的值,这两个ID在uri_get终表(图6)中排名分别为2和3。这恰好体现了非传统ID的覆盖更广。
[0169] 另外,原表前7个ID(图5)不可用的原因:排名前2的两个ID的IV值相对太小,Iv值却很大;前3个和第6、7个的Iv值太大,即说明该ID在同一个IP内出现的值不断变化;第3个和第6个ID的iV值很大,即不同IP出现相同值太多(某些Key例如设备型号虽然,iV也会大,但是仍可以一定程度做为ID使用)。并且从Key的名称上大致可以得出“ri”是一个随机数,“lgt”表示经度,“ltt”代表纬度等,这些Key具有随机性,无法对应出一个设备。
[0170] 方式二、IV最大的ID:
[0171] Host为“cache.video.iqiyi.com”Key为“k_uid”的ID排名14。在同样的pcap包中,该域名共出现13次,“k_uid”也出现13次,即只要出现这个Host就会出现这个Key,所以其IV值比较大也是合理的,这样在有限的采样时间内采集到这个Key的概率也是比较大的。需要注意,“k_uid”也不是传统ID,在此也体现了我们选出非传统ID的优势。“k_uid”的值也是“idfa”,如图11所示:
[0172] 我们测试使用的设备是iOS系统,所以会有idfa这个Key,但是在图10中的值是imei号的形式,因此推断其值在安卓手机中为本机imei值。总之无论在iOS系统还是安卓系统其值都唯一。Iv为11表明某IP下有11台设备在共享,IvAll为1227表明共有1227个IP在共享设备。
[0173] 最终共得到311个ID(包含传统ID和非传统ID)。同样,对iv大于97的前500个Cookie ID进行分析,得367个ID。
[0174] (2)POST类型数据的分析
[0175] 选取iv大于19的前30个Uri ID分析得到24个ID,iv大于17的前30个Cookie ID分析得到30个ID。
[0176] ID表筛选公式:
[0177] 由于IV是越大越好、iV越小越好、iv越大越好、IvAll越小越好,因此可以按照iv降序排序,选出topN个项。然后再根据(IV*iv)/(iV*IvAll)这个公式,算出一个Score分数,对此分数降序排序,即可筛选出topM个最优项(M
[0178] 通过本发明实施例表明,在通过实施例1所述方法结合具体应用场景进行实现还,还可以适当的调整其排序策略,从而取得更优的结果。
[0179] 实施例5:
[0180] 如图12所示,是本发明实施例的带宽捆绑检测装置的架构示意图。本实施例的带宽捆绑检测装置包括一个或多个处理器21以及存储器22。其中,图12中以一个处理器21为
例。
[0181] 处理器21和存储器22可以通过总线或者其他方式连接,图12中以通过总线连接为例。
[0182] 存储器22作为一种非易失性计算机可读存储介质,可用于存储非易失性软件程序和非易失性计算机可执行程序,如实施例1中的带宽捆绑检测方法。处理器21通过运行存储在存储器22中的非易失性软件程序和指令,从而执行带宽捆绑检测方法。
[0183] 存储器22可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,存储器22可选包括相对于处理器21远程设置的存储器,这些远程存储器可以通过网络连接至处理器
21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
[0184] 所述程序指令/模存储在所述存储器22中,当被所述一个或者多个处理器21执行时,执行上述实施例1中的带宽捆绑检测方法,例如,执行以上描述的图1-图4所示的各个步骤。
[0185] 值得说明的是,上述装置和系统内的模块、单元之间的信息交互、执行过程等内容,由于与本发明的处理方法实施例基于同一构思,具体内容可参见本发明方法实施例中
的叙述,此处不再赘述。
[0186] 本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质
可以包括:只读存储器(ROM,Read Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁盘或光盘等。
[0187] 以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈