流量监测、上传控制的方法及设备与流程

文档序号:16685934发布日期:2019-01-22 18:19阅读:293来源:国知局
流量监测、上传控制的方法及设备与流程

本申请涉及信息技术领域,尤其涉及流量监测、上传控制的方法及设备。



背景技术:

在网络系统的p2p(peer-to-peer,对等网络)资源分享场景中,各个节点根据在资源分享中的角色,可以分为供给端和消费端。供给端就是在资源分享的过程中,上传资源的节点,而消费端是指在资源分享的过程中,下载资源的节点。

在上传和下载的过程中,当带宽资源不足时,将会出现带宽资源争夺的情况。带宽资源可以分为下行带宽和上行带宽,其中,下行带宽的控制可以采用避让原则,在带宽分配时优先满足用户正常操作的需求,即资源下载的需求避让用户正常操作的需求。

而上行带宽资源直接决定了供给端节点服务能力的高低,避让过多,会影响节点之间的资源分享。现有技术中,对于上传流量的控制是基于大数据统计所有供给端的平均上行带宽,在此基础上乘以一个系数,并以该值作为供给端上行带宽的上限值。由于该上限值是基于大数据统计得到,对于高带宽和低带宽的用户的限速效果不佳。对于高带宽的用户,按该上限值限速后,上传能力会被限制,而低带宽的用户,该上限值可能比其本身多能提供的最高上行带宽还高,起不到限速效果,会对用户的上网体验会造成影响。

申请内容

本申请的一个目的是提供流量监测、上传控制的方案,用以解决现有技术对高带宽和低带宽的用户限速效果不佳的问题。

为实现上述目的,本申请提供了一种设备,该设备包括:

流量检测装置,用于检测第一时间窗口内的总体上行流量和前一周期内的用户上行流量,其中,所述第一时间窗口至少包含一个周期;

处理装置,用于根据所述总体上行流量确定每个周期的总体上传量,根据所述用户上行流量确定前一周期的用户上传量,以及根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量;

数据发送装置,用于上传数据。

在一种实施例中,所述数据发送装置,还用于在第一时间窗口内向预设目标设备上传数据;

所述流量检测装置,用于根据上传的数据,检测第一时间窗口内的总体上行流量;

所述处理装置,用于根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

在一种实施例中,所述处理装置,用于根据所述第一时间窗口内的总体上行流量,确定上行带宽值;以及根据所述上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量。

在一种实施例中,所述处理装置,用于根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口;以及对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。

在一种实施例中,所述流量检测装置,用于检测前一周期内的总体上行流量和资源上行流量;以及将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。

在一种实施例中,所述处理装置,还用于在确定所述总体上行流量、资源上行流量和用户上行流量时,基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。

在一种实施例中,所述处理装置,用于根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

在一种实施例中,所述处理装置,还用于在收到资源上传请求时,获取当前周期的剩余上传量;以及比较所述资源上传请求所对应的资源的数据量和当前周期的剩余上传量,其中,所述剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差;

所述数据发送装置,还用于基于比较结果上传关于所述资源的数据。

在一种实施例中,所述数据发送装置,用于在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,在当前周期内上传关于所述资源的数据;以及在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。

基于本申请的另一方面,还提供了一种方法,该方法包括:

检测第一时间窗口内的总体上行流量,并根据所述总体上行流量确定每个周期的总体上传量,其中,所述第一时间窗口至少包含一个周期;

检测前一周期内的用户上行流量,并根据所述用户上行流量确定前一周期的用户上传量;

根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量。

在一种实施例中,检测第一时间窗口内的总体上行流量,并根据所述总体上行流量确定每个周期的总体上传量,包括:

在第一时间窗口内向预设目标设备上传数据包;

根据上传的数据,检测第一时间窗口内的总体上行流量;

根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

在一种实施例中,根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量,包括:

根据所述第一时间窗口内的总体上行流量,确定上行带宽值;

根据所述上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量。

在一种实施例中,根据所述第一时间窗口内的总体上行流量,确定上行带宽值,包括:

根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口;

对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。

在一种实施例中,检测前一周期内的用户上行流量,包括:

检测前一周期内的总体上行流量和资源上行流量;

将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。

在一种实施例中,该方法还包括:

在确定所述总体上行流量、资源上行流量和用户上行流量时,基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。

在一种实施例中,根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量,包括:

根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

本申请还提供了另一种方法,该方法还包括:

在收到资源上传请求时,获取当前周期的剩余上传量,其中,所述剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差,所述当前周期的可用上传量基于前述的方法获取;

比较所述资源上传请求所对应的资源的数据量和当前周期的剩余上传量,基于比较结果上传关于所述资源的数据。

在一种实施例中,基于比较结果发送所述资源上传请求所对应的资源,包括:

在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,在当前周期内上传关于所述资源的数据;

在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。

此外,本申请还提供了一种设备,该设备包括处理器和存储有机器可读指令的一个或多个机器可读介质,当所述处理器执行所述机器可读指令时,使得所述设备执行前述任一项所述的方法。

与现有技术相比,本申请提供的方案中,先检测第一时间窗口内的总体上行流量,并根据所述总体上行流量确定每个周期的总体上传量,然后检测前一周期内的用户上行流量,并根据所述用户上行流量确定前一周期的用户上传量,再根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量。通过检测流量的方式,使得获取到的每个周期的总体上传量、用户上传量与供给端节点的实际运行情况相符,在每个周期开始时,计算当前周期的可用上传量,由此,在保证供给端节点服务能力的同时,为用户正常上网预留一定的带宽,避免影响用户正常上网。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:

图1为一种资源分享的场景示意图;

图2为另一种资源分享的场景示意图;

图3为本申请实施例提供的一种设备的示意图;

图4为本申请实施例提供的一种方法的示意图;

图5为本申请实施例提供的另一种方法的示意图;

图6示意性地示出了可被用于实施本申请中所述的各个实施例的示例性系统;

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在下面的具体描述中,给出大量特定细节,从而提供对一个实施例的透彻理解。但是,将由本领域普通技术人员理解到,一个实施例可以在没有这些特定细节的情况下实践。在其他实例中,众所周知的方法、过程、组件、单元和/或电路没有具体描述以免混淆讨论。

此处,利用诸如例如为“处理”、“计算”、“运算”、“确定”、“建立”、“分析”、“检查”、或类似者的术语的讨论可以指代计算机、计算平台、计算系统、或其它电子计算设备的(多个)操作和/或(多个)处理,其操纵和/或变换呈现为计算机的寄存器和/或存储器内的物理(例如,电子)量的数据成类似地呈现为计算机的寄存器和/或存储器或其它信息存储介质内的物理量的其它数据,该计算机的寄存器和/或存储期或其它信息存储介质可以存储指令以执行操作和/或处理。

引用“一个实施例”、“实施例”、“说明性的实施例”、“各种实施例”等指示这样描述的(多个)实施例可以包括特别的特征、结构或特性,但是不是每个实施例一定包括特别的特征、结构、或特性。进一步,措词“在一个实施例中”的重复使用不一定指代相同的实施例。

如这里所使用的,除非另有规定,使用序数形容词“第一”、“第二”、“第三”等来描述通用的对象仅仅指示指代类似的对象的不同的实例并且不意图暗示这样描述的对象必须是所给定的顺序,该给定的顺序为时间、空间、排序、或以任意其它方式的。

某些实施例可以结合各种设备和系统使用,例如,个人计算机(pc)、台式计算机、移动计算机、膝上型计算机、笔记本计算机、平板计算机、智能手机设备、服务器计算机、手持计算机、手持设备、个人数字助理(pda)设备、手持pda设备、混合设备、车载设备、移动或便携式设备、消费者设备、非移动或非便携式设备、无线通信站、无线通信设备、无线接入点(ap)、有线或无线路由器、有线或无线调制解调器、视频设备、音频设备、音频-视频(a/v)设备、有线或无线网络、具有一个或多个内置天线和/或外置天线的设备、数字视频广播(dvb)设备或系统、多标准无线电设备或系统、有线或无线手持设备,例如,智能手机、无线应用协议(wap)设备以及类似者。

在以下详细说明中,参考构成本文的一部分的附图,其中相同的数字在全文中指相同的部分,并且其中阐述的实施例为本发明的主题可实现的。应当知道可使用其他实施例,并且可实现不脱离本发明范围的结构或逻辑的改变。因此,以下详细说明不是为了限制的意思,并且实施例的范围限定在附带的权利要求和它们的等同替代。

各种操作以理解声称的主题最有帮助的方式描述为多个离散的动作或轮流操作。然而,说明书的顺序不应当解释为暗示这些操作为必要的相关顺序。特别地,这些操作不按照呈现的顺序执行。本文描述的操作以描述的实施例不同的顺序来执行。不同的附带操作可被执行和/或在附带的实施例中省略描述的操作。

此外,本申请描述中的短语“a和/或b”意味着(a)、(b)或(a和b);短语“a、b和/或c”意味着(a)、(b)、(c)、(a和b)、(a和c)、(b和c)或(a、b和c)。

图1示出了一种资源分享的场景示意图,在该次资源分享过程中,设备101向设备102发送关于资源a的相关数据,即设备101是资源分享的供给端节点,而设备102是资源分享的消费端节点。对于设备101,其在运行过程中的总体上行流量包括两部分流量,即资源上行流量以及用户上行流量。其中,资源上行流量即设备101为发送资源a所产生的流量,用户上行流量即除资源上行流量之外,用户正常使用设备101的上网功能(例如用户浏览网页、进行即时通信等)所产生的流量,在产生这些流量的过程中,均需要占用一定的上行带宽。

图2示出了另一种资源分享的场景示意图,在该次资源分享过程中,设备201经由设备203向设备202发送关于资源a的相关数据,设备201是资源分享的供给端节点,设备202是资源分享的消费端节点,设备203是数据传输过程中的中间节点,例如提供路由、数据转发等功能的设备等。

对于设备201,其在运行过程中的总体上行流量包括资源上行流量以及用户上行流量,其中,资源上行流量即设备201为发送资源a所产生的流量,用户上行流量即除资源上行流量之外,用户正常使用设备201的其它功能(例如用户浏览网页、进行即时通信等)所产生的流量。对于设备203,在其在运行过程中的资源上行流量是指设备203、以及所有将设备203作为中间节点上传数据的设备(例如设备204、205等)在上传相应资源时所产生的流量,而用户上行流量是指设备203、以及所有将设备203作为中间节点上传数据的设备在实现用户正常上网时所产生的流量。

图3示出了本申请一种实施例提供的设备,用于实现流量监测,可以在每个周期开始时获取当前周期的可用上传量。所述设备可以包括流量检测装置310、处理装置320和数据发送装置330。其中,流量检测装置310用于检测第一时间窗口内的总体上行流量和前一周期内的用户上行流量。处理装置320用于根据所述总体上行流量确定每个周期的总体上传量,根据所述用户上行流量确定前一周期的用户上传量,以及根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量;数据发送装置330用于上传数据。

其中,第一时间窗口是指设备对上行流量进行探测的时间窗口,第一时间窗口的长度和具体时间段可以根据实际需求进行设定,其长度至少需要包含一个周期,从而可以根据该第一时间窗口内的总体上行流量来计算每个周期的总体上传量。在实际场景中,为保证每个周期的总体上传量的准确度,可以选择在用户使用网络的低谷时间段中设定第一时间窗口,并且第一时间窗口包含的周期越多,据此计算的每个周期的总体上传量也越准确。例如,周期可以是1s等,而第一时间窗口可以设定为凌晨三点至四点的一个小时,第一时间窗口内检测到的总体上行流量为7200mb,则可以计算出每个周期的总体上传量为7200/3600=2mb。

每个周期的总体上传量是指每个周期内,设备可以上传的数据量的上限值,用户上传量是指周期内用户正常上网时实际产生的数据量,可用上传量是指周期内可以用于上传分享的资源的数据量。本申请的一个实施例中,通过检测流量的方式,使得获取到的每个周期的总体上传量、用户上传量与供给端节点的实际运行情况相符,在每个周期开始时,根据如下公式计算当前周期的可用上传量:当前周期的可用上传量=每个周期的总体上传量-前一周期的用户上传量。由此,在保证供给端节点服务能力的同时,为用户正常上网预留一定的带宽,避免影响用户正常上网。

例如,检测获得每个周期的总体上传量为2mb,上一周期的用户上传量为0.5mb,考虑到用户正常上网时用户上传流量在短时间内的连续性,即后一周期的用户上传量很有可能与前一周期的用户上传量类似,因此可以计算出当前周期的可用上传量为2mb-0.5mb=1.5mb,由此可以在保证供给端节点服务能力的同时,在一定程度上避免影响用户正常上网。

在实际场景中,用户正常上网时用户上传流量在短时间内存在连续性的可能较高,但是后一周期的用户上传量明显高于前一周期的可能性也同样存在,此时前述实施例的方式将会影响用户正常上网。为解决该问题,处理装置320在根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量时,可以进一步引入预留预留上传量,即根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

在一个实施例中,每个周期的预留上传量可以基于如下公式计算:预留上传量=每个周期的总体上传量×预留系数。例如预留系数设定为0.2,检测获得每个周期的总体上传量为2mb,上一周期的用户上传量为0.5mb,则可以计算出当前周期的可用上传量为:2mb-0.5mb-2mb×0.2=1.1mb。由此,即使在后一周期的用户上传量相较于前一周期突然增加了0.4mb,也不会影响用户正常上网。

在一个实施例中,获取每个周期的总体上传量的原理可以是:获取设备本地的资源,在某一时间段内持续向预设目标设备(例如预先指定的服务器)发送数据,使得上行带宽的负载达到最大,然后根据发送这些数据时产生的流量计算出每个周期的总体上传量。在获取每个周期的总体上传量的处理过程中,设备的数据发送装置在第一时间窗口内向预设目标设备上传数据包;流量检测装置根据上传的数据,检测第一时间窗口内的总体上行流量;处理装置根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

由于在探测总体上传量的过程中,需要使得上行带宽的负载达到最大,容易影响到用户正常上网。因此,可以通过选取用户正常上网的低谷时间段探测总体上传量,例如每天的凌晨三至四点之间的某一时间段等,由此可以避免影响到用户正常上网。在一个实施例中,可以通过通过大数据分析的方式确定出用户使用设备进行正常上网的低谷时间段,将该时间段确定为第一时间窗口。

处理装置在根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量时,可以首先根据所述第一时间窗口内的总体上行流量,确定上行带宽值,其中,上行带宽值是指第一时间窗口内单位时间的总体上传量,例如2mb/s。然后,根据上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量,在一个实施例中周期时长可以根据实际场景的需求进行设定,例如设定为1s、2s等。若周期时长为1s,则可以计算出每个周期的总体上传量为2mb/s×1s=2mb。

在一个实施例中,处理装置在确定上行带宽值时,首先根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口,例如第一时间窗口为每天凌晨三至四点之间选取的n秒时间,而第二时间窗口可以是该n秒时间内的每一秒,由此,记录第一时间窗口内的多个上行带宽候选值。在获取到多个上行带宽候选值之后,可以对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。其中,预设排序位置可以根据经验值进行设定,例如本实施例中该预设位置可以设定为排序的前5%位置,具体实现可以是将上行带宽候选值从高往低排序,过滤掉前部5%的数据,从剩下的上行带宽候选值中取最高的一个,作为上行带宽值,由此可以减少探测数据的波动对最终获取的上行带宽值的影响,提高精确性。

流量检测装置在检测前一周期内的用户上行流量时,可以直接检测到前一周期内的总体上行流量和资源上行流量,然后将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。即前一周期内的用户上行流量=前一周期内的总体上行流量-前一周期内的资源上行流量。

在实际场景中,不同的资源分享方式可能会基于不同的协议,并通过设备上的不同程序、应用、组件等实现数据传输功能,例如在p2p网络(对等计算机网络)中实现数据分享时,供给端节点会通过p2p组件(例如p2p加速器)等实现资源数据上传,因此通过p2p组件可以获取到资源上行流量。相应地,对于其它的资源分享方式,也可以通过相应的程序、应用、组件等获取到资源上行流量,以用于计算用户上行流量。而总体上行流量可以通过检测设备接入网络的入口在设备运行过程中所产生的所有的上行流量来确定。

为了进一步减少因资源上传而挤占用户正常上网所需要的带宽的情况,处理装置还可以在确定所述总体上行流量、资源上行流量和用户上行流量时,基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。即在统计总体上行流量和资源上行流量的值时,使得最终的统计值低于实际值,而统计在用户上行流量的值时,使得最终的统计值高于实际值,由此可以减少探测总体上行流量和资源上行流量的误差带来的影响,优先保证用户正常上网的带宽需求。

在一种实施例中,预设规则的实现方式可以是对总体上行流量、资源上行流量以及用户上行流量进行单元化处理,例如以64kb(可以根据实际情况调整)为一个上行流量的单元。在统计总体上行流量和资源上行流量的值,对于不足64kb的部分,进行去尾处理。例如总体上行流量的实际值为1299kb,则最终得到的总体上行流量的统计值为:64kb×20=1280kb,对于多余的19kb不计入最终的统计值。反之,在统计用户上行流量时,对于不足64kb的部分,可以统计为64kb。例如,用户上行流量的实际值为1299kb,则最终得到的用户上行流量的统计值为:64kb×21=1344kb,对于多余的19kb,以64kb计入最终的统计值中。

此外,预设规则的实现方式也可以是将总体上行流量、资源上行流量和用户上行流量的实际值,乘以一个预设的系数,来作为最终的统计值,例如总体上行流量和资源上行流量的系数为0.95,而用户上行流量的系数为1.05。在此,本领域技术人员应当理解上述预设规则的实现方式仅为举例,其他现有的或今后可能出现的预设规则的实现方式如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。

在一个实施例中,图3所示的设备还可以用于进行上传控制,即在每次收到资源上传请求时,对相应资源的上传进行控制,以避免影响用户正常上网的需求。其中,处理装置320可以在收到资源上传请求时,获取当前周期的剩余上传量,该剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差。当前周期内已经产生的资源上行流量基于当前周期内已经处理的资源上传请求产生,例如,已经处理过一次资源上传请求,消耗的资源上传流量为0.4mb,此时又接收到一资源上传请求需要处理,若当前周期的可用上传量为1.5mb,则可以计算出当前周期的剩余上传量为1.5mb-0.4mb=1.1mb。而对于每一周期内第一次收到的资源上传请求,由于当前周期内已经产生的资源上行流量为0,其当前周期的剩余上传量等于当前周期的可用上传量。

在确定当前周期的剩余上传量之后,处理装置320可以比较所述资源上传请求所对应的资源的数据量和当前周期的剩余上传量,来获取比较结果。所述数据发送装置330基于比较结果上传关于所述资源的数据。

在一个实施例中,所述比较结果至少包括两种:所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量,以及所述资源上传请求所对应的资源的数据量大于所述剩余上传量。

例如,本次资源上传请求所对应的资源的数据量为0.9mb,而当前周期的剩余上传量为1.1mb,则属于前一种情况。在资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,数据发送装置在当前周期内上传关于所述资源的数据。

若本次资源上传请求所对应的资源的数据量为1.9mb,则所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量,当前周期的剩余上传量不足以处理本次资源上传请求,此时,数据发送装置将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。即对于该1.9mb大小的资源,由于当前周期的剩余上传量为1.1mb,可以在当前周期内上传不超过1.1mb的数据,未在本次上传的其余部分可以在后续周期内进行上传,其中,后续周期可以是此后的一个或者多个周期。

基于同一发明构思,本申请的实施例还提供了相应的方法,该方法对应的设备是前述实施例中所提供的设备,并且其解决问题的原理与这些设备相似。

图4示出了本申请一种实施例提供的方法,该方法用于实现流量监测,可以在每个周期开始时获取当前周期的可用上传量,包括如下处理过程:

方框401,由流量检测装置或其它装置检测第一时间窗口内的总体上行流量,并由处理装置或其它装置根据所述总体上行流量确定每个周期的总上传量。

方框402,由流量检测装置或其它装置检测前一周期内的用户上行流量,并由处理装置或其它装置根据所述用户上行流量确定前一周期的用户上传量。

方框403,由处理装置或其它装置根据每个周期的总上传量和前一周期的用户上传量,获取当前周期的可用上传量。

第一时间窗口是指设备对上行流量进行探测的时间窗口,第一时间窗口的长度和具体时间段可以根据实际需求进行设定,其长度至少需要包含一个周期,从而可以根据该第一时间窗口内的总体上行流量来计算每个周期的总体上传量。在实际场景中,为保证每个周期的总体上传量的准确度,可以选择在用户使用网络的低谷时间段中设定第一时间窗口,并且第一时间窗口包含的周期越多,据此计算的每个周期的总体上传量也越准确。例如,周期可以是1s等,而第一时间窗口可以设定为凌晨三点至四点的一个小时,第一时间窗口内检测到的总体上行流量为7200mb,则可以计算出每个周期的总体上传量为7200/3600=2mb。

其中,每个周期的总体上传量是指每个周期内,设备可以上传的数据量的上限值,用户上传量是指周期内用户正常上网时实际产生的数据量,可用上传量是指周期内可以用于上传分享的资源的数据量。本申请的一个实施例中,通过检测流量的方式,使得获取到的每个周期的总体上传量、用户上传量与供给端节点的实际运行情况相符,在每个周期开始时,根据如下公式计算当前周期的可用上传量:当前周期的可用上传量=每个周期的总体上传量-前一周期的用户上传量。由此,在保证供给端节点服务能力的同时,为用户正常上网预留一定的带宽,避免影响用户正常上网。

例如,检测获得每个周期的总体上传量为2mb,上一周期的用户上传量为0.5mb,考虑到用户正常上网时用户上传流量在短时间内的连续性,即后一周期的用户上传量很有可能与前一周期的用户上传量类似,因此可以计算出当前周期的可用上传量为2mb-0.5mb=1.5mb,由此可以在保证供给端节点服务能力的同时,在一定程度上避免影响用户正常上网。

在实际场景中,用户正常上网时用户上传流量在短时间内存在连续性的可能较高,但是后一周期的用户上传量明显高于前一周期的可能性也同样存在,此时前述实施例的方式将会影响用户正常上网。为解决该问题,方框403中,处理装置或其它装置在根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量时,可以进一步引入预留预留上传量,即根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

在一个实施例中,每个周期的预留上传量可以基于如下公式计算:预留上传量=每个周期的总体上传量×预留系数。例如预留系数设定为0.2,检测获得每个周期的总体上传量为2mb,上一周期的用户上传量为0.5mb,则可以计算出当前周期的可用上传量为:2mb-0.5mb-2mb×0.2=1.1mb。由此,即使在后一周期的用户上传量相较于前一周期突然增加了0.4mb,也不会影响用户正常上网。

在一个实施例中,获取每个周期的总体上传量的原理可以是:获取设备本地的资源,在某一时间段内持续向预设目标设备(例如预先指定的服务器)发送数据,使得上行带宽的负载达到最大,然后根据发送这些数据时产生的流量计算出每个周期的总体上传量。在获取每个周期的总体上传量的处理过程中,设备的数据发送装置在第一时间窗口内向预设目标设备上传数据包;流量检测装置根据上传的数据,检测第一时间窗口内的总体上行流量;处理装置根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

由于在探测总体上传量的过程中,需要使得上行带宽的负载达到最大,容易影响到用户正常上网。因此,可以通过选取用户正常上网的低谷时间段探测总体上传量,例如每天的凌晨三至四点之间的某一时间段等,由此可以避免影响到用户正常上网。在一个实施例中,可以通过通过大数据分析的方式确定出用户使用设备进行正常上网的低谷时间段,将该时间段确定为第一时间窗口。

处理装置在根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量时,可以首先根据所述第一时间窗口内的总体上行流量,确定上行带宽值,其中,上行带宽值是指第一时间窗口内单位时间的总体上传量,例如2mb/s。然后,根据上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量,在一个实施例中周期时长可以根据实际场景的需求进行设定,例如设定为1s、2s等。若周期时长为1s,则可以计算出每个周期的总体上传量为2mb/s×1s=2mb。

在一个实施例中,在确定上行带宽值时,首先根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口,例如第一时间窗口为每天凌晨三至四点之间选取的n秒时间,而第二时间窗口可以是该n秒时间内的每一秒,由此,记录第一时间窗口内的多个上行带宽候选值。在获取到多个上行带宽候选值之后,可以对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。其中,预设排序位置可以根据经验值进行设定,例如本实施例中该预设位置可以设定为排序的前5%位置,具体实现可以是将上行带宽候选值从高往低排序,过滤掉前部5%的数据,从剩下的上行带宽候选值中取最高的一个,作为上行带宽值,由此可以减少探测数据的波动对最终获取的上行带宽值的影响,提高精确性。

在检测前一周期内的用户上行流量时,可以直接检测到前一周期内的总体上行流量和资源上行流量,然后将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。即前一周期内的用户上行流量=前一周期内的总体上行流量-前一周期内的资源上行流量。

在实际场景中,不同的资源分享方式可能会基于不同的协议,并通过设备上的不同程序、应用、组件等实现数据传输功能,例如在p2p网络(对等计算机网络)中实现数据分享时,供给端节点会通过p2p组件(例如p2p加速器)等实现资源数据上传,因此通过p2p组件可以获取到资源上行流量。相应地,对于其它的资源分享方式,也可以通过相应的程序、应用、组件等获取到资源上行流量,以用于计算用户上行流量。而总体上行流量可以通过检测设备接入网络的入口在设备运行过程中所产生的所有的上行流量来确定。

为了进一步减少因资源上传而挤占用户正常上网所需要的带宽的情况,本申请一种实施例提供的方法中,在由处理装置或者其它装置确定所述总体上行流量、资源上行流量和用户上行流量时,可以基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。即在统计总体上行流量和资源上行流量的值时,使得最终的统计值低于实际值,而统计在用户上行流量的值时,使得最终的统计值高于实际值,由此可以减少探测总体上行流量和资源上行流量的误差带来的影响,优先保证用户正常上网的带宽需求。

在一种实施例中,预设规则的实现方式可以是对总体上行流量、资源上行流量以及用户上行流量进行单元化处理,例如以64kb(可以根据实际情况调整)为一个上行流量的单元。在统计总体上行流量和资源上行流量的值,对于不足64kb的部分,进行去尾处理。例如总体上行流量的实际值为1299kb,则最终得到的总体上行流量的统计值为:64kb×20=1280kb,对于多余的19kb不计入最终的统计值。反之,在统计用户上行流量时,对于不足64kb的部分,可以统计为64kb。例如,用户上行流量的实际值为1299kb,则最终得到的用户上行流量的统计值为:64kb×21=1344kb,对于多余的19kb,以64kb计入最终的统计值中。

此外,预设规则的实现方式也可以是将总体上行流量、资源上行流量和用户上行流量的实际值,乘以一个预设的系数,来作为最终的统计值,例如总体上行流量和资源上行流量的系数为0.95,而用户上行流量的系数为1.05。在此,本领域技术人员应当理解上述预设规则的实现方式仅为举例,其他现有的或今后可能出现的预设规则的实现方式如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。

本申请一个实施例提供的方法还可以用于进行上传控制,即在每次收到资源上传请求时,对相应资源的上传进行控制,以避免影响用户正常上网的需求。该方法的处理过程如图5所示,包括:

方框501,由处理装置或者其它装置在收到资源上传请求时,获取当前周期的剩余上传量。该剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差,其中,获取当前周期的剩余上传量的方式可以基于前述实施例中任意一种用于实现流量监测的方法实现。当前周期内已经产生的资源上行流量基于当前周期内已经处理的资源上传请求产生,例如,已经处理过一次资源上传请求,消耗的资源上传流量为0.4mb,此时又接收到一资源上传请求需要处理,若当前周期的可用上传量为1.5mb,则可以计算出当前周期的剩余上传量为1.5mb-0.4mb=1.1mb。而对于每一周期内第一次收到的资源上传请求,由于当前周期内已经产生的资源上行流量为0,其当前周期的剩余上传量等于当前周期的可用上传量。

方框502,由处理装置或者其它装置比较所述上传请求所对应的资源的数据量和当前周期的剩余上传量,来获取比较结果。

方框503,由数据发送装置或者其它装置基于比较结果上传关于所述资源的数据。

在一个实施例中,所述比较结果至少包括两种:所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量,以及所述资源上传请求所对应的资源的数据量大于所述剩余上传量。

例如,本次资源上传请求所对应的资源的数据量为0.9mb,而当前周期的剩余上传量为1.1mb,则属于前一种情况。在资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,数据发送装置或其他装置在当前周期内上传关于所述资源的数据。

若本次资源上传请求所对应的资源的数据量为1.9mb,则所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量,当前周期的剩余上传量不足以处理本次资源上传请求,此时,数据发送装置或其他装置将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。即对于该1.9mb大小的资源,由于当前周期的剩余上传量为1.1mb,可以在当前周期内上传不超过1.1mb的数据,未在本次上传的其余部分可以在后续周期内进行上传,其中,后续周期可以是此后的一个或者多个周期。

本实施例可被实现为使用任意适当的硬件和/或软件进行想要的配置的系统。图6示意性地示出了可被用于实现本申请实施例中所述的各个实施例的示例性系统600。对于一个实施例,图6示出了示例性系统600,该系统具有一个或多个处理器605、被耦合到(一个或多个)处理器605中的至少一个的系统控制模块610、被耦合到系统控制模块610的系统存储器615、被耦合到系统控制模块610的非易失性存储器(nvm)/存储设备620、以及被耦合到系统控制模块610的一个或多个通信接口625。

在一些实施例中,系统600能够作为本申请中所述的设备。在一些实施例中,系统600可包括具有指令的一个或多个机器可读介质(例如,系统存储器或nvm/存储设备620)以及与该一个或多个机器可读介质耦合并被配置为执行指令以实现模块从而执行本申请实施例中所述的方法的一个或多个处理器(例如,(一个或多个)处理器605)。

对于一个实施例,系统控制模块610可包括任意适当的接口控制器,以向(一个或多个)处理器605中的至少一个和/或与系统控制模块610通信的任意适当的设备或组件提供任意适当的接口。

系统控制模块610可包括存储器控制器模块630,以向系统存储器615提供接口。存储器控制器模块630可以是硬件模块、软件模块和/或固件模块。

系统存储器615可被用于例如为系统600加载和存储数据和/或指令。对于一个实施例,系统存储器615可包括任意适当的易失性存储器,例如,适当的dram。在一些实施例中,系统存储器615可包括双倍数据速率类型四同步动态随机存取存储器(ddr4sdram)。

对于一个实施例,系统控制模块610可包括一个或多个输入/输出(i/o)控制器,以向nvm/存储设备620及(一个或多个)通信接口625提供接口。

例如,nvm/存储设备620可被用于存储数据和/或指令。nvm/存储设备620可包括任意适当的非易失性存储器(例如,闪存)和/或可包括任意适当的(一个或多个)非易失性存储设备(例如,一个或多个硬盘驱动器(hdd)、一个或多个光盘(cd)驱动器和/或一个或多个数字通用光盘(dvd)驱动器)。

nvm/存储设备620可包括在物理上作为系统600被安装在其上的设备的一部分的存储资源,或者其可被该设备访问而不必作为该设备的一部分。例如,nvm/存储设备620可通过网络经由(一个或多个)通信接口625进行访问。

(一个或多个)通信接口625可为系统600提供接口以通过一个或多个网络和/或与任意其他适当的设备通信。系统600可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信。例如,(一个或多个)通信接口625可与以上针对图1所探讨的收发器模块140耦合。

对于一个实施例,(一个或多个)处理器605中的至少一个可与系统控制模块610的一个或多个控制器(例如,存储器控制器模块630)的逻辑封装在一起。对于一个实施例,(一个或多个)处理器605中的至少一个可与系统控制模块610的一个或多个控制器的逻辑封装在一起以形成系统级封装(sip)。对于一个实施例,(一个或多个)处理器605中的至少一个可与系统控制模块610的一个或多个控制器的逻辑集成在同一模具上。对于一个实施例,(一个或多个)处理器605中的至少一个可与系统控制模块610的一个或多个控制器的逻辑集成在同一模具上以形成片上系统(soc)。

在各个实施例中,系统600可以但不限于是:服务器、工作站、台式计算设备或移动计算设备(例如,膝上型计算设备、手持计算设备、平板电脑、上网本等)、路由器、无线接入点(ap)等。在各个实施例中,系统600可具有更多或更少的组件和/或不同的架构。例如,在一些实施例中,系统600包括一个或多个摄像机、键盘、液晶显示器(lcd)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(asic)和扬声器等。

本申请实施例提供了方法和设备,示例1可包括一种设备,该设备包括:流量检测装置,用于检测第一时间窗口内的总体上行流量和前一周期内的用户上行流量;处理装置,用于根据所述总体上行流量确定每个周期的总体上传量,根据所述用户上行流量确定前一周期的用户上传量,以及根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量;数据发送装置,用于上传数据。

示例2可包括示例1的设备,其中,所述数据发送装置,还用于在第一时间窗口内向预设目标设备上传数据;所述流量检测装置,用于根据上传的数据,检测第一时间窗口内的总体上行流量;所述处理装置,用于根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

示例3可包括示例1或2的设备,其中,所述处理装置,用于根据所述第一时间窗口内的总体上行流量,确定上行带宽值;以及根据所述上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量。

示例4可包括示例1-3的任一项设备,其中,所述处理装置,用于根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口;以及对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。

示例5可包括示例1-4的任一项设备,流量检测装置,用于检测前一周期内的总体上行流量和资源上行流量;以及将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。

示例6可包括示例1-5的任一项设备,所述处理装置,还用于在确定所述总体上行流量、资源上行流量和用户上行流量时,基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。

示例7可包括示例1-6的任一项设备,所述处理装置,用于根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

示例8可包括示例1-7的任一项设备,其中,所述处理装置,用于在收到资源上传请求时,获取当前周期的剩余上传量;以及比较所述资源上传请求所对应的资源的数据量和当前周期的剩余上传量,其中,所述剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差;所述数据发送装置,用于基于比较结果上传关于所述资源的数据。

示例9可包括示例8的设备,所述数据发送装置,用于在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,在当前周期内上传关于所述资源的数据;以及在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。

示例10可包括一种方法,该方法包括:检测第一时间窗口内的总体上行流量,并根据所述总体上行流量确定每个周期的总体上传量;检测前一周期内的用户上行流量,并根据所述用户上行流量确定前一周期的用户上传量;根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量。

示例11可包括示例10的方法,其中,检测第一时间窗口内的总体上行流量,并根据所述总体上行流量确定每个周期的总体上传量,包括:

在第一时间窗口内向预设目标方法上传数据包;

根据上传的数据,检测第一时间窗口内的总体上行流量;

根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量。

示例12可包括示例10或11的方法,其中,根据所述第一时间窗口内的总体上行流量,确定每个周期的总体上传量,包括:

根据所述第一时间窗口内的总体上行流量,确定上行带宽值;

根据所述上行带宽值以及每个周期的周期时长,获取每个周期的总体上传量。

示例13可包括示例10-12的任一项方法,其中,根据所述第一时间窗口内的总体上行流量,确定上行带宽值,包括:

根据多个第二时间窗口内上传数据的总体上行流量,确定多个上行带宽候选值,其中,所述第二时间窗口为所述第一时间窗口的子窗口;

对所述上行带宽候选值进行排序,将预设排序位置的上行带宽候选值确定为所述上行带宽值。

示例14可包括示例10-13的任一项方法,其中,检测前一周期内的用户上行流量,包括:

检测前一周期内的总体上行流量和资源上行流量;

将所述总体上行流量与资源上行流量的差,确定为前一周期内的用户上行流量。

示例15可包括示例10-14的任一项方法,其中,该方法还包括:

在确定所述总体上行流量、资源上行流量和用户上行流量时,基于预设处理规则,缩小所述总体上行流量和资源上行流量的值和/或放大所述用户上行流量的值。

示例16可包括示例10-14的任一项方法,其中,根据每个周期的总体上传量和前一周期的用户上传量,获取当前周期的可用上传量,包括:

根据每个周期的总体上传量、前一周期的用户上传量以及每个周期的预留上传量,获取当前周期的可用上传量。

示例17可包括一种方法,其中,该方法还包括:

在收到资源上传请求时,获取当前周期的剩余上传量,其中,所述剩余上传量为当前周期的可用上传量与当前周期内已经产生的资源上行流量之差,所述当前周期的可用上传量基于示例10-16中任一项方法获取;

比较所述资源上传请求所对应的资源的数据量和当前周期的剩余上传量,基于比较结果上传关于所述资源的数据。

示例18可包括示例17的方法,其中,基于比较结果发送所述资源上传请求所对应的资源,包括:

在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,在当前周期内上传关于所述资源的数据;

在所述资源上传请求所对应的资源的数据量小于等于所述剩余上传量时,将所述资源中小于等于所述剩余上传量的部分在当前周期内上传,将所述资源的其余部分在后续周期内上传。

示例19可包括一种设备,其中,该设备包括处理器和存储有机器可读指令的一个或多个机器可读介质,当所述处理器执行所述机器可读指令时,使得所述设备执行示例10-16中任一项方法。

示例20可包括一种设备,其中,该设备包括处理器和存储有机器可读指令的一个或多个机器可读介质,当所述处理器执行所述机器可读指令时,使得所述设备执行示例17或18的方法。

需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(asic)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,ram存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。

另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据程序指令运行的计算机设备的工作存储器中。

对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1