CN112838989A - 一种数据流管理方法、网络设备及存储介质 - Google Patents

一种数据流管理方法、网络设备及存储介质 Download PDF

Info

Publication number
CN112838989A
CN112838989A CN201911168077.9A CN201911168077A CN112838989A CN 112838989 A CN112838989 A CN 112838989A CN 201911168077 A CN201911168077 A CN 201911168077A CN 112838989 A CN112838989 A CN 112838989A
Authority
CN
China
Prior art keywords
management
data
data stream
area
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CN201911168077.9A
Other languages
English (en)
Inventor
惠羿
魏霄鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201911168077.9A priority Critical patent/CN112838989A/zh
Publication of CN112838989A publication Critical patent/CN112838989A/zh
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames

Abstract

本发明实施例提供一种数据流管理方法、网络设备及存储介质,网络设备对数据流进行“分区管理”,按照不同的热度等级设置至少两个管理区,每个管理区唯一对应一个热度等级。对于任意一个数据流,按照该数据流的流量活跃程度确定该数据流的热度等级,从而将该数据流划分到对应的管理区当中。在从数据包接收队列中获取当前待处理的目标数据包后,网络设备按照热度等级从高至低的顺序在各管理区中查询该目标数据包对应的数据流。网络设备极有可能在热度等级较高的管理区中匹配出该目标数据包对应的数据流,这样,对于剩余热度等级低的管理区中的数据流,网络设备就不需要继续查询,能够在很大程度上减少查询负担,提升查询效率,提升管理性能。

Description

一种数据流管理方法、网络设备及存储介质
技术领域
本发明涉及网络通信领域,尤其涉及一种数据流管理方法、网络设备及存储介质。
背景技术
随着通信网络发展,网络数据不断膨胀,媒体面(Data Plane)的业务需求也越来越多,例如,防火墙、ACL(Access Control List,访问控制列表)、TCP(TransmissionControl Protocol,传输控制协议)加速、家长控制儿童上网、DPI(Deep PacketInspection,深度包检测)等。并且,随着5G时代的来临,物联网、车联网的发展,大量终端接入,网络流量、接入连接数、用户流呈指数增加,终端安装了很多APP(Application,应用程序),APP会定时或不定时发起上网请求,一般来说,一部中度使用的手机,每5分钟发起建流的请求就达上百条,这给传统基于流表做负载分发的网络设备带来了巨大的压力。
通常,基于流表进行负载均衡的网络设备在接收到一个带分发的数据包时,就会从该数据包的IP头获取Key(键值),然后基于获取到的Key查询流表中是否已经存在该数据包对应的流,若存在,则直接基于该流确定处理该数据包的RS(real server,真实服务器,也即业务处理节点),然后将该数据包传输给对应的RS;若不存在,则网络设备需要在流表中建立该数据包对应的流,确定该数据包对应的RS并将该数据包传输给对应的RS。由于通信网络中有海量的流量,因此流表中管理的流自然也繁多,这就会直接导致网络设备在查询流表中是否存在数据包对应的流时效率低下,影响流表性能。
发明内容
本发明实施例提供的数据流管理方法、网络设备及存储介质,主要解决的技术问题是网络流量大所造成的流表大,查询效率低,性能低下的问题。
为解决上述技术问题,本发明实施例提供一种数据流管理方法,包括:
从数据包接收队列中获取当前待处理的目标数据包;
按照热度等级从高至低的顺序在各管理区中查询目标数据包对应的数据流;管理区的总数大于等于2,且一个管理区唯一对应一个热度等级;一个数据流的流量活跃程度与其所属热度等级呈正相关关系。
本发明实施例还提供一种网络设备,该网络设备包括处理器、存储器及通信总线;
通信总线用于实现处理器和存储器之间的连接通信;
处理器用于执行存储器中存储的一个或者多个程序,以实现上述数据流管理方法的步骤。
本发明实施例还提供一种存储介质,该存储介质存储有一个或者多个程序,一个或者多个程序可被一个或者多个处理器执行,以实现上述数据流管理方法的步骤。
本发明的有益效果是:
根据本发明实施例提供的数据流管理方法、网络设备及存储介质,网络设备对数据流进行“分区管理”,按照不同的热度等级设置至少两个管理区,每个管理区唯一对应一个热度等级。对于任意一个数据流,按照该数据流的流量活跃程度确定该数据流的热度等级,从而将该数据流划分到对应的管理区当中。通过这种管理方式,流量活跃程度越高的数据流,也即极有可能在后续过程中频繁接到对应数据包的数据流,将会位于热度等级越高的管理区中;流量活跃程度越低的数据流所属的管理区的热度等级自然也就越低。在从数据包接收队列中获取当前待处理的目标数据包后,网络设备按照热度等级从高至低的顺序在各管理区中查询该目标数据包对应的数据流。一个数据流的流量活跃程度高意味着网络设备接收到该数据流的数据包的概率也比较高,反过来,网络设备所接收到的数据包也有极大的可能是属于流量活跃程度高的数据流的,因此,当获取到目标数据包之后,网络设备极有可能在热度等级较高的管理区中匹配出该目标数据包对应的数据流,这样,对于剩余热度等级低的管理区中的数据流,网络设备就不需要继续查询。故,网络设备按照热度等级从高至低的顺序在各管理区中查询,能够在很大程度上减少查询负担,提升查询效率,提升管理性能。
本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明,且应当理解,至少部分有益效果从本发明说明书中的记载变的显而易见。
附图说明
图1为本发明实施例一中提供的数据流管理方法的一种流程图;
图2为本发明实施例一中示出的核心网中虚拟负载均衡器的一种部署示意图;
图3为相关技术中负载均衡设备对获取到的目标数据包的一种处理流程图;
图4为本发明实施例一中提供的网络设备对各管理区中数据流进行老化管理的一种流程图;
图5为本发明实施例二中示出的虚拟负载均衡器的整体架构示意图;
图6为本发明实施例二中示出的HWC数据流管理方案的一种算法原理示意图;
图7为相关技术中进行数据流管理的一种原理示意图;
图8为本发明实施例三中示出的网络设备的一种硬件结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
实施例一:
为了解决相关技术中因为流表大而导致流表性能下降,网络设备查询效率低下的问题,本实施例提供一种数据流管理方法,请参见图1示出的流程图:
S102:网络设备从数据包接收队列中获取当前待处理的目标数据包。
在本实施例中,网络设备是指需要对数据流进行管理的设备,例如,位于流量入口和多个业务处理节点之间的,需要利用流表或连接表等管理表进行负载均衡管理的负载均衡(LB,Load Balance)设备,在本实施例的一些示例当中,网络设备可以是部署有vLB(virtual Load Balancer,虚拟负载均衡器)的网络设备。例如,在图2当中示出了核心网中vLB 21的部署示意图,vLB 21位于xGW(extensible Gateway,增强型集群网关)22之后,vFW(virtual Firewall,虚拟防火墙)23到ISP(Internet Service Provider),互联网服务提供商)之前。在xGW 22与vLB 21之间可以设置vR(virtual Router,虚拟路由器),可选地,在vLB之后可以部署业务链、VO、TCPO加速器等。图2当中,箭头表示流量流向,黑色粗实线表示上行流量,黑色细实线则是下行流量。
由于通信网络中有海量的流量,因此,即便是在同一时刻,也可能会存在多个数据包等待网络设备进行处理,例如等待负载均衡设备为该数据包分配对应的RS。所以,在本实施例中,网络设备按照各数据包到达的时间顺序对各数据包进行处理,数据包达到网络设备后,进入数据包接收队列当中,网络设备按照先入先出的顺序从数据包接收队列中取出当前待处理的数据包,为了便于介绍,这里将网络设备当前待处理的数据包称为“目标数据包”。
S104:网络设备按照热度等级从高至低的顺序在各管理区中查询目标数据包对应的数据流。
由于本实施例中的网络设备主要是帮助其后的多个RS实现负载均衡,因此,网络设备在获取到目标数据包之后,主要就是要为该目标数据包确定出对应的目标RS,将目标RS的MAC(Media Access Control,媒体介入控制层)地址填写到目标数据包的目标MAC中,然后将该目标数据包按照目标MAC地址发送给目标RS。
考虑到目标数据包可能不是其所属数据流的第一个数据包,因此,网络设备在此之前可能已经创建过对应的数据流了。所以,在获取到目标数据包之后,网络设备先确定该目标数据包对应的数据流在本网络设备中是否已经存在。通常情况下,网络设备采用管理表来管理已经创建的数据流,例如通过连接表或者是流表管理数据流。管理表中基于“key-value”来管理数据包的数据流,其中,“value”中记录的是数据流对应的RS,而“key”的形式可以不只一种,在本实施例的一些示例当中,网络设备采用源IP、目的IP以及协议类型形成的三元组作为key。图3中示出了相关技术中负载均衡设备对获取到的目标数据包的一种处理流程,假定管理表为流表:
S302:接收目标数据包;
S304:采用目标数据包对应的三元组在哈希表中进行查找;
S306:判断该目标数据包所对应的数据流是否已经存在。
若判断结果为是,则进入S308;否则进入S312。
S308:按照数据流对应的MAC修改目标数据包的目的MAC;
S310:将经修改处理后的目标数据包加入数据包发送队列进行发送;
S312:基于哈希算法确定目标数据包对应的目标RS;
S314:判断流表中是否存在老化的数据流;
若判断结果为是,则进入S316,否则进入S320。
S316:重用老化的数据流;
S318:更新数据流的状态;
随后,负载均衡设备同样执行S308,修改目标数据包的目的MAC后对目标数据包进行发送。
S320:是否可以流表中分配存储空间;
若判断结果为是,则进入S322,否则进入S324。
S322:在流表中创建目标数据包对应的数据流。
在流表中创建对应的数据表之后,负载均衡设备执行S308,修改目标数据包的目的MAC后对目标数据包进行发送。
S324:丢弃目标数据包。
在本实施例中,网络设备获取到目标数据包之后,同样可以从目标数据包的IP头(IP header)中提取出三元组,然后根据三元组,哈希查找目标数据包对应的数据流。当然,本领域技术人员可以理解的是,在本实施例的其他一些示例当中,key也可以是其他形式,也即并不一定是源IP、目的IP以及协议类型组成的三元组。
不过,和相关技术中不同的是:相关技术中负载均衡设备对应所有的数据流进行管理时,所有数据流混杂在一起,在查询目标数据包对应数据流的过程中,查询负担大,效率低。而本实施例中,网络设备划分至少两个管理区来对数据流进行管理,一个管理区唯一对应一个热度等级。管理区可以基于连接表或流表来对划分到该管理区中的数据流进行管理。在为一个数据流划分所属管理区的时候,主要考虑该数据流的流量活跃程度,流量活跃程度越高,则该数据流所属的管理区的热度等级应当越高,反之,数据流的流量活跃程度越低,则对应的管理区的热度等级自然也越低。
在本实施例的一些示例当中,数据流的流量活跃程度可以通过数据流的收包频率和流量大小中的至少一个来表征,应当理解的是,一个数据流的收包频率越高,则该数据流的流量活跃程度也越高,也即数据流的流量活跃程度与该数据流的收包频率呈正相关关系。数据流的流量大小同样与流量活跃程度呈正相关关系,流量越大,则数据流越活跃。虽然一个数据流的收包频率以及流量大小指的是该数据流在过去的收包频率以及流量大小,但其可以表征该数据流的活跃程度,也就可以体现网络设备在未来接收到该数据流的数据包的概率大小。所以,通过对数据流划分到热度等级不同的管理区中进行管理,可以使得那些流量活跃程度高的数据流处于热度等级高的管理区中,也即使得那些在后续过程中极有可能较为频繁地接收到数据包的数据流处于热度等级较高的管理区中,使得那些短流、瞬时流等处于热度等级相对较低的管理区中。
对于网络设备而言,其接收到一个数据包,该数据包有极大可能是已经创建的某个数据流的数据包,基于实践经验,90%的数据包所属的数据流都属于热度等级较高的管理区。因此,当获取到目标数据包后,网络设备按照热度等级从高到低的顺序来查询各管理区中的数据流,可以使得查询过程更有针对性,有利于提升查询过程的效率,降低查询负担。
如果经过查询,网络设备从某一个管理区中查询到了目标数据包对应的数据流,则网络设备的处理方式和相关技术中类似:即按照查询到的数据流对应的MAC地址修改目标数据包的MAC地址,然后将经过修改处理的目标数据包送到数据包发送队列中,让数据包发送队列按照目标数据包的目的MAC地址将该目标数据包传输给对应的目标RS。
如果经过查询,所有管理区中均不存在该目标数据包对应的数据流,则说明该数据包是其所属数据流的第一个数据包,因此,网络设备需要为该数据包新建一个数据流:
在本实施例的一些示例当中,网络设备为目标数据包创建数据流之后,可以按照该数据流当前的流量活跃程度且划分一个管理区,由于新建的数据流当前仅接收到一个数据包,所以,网络设备可以基于该,目标数据包的流量大小为该数据包确定一个管理区。应当理解的是,由于该数据流当前尚只有一个数据包,因此,该数据六的流量活跃程度并不会太高,其所属的管理区的热度等级也不会太高。
在本实施例的另外一些示例当中,因为网络设备仅接收到新建数据流的第一个数据包,因此,并不能准确确定其流量活跃程度,故,网络设备可以直接将该新建数据流划分到热度等级最低的管理区中。换言之,当网络设备确定所有管理区中均不存在与目标数据包对应的数据流时,可以直接在热度等级最低的管理区为该目标数据包新建数据流。
一般来说,一个千万级的流表占用空间40G左右,这对网络设备流表的资源占用具有极高的要求。在5G时代中,各种手机APP、物联网芯片制造了大量短流、瞬时流,根据某电信局点的数据统计,一个典型的移动网络的流表中:30%的数据流为瞬时流、60%的数据流为长间隔周期流,真正的长巨流不足3%。所以,虽然网络设备中数据流众多,管理表资源占用大,但这其中所管理的数据流很大一部分都属于流量活跃程度低、不会频繁收包或者后续不会继续收包的数据流,为了解决管理表空间占用过大、老化低效的问题,本实施例中提供一种解决方案,请参见图4:
S402:为各管理区配置大小与其热度等级呈正相关关系的老化检查周期。
每一个管理区都有与之对应的老化检查周期,所谓老化检查周期实际上就是对数据流进行老化检查的周期,老化检查周期越长,则意味着很久才会对数据流进行一次老化检查,对数据流老化检查的频率越低;老化周期越长,则意味着会比较频繁地对数据流进行老化检查。
在本实施例中,一个管理区的老化检查周期的大小与该管理区的热度等级呈正相关关系,也即管理区的热度等级越高,该管理区对应的老化检查周期越长,相反,一个管理区的热度等级越低,则该管理区对应的老化检查周期就越短。因此,对于热度等级高的管理区中的数据流,老化检查频率比较低,而对于热度等级较低的管理区中的数据流,则会较为频繁地检查该管理区中的数据流是否已经老化。
S404:对于任一管理区,按照管理区对应的老化检查周期对管理区中当前的数据流进行老化检查,确定出管理区中已经老化的数据流。
在本实施例的一些示例当中,各管理区的老化检查周期完全不同。但在本实施例的另外一些示例当中,热度等级相近的两个甚至多个管理区可以共用相同的老化检查周期,例如,假定网络设备分了9个热度等级的管理区,其可以为热度等级1~3的三个管理区配置同样的老化检查周期,为热度等级4~6的三个管理区配置同样的老化检查周期,而热度等级7~9的三个管理区则拥有另外一种老化检查周期。
这里继续以各管理区的老化检查周期互不相同进行说明:
假定网络设备设置了热度等级依次降低的热区、温区、冷区三个管理区,三者的老化检查周期依次为30min、10min以及1min,则网络设备会没30分钟对热区中各数据流进行一次老化检查,每10分钟对温区中的各数据流进行一次老化检查,每一分钟对冷区中各数据流进行一次老化检查。可以理解的是,网络设备通过老化检查可以确定各管理区中当前已经老化的数据流。
S406:将已经老化的数据流从管理区中删除。
为了避免这些已经老化的数据流继续存在与流表或连接表等管理表中,占用管理表的空间,造成管理表老化低效的问题,本实施例中网络设备确定出一个管理区中老化的数据流之后,可以直接将这些已经老化的数据流进行删除。
可以理解的是,因为热度等级高的管理区中所管理的数据流是在后续过程中极有可能继续收包的数据流,而热度等级低的管理区中所管理的绝大多数数据流则是短流、瞬时流等“垃圾流”,因此,按照管理区热度等级的高低来设置老化检查周期的大小,可以保证热度等级低的管理区中的大量垃圾流能够被及时清理掉,节约管理表的空间。同时,及时清理垃圾流能够有效减少各管理区中数据流的总数,在这种情况下,当网络设备获取到一个目标数据包之后,按照热度等级从高到低的顺序在各管理区中查询该目标数据包对应的数据流,即便是没能从热度等级高的管理区中查询到,而不得不与热度等级较低的管理区中的数据流进行匹配,但因为各管理区中数据流的总数减少,因此,即便是在这种情况下,也依旧可以在一定程度上提升网络设备进行管理表查询的效率。
在本实施例的一些示例当中,各个管理区中的数据流还可以随着数据流自身流量活跃程度的变更而发生所属管理区的变更,也即各管理区中的数据流可以“相互流动”:网络设备可以定期重新为各管理区中的数据流确定所属的管理区。在一些示例当中,网络设备可以为各管理区配置对应的重分区周期,然后按照各管理区对应的重分区周期来为该管理区中的数据流确定所属管理区。在本实施例的一些示例当中,管理区重分区周期的大小也同样与管理区的热度等级呈正相关关系,例如,在本实施例的一种示例当中,管理区的重分区周期与该管理区的老化检查周期大小相同。甚至在本实施例的部分示例当中,管理区的重分区周期与其老化检查周期重合,因此,网络设备会在对该管理区中的数据流进行老化检查的同时确定各数据流是否有管理区变动,如果有,则将变动的数据流迁移到新的管理区中。
继续以网络设备设置热区、温区和冷区三个管理区进行数据流管理为例进行说明:
对于冷区,由于其中包括大量的数据流,因此,对各数据流进行管理区变更判断的时候,所依据的指标就不会太多,否则会给网络设备造成较大的管理负担。考虑到冷区的老化检查周期比较短,所以,可以考虑让网络设备依据该管理区中数据流在该老化检查周期内的收包数目是否达到热度升级阈值来判断是否可以升迁到温区中。如果冷区中某一个数据流在老化检查周期内的收包数目达到热度升级阈值,则可以将该数据流重新划分到温区中。应当明白的是,在本实施例的其他一些示例当中,管理设备在对温区中数据流进行所属管理区评判的时候,可以考虑采用更多或者不同的指标来进行判断。
对于热区,因为热区中的数据流是收包非常频繁的数据流,数据流的访问频次比较高,也即数据流的流量活跃程度已经比较高了,因此对于网络设备而言,其更关注的是该区中数据流流量活跃程度的持久性。在本实施例的一些示例当中,网络设备可以根据热区中各数据流的收包总数以及收包总数的更新时间为各数据流重新确定所属的管理区。例如,如果有两个数据流的收包总数均为n,其中数据流a对应的收包总数更新时间为t1,而数据流b的收包总数更新时间为t2,其中,t2比t1距离当前时刻更近,因此,说明数据流b的流量活跃程度持久性比数据流a的更好。
对于温区,因为其中包含的数据流比较少,并且温区中数据流的访问频次相较于热区中的数据流而言也更舒缓,所以,网络设备在温区中数据流进行管理区变更判断的时候,可以考虑更多的评判指标,对各数据流进行更详细、更多维度的评判:在本实施例的一些示例当中,网络设备可以根据温区中各数据流的最近收包时间(即收到最近一个数据包的时间)、收包总数(即数据流的历史收包总数)以及最近连续n次收包的平均收包周期为各数据流重新确定所属的管理区。毫无疑义的是,在本实施例的其他一些示例当中,在对温区中数据流进行所属管理区评判的时候,可以考虑更少、更多或者不同的指标来进行判断。
本发明实施例提供的数据流管理方法,通过设置两个或者多个热度等级不同的管理区来对数据流进行管理,并在接收到目标数据包的时候按照热度等级从高到低的顺序在各管理区中查询目标数据包对应的数据流,能够在很大概率上缩短查询时间,减小查询负担,从而提升管理表的性能。
更进一步地,网络设备可以为不同的管理区设置不同的老化检查周期,热度等级越低的管理区的老化检查周期越短,这样可以及时清理掉热度等级低的管理区中的垃圾流,从而减少管理区中数据流的总数,从另一维度提升管理表性能,减少管理表对资源的占用。
同时,因为网络设备可以定期对各管理区中的数据流进行重新分区,从而可以使得各管理区中的数据流彼此流动,使得流量活跃程度高的数据流逐步从热度等级低的管理区中升迁到热度等级高的管理区中,保证该数据流的数据包到达时,能够迅速查找到数据包对应的数据流。同时也使得流量活跃程度低的数据流逐步从热度等级高的管理区降级到热度等级相对较低的管理区中,甚至被清理,避免占用热度等级高的管理区的资源,优化了资源配置。
实施例二:
为了使本领域技术人员对本发明实施例中提供的数据流管理方法的优点与细节更加清楚,本实施例将结合具体示例继续对该数据流管理方案进行阐述:在本实施例中,网络设备上部署有vLB,所以,网络设备实际上就是一个负载均衡设备LB,本实施例中负载均衡设备可以应用于链路层、IP层或网络层。
下面结合附图对vLB的整体架构进行说明,请参见图5示出的vLB的整体架构示意图:
UE 51与PGW(PDN GateWay,PDN网关)52通信,PGW 52与LB 53通信,LB 53之后设置有多个RS 54,RS 54之后可以设置FW 55以及ISP 56等。考虑到系统的容灾要求,当某个RS下线或者新加了某个RS之后,应当尽量减少受到影响的用户数。所以,在实施例的一些示例当中,可以结合一致性哈希原理设计健康检查机制:当RS出现变动时,老的数据流优先访问原来的RS,而对于新增或者下线的RS上的用户,则通过一致性哈希原理获取新分配的RS节点。如果RS下线出现在在多个相同业务的RS集群中,老的数据流对应的负载变化会被均衡到其余RS上,避免了对单个RS冲击过大的问题。
在本实施例中,LB 53当中包括第一NIC(Network Interface Controller,网络接口控制器)531、第二NIC 532以及n个数据包处理进程(packets processing)533,其中第一NIC531主要用于同PGW52通信,第二NIC 532用于实现同RS 54的通信。在第一NIC 531中,包括RSS与n个数据包接收队列(RX queue),每一个数据包接收队列对应一个数据包处理进程533;在第二NIC 532中,包括n个数据包发送队列(TX queue),每个数据包发送队列对应一个数据包处理进程533。
第一NIC531中的RSS可以将从PGW 52处接收到的数据包按照数据包的源IP分发到各个数据包接收队列中,RSS分发的原理是对数据包的源IP进行哈希,目的是将数据包均衡分发到不同数据包处理进程,同时让相同的UE的流分配到同一个数据包处理进程。
在本实施例的一些示例当中,vLB可以被部署在openstack(由美国国家航空航天局和RackSpace合作研发的为公有云及私有云提供软件的云计算或云存储平台)、tecs等资源池之上,vLB虚机通过虚拟SR-IOV(Single Root I/O Virtualization,单根I/O虚拟化)网卡,以DPDK(Data Plane Develop Kit,数据面开发套件)接管收包,对二层报文(帧)解报头。本实施例中的LB 53是基于二层链路层的负载器,尽管其需要三层的源IP地址作为哈希查询的key,但其工作的过程是通过在数据链路层修改数据帧的目的MAC地址来实现负载均衡的目的。因为数据链路层是OSI网络模型的第二层,而数据链路层负载均衡的方法走的是MAC层的协议,因此需要LB 53和后端服务器处在同一个二层(即同一个广播域)之中。
数据包处理进程533从与自身对应的数据包接收队列当中取出一个待处理的目标数据包之后,可以对目标数据包进行处理。在本实施例中,数据包处理进程533配置多个管理区来对数据流进行管理,一个管理区唯一对应一个热度等级。管理区可以基于连接表或流表来对划分到该管理区中的数据流进行管理。在为一个数据流划分所属管理区的时候,主要考虑该数据流的流量活跃程度,流量活跃程度越高,则该数据流所属的管理区的热度等级应当越高,反之,数据流的流量活跃程度越低,则对应的管理区的热度等级自然也越低。例如,在本实施例的一种示例当中,可以采用数据流的收包频率和流量大小来体现数据流的流量活跃程度,且收包频率和流量大小均与数据流的流量活跃程度呈正相关关系。在本实施例的一种示例当中,数据流的流量活跃程度仅与其收包频率有关,例如,在该示例当中,数据包处理进程533设置了热区(Hot)、温区(Warm)以及冷区(Cold)三个管理区来进行数据流管理,所以,该示例当中的数据流管理方案也称为HWC数据流管理方案。图6中示出了HWC数据流管理方案的一种算法原理示意图:
在图6当中,一个圆圈代表一个数据流,圆圈的大小与该数据流的收包周期(或者说查询周期)正相关,因此,一个数据流收包越频繁(也即被查询地越频繁),则其收包周期越长,圆圈越大。在图6当中,因为设置了热区61、温区62和冷区63三个管理区,所以,圆圈越小的数据流所在的管理区热度等级越高,相反,圆圈越大的数据流所在的管理区热度等级也越低。
数据包处理进程533可以从目标数据包中提取出key,然后基于提取的key按照热度等级从高到低的顺序在各管理区中进行查询,确定是否已经存在该目标数据包对应的数据流。
如果在某一个管理区中查询到与该目标数据包对应的数据流,则该目标数据包新的目的MAC也随之确定:数据包处理进程533可以根据查询到的数据流对应的目标RS的MAC地址修改目标数据包的目的MAC,然后将经修改处理后的是目标数据包传输到该数据包处理进程533对应的数据包发送队列当中。目标数据包在数据包发送队列当中等待发送,当发送顺序轮到该目标数据包后,第二NIC532可以按照该目标数据包的目的MAC将其发送给对应的RS 54。
如果查询完了所有的管理区,都没能查询到目标数据包对应的数据流,则数据包处理进程533可以根据负载均衡算法确定出目标数据包对应的目标RS,也即确定出该目标数据包对应的目的MAC,然后基于确定出的目标RS为该目标数据包创建对应的数据流。在本实施例当中,新建的数据流都属于热度等级最低的管理区。
由于HWC数据流管理方案中基于数据流的流量活跃程度对海量的数据流进行了分区管理,为查询过程中按热度等级逐渐降低的顺序对各管理区进行查询提供了基础,使得目标数据包到达后,只要该目标数据包对应的数据流已经存在,则数据包处理进程533就可以迅速完成查询。这相较于相关技术中对所有数据流进行无序管理的方案,如图7所示,能够显著提升数据流查询效率,优化管理性能。
在本实施例中,数据包处理进程533在对数据流进行管理的时候,可以根据实际情况采用流表或连接表进行管理,所以,数据包处理进程533对数据流进行分区管理,实际上也就是对流表或连接表进行分级管理。另外,数据包处理进程533不仅可以对数据流进行分区管理,而且,还可以为不同热度等级的管理区设置不同的老化检查周期,对各管理区中的数据流实现不同频率的老化检查。数据包处理进程533可以将热度等级越高的管理区的老化检查周期配置得越长,将热度等级越低的管理区的老化周期配置得越短。这样,可以使得热度等级低的管理区中大量的垃圾流可以及时被清理掉,从而减小整体管理表的资源占用,提升管理表性能。
在本实施例的一些示例当中,各个管理区中的数据流还可以“相互流动”:数据包处理进程533可以定期重新为各管理区中的数据流确定所属的管理区。在一些示例当中,数据包处理进程533可以为各管理区配置对应的重分区周期,然后按照各管理区对应的重分区周期来为该管理区中的数据流确定所属管理区。在本实施例的部分示例当中,管理区的重分区周期与其老化检查周期重合,因此,数据包处理进程533会在对该管理区中的数据流进行老化检查的同时确定各数据流是否有管理区变动,如果有,则将变动的数据流迁移到新的管理区中。
对于冷区,老化检查周期比较短,数据包处理进程533只需统计数据流在老化检查周期内的收包数目是否达到热度升级阈值,若是,则将对应的数据流重新划分到温区中。
对于温区,流表相对较小,收包更新次数较温和,对于该区,会终点区分辨别各数据流的流量活跃程度,所以数据包处理进程533采用了相对完善的KPI对各数据流进行考核,例如,数据包处理进程533根据数据流的最近收包时间、收包总数、最近n次收包的平均收包周期对数据流进行评估,对于评估优秀的数据流迁移到热区,将评估结果较差的数据流移到冷区。
对于热区,数据包处理进程533的关注点是数据流流量活跃程度的持久性,因为热区访问频度很高,并且老化检查周期设置得最长,所以数据包处理进程533需要尽量减少字段更新,可选地,数据包处理进程533可以只记录各数据流的收包总数和收包总数的更新时间,并在一个老化检查周期到达之后据此判断是否对数据包进行降级。
在本实施例中,负载均衡设备LB通过对数据流进行分区,收包后,可以优先在数据流较少的热区进查询匹配,最后查询数据流数目最大的垃圾冷区,在实践中,90%的数据包属于可以迅速完成查询的热区的数据流(也即首次匹配热区的流表就可以查到目的RS),而只有10%的数据包,需要完成整个查询。这可以在很大程度呈提升热区中数据流对应的数据包的查询效率。同时,即便是对于剩余10%的数据包,虽然对于这部分数据包,可能需要和所有管理区中的数据流进行匹配,也即对于这部分数据包而言,数据流的分区管理与无序管理没有差别,但因为LB及时清理了冷区中大量的垃圾流,减少了所有管理区中数据流的总量,因此还是可以节约查询时间。故,从整体上来说,本实施例提供的数据流管理方法可以提升流表或连接表的性能。
实施例三:
本实施例提供一种存储介质,该存储介质中可以存储有一个或多个可供一个或多个处理器读取、编译并执行的计算机程序,在本实施例中,该计算机可读存储介质可以存储有数据流管理程序,数据流管理程序可供一个或多个处理器执行实现前述实施例介绍的任意一种数据流管理方法的流程。
本实施例中还提供一种网络设备,如图8所示:网络设备80包括处理器81、存储器82以及用于连接处理器81与存储器82的通信总线83,其中存储器82可以为前述存储有数据流管理程序的存储介质。处理器81可以读取数据流管理程序,进行编译并执行实现前述实施例中介绍的数据流管理方法的流程:
在本实施例的一种示例当中,处理器81从数据包接收队列中获取当前待处理的目标数据包,然后,按照热度等级从高至低的顺序在各管理区中查询目标数据包对应的数据流;在本实施例中,管理区的总数大于等于2,且一个管理区唯一对应一个热度等级;一个数据流的流量活跃程度与其所属热度等级呈正相关关系。
在本实施例的一种示例当中,数据流的流量活跃程度同数据流的收包频率及流量大小中的至少一个呈正相关关系。
可选地,各管理通过管理表对所包含的数据流进行管理,管理表为流表或连接表中的任意一种。
在一种示例当中,处理器81按照热度等级从高至低的顺序在各管理区中查询目标数据包对应的数据流之后,若所有管理区中均不存在与目标数据包对应的数据流,则处理器81会为目标数据包新建数据流,并按照新建的数据流当前的流量活跃程度为其划分管理区;
在本实施例的另一种示例中,若所有管理区中均不存在与目标数据包对应的数据流,处理器81可以在热度等级最低的管理区为目标数据包新建数据流。
在本实施例的另外一些示例当中,处理器81可以为各管理区配置对应的老化检查周期,管理区的老化检查周期的大小与其热度等级呈正相关关系。对于任一管理区,处理器81按照管理区对应的老化检查周期对管理区中当前的数据流进行老化检查,确定出管理区中已经老化的数据流,然后将已经老化的数据流从管理区中删除。
在本实施例的部分示例当中,对于任一管理区,处理器81还可以按照管理区对应的老化检查周期定期重新为管理区中的数据流确定所属的管理区。
在一些示例中,管理区的总数为3,按照热度等级从高到低的顺序依次分为热区、温区及冷区。在重新为管理区中的数据流确定所属的管理区时:
对于冷区,处理器81判断冷区中各数据流在最近一个老化周期中的收包数目是否达到热度升级阈值,若是,则将对应的数据流重新划分到温区中;
对于温区,处理器81根据温区中各数据流的最近收包时间、收包总数以及最近连续n次收包的平均收包周期为各数据流重新确定所属的管理区。
对于热区,处理器81根据热区中各数据流的收包总数以及收包总数更新时间为各数据流重新确定所属的管理区。
本实施例提供的网络设备对数据流进行“分区管理”,按照不同的热度等级设置至少两个管理区,每个管理区唯一对应一个热度等级。对于任意一个数据流,按照该数据流的流量活跃程度确定该数据流的热度等级,从而将该数据流划分到对应的管理区当中。因此,当获取到目标数据包之后,网络设备基本可以在热度等级较高的管理区中匹配出该目标数据包对应的数据流,这样,对于剩余热度等级低的管理区中的数据流,网络设备就不需要继续查询。通过这种方式,能够在很大程度上减少查询负担,提升查询效率,提升管理性能。
显然,本领域的技术人员应该明白,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM,ROM,EEPROM、闪存或其他存储器技术、CD-ROM,数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。

Claims (12)

1.一种数据流管理方法,包括:
从数据包接收队列中获取当前待处理的目标数据包;
按照热度等级从高至低的顺序在各管理区中查询所述目标数据包对应的数据流;所述管理区的总数大于等于2,且一个管理区唯一对应一个热度等级;一个数据流的流量活跃程度与其所属热度等级呈正相关关系。
2.如权利要求1所述的数据流管理方法,其特征在于,数据流的流量活跃程度同所述数据流的收包频率及流量大小中的至少一个呈正相关关系。
3.如权利要求1所述的数据流管理方法,其特征在于,各所述管理通过管理表对所包含的数据流进行管理,所述管理表为流表或连接表中的任意一种。
4.如权利要求1所述的数据流管理方法,其特征在于,所述按照热度等级从高至低的顺序在各管理区中查询所述目标数据包对应的数据流之后,还包括:
若所有管理区中均不存在与所述目标数据包对应的数据流,则为所述目标数据包新建数据流,并按照新建的所述数据流当前的流量活跃程度为其划分管理区;
或,
若所有管理区中均不存在与所述目标数据包对应的数据流,则在热度等级最低的管理区为所述目标数据包新建数据流。
5.如权利要求1-4任一项所述的数据流管理方法,其特征在于,还包括:
为各所述管理区配置对应的老化检查周期,管理区的老化检查周期的大小与其热度等级呈正相关关系;
对于任一管理区,按照所述管理区对应的老化检查周期对所述管理区中当前的数据流进行老化检查,确定出所述管理区中已经老化的数据流;
将已经老化的数据流从所述管理区中删除。
6.如权利要求5所述的数据流管理方法,其特征在于,还包括:
对于任一管理区,按照所述管理区对应的老化检查周期定期重新为所述管理区中的数据流确定所属的管理区。
7.如权利要求6所述的数据流管理方法,其特征在于,管理区的总数为3,按照热度等级从高到低的顺序依次分为热区、温区及冷区。
8.如权利要求7所述的数据流管理方法,其特征在于,对于所述冷区,所述重新为所述管理区中的数据流确定所属的管理区包括:
判断所述冷区中各所述数据流在最近一个老化周期中的收包数目是否达到热度升级阈值,若是,则将对应的数据流重新划分到温区中。
9.如权利要求7所述的数据流管理方法,其特征在于,对于所述温区,所述重新为所述管理区中的数据流确定所属的管理区包括:
根据所述温区中各数据流的最近收包时间、收包总数以及最近连续n次收包的平均收包周期为各所述数据流重新确定所属的管理区。
10.如权利要求7所述的数据流管理方法,其特征在于,对于所述热区,所述重新为所述管理区中的数据流确定所属的管理区包括:
根据所述热区中各数据流的收包总数以及所述收包总数更新时间为各所述数据流重新确定所属的管理区。
11.一种网络设备,所述网络设备包括处理器、存储器及通信总线;
所述通信总线用于实现处理器和存储器之间的连接通信;
所述处理器用于执行存储器中存储的一个或者多个程序,以实现如权利要求1至10中任一项所述的数据流管理方法的步骤。
12.一种存储介质,其特征在于,所述存储介质存储有一个或者多个程序,所述一个或者多个程序可被一个或者多个处理器执行,以实现如权利要求1至10中任一项所述的数据流管理方法的步骤。
CN201911168077.9A 2019-11-25 2019-11-25 一种数据流管理方法、网络设备及存储介质 Withdrawn CN112838989A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911168077.9A CN112838989A (zh) 2019-11-25 2019-11-25 一种数据流管理方法、网络设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911168077.9A CN112838989A (zh) 2019-11-25 2019-11-25 一种数据流管理方法、网络设备及存储介质

Publications (1)

Publication Number Publication Date
CN112838989A true CN112838989A (zh) 2021-05-25

Family

ID=75922342

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911168077.9A Withdrawn CN112838989A (zh) 2019-11-25 2019-11-25 一种数据流管理方法、网络设备及存储介质

Country Status (1)

Country Link
CN (1) CN112838989A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113746893A (zh) * 2021-07-16 2021-12-03 苏州浪潮智能科技有限公司 一种基于fpga的智能网卡数据转发方法、系统及终端
CN115334136A (zh) * 2022-07-05 2022-11-11 北京天融信网络安全技术有限公司 一种连接老化控制方法、系统、设备及存储介质
CN117729189A (zh) * 2024-02-08 2024-03-19 睿云联(厦门)网络通讯技术有限公司 基于云端分布式活跃度的sip注册限流方法及设备介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105357146A (zh) * 2015-10-21 2016-02-24 北京交通大学 出口网关内缓存队列饱和攻击防御方法、装置及系统
CN105721300A (zh) * 2014-12-23 2016-06-29 英特尔公司 用于网络设备流查找管理的技术
CN107276916A (zh) * 2017-06-22 2017-10-20 中国科学技术大学 基于协议无感知转发技术的交换机流表管理方法
CN109347745A (zh) * 2018-09-20 2019-02-15 郑州云海信息技术有限公司 一种基于OpenFlow交换机的流表匹配方法和装置
CN110474845A (zh) * 2019-08-19 2019-11-19 广州西麦科技股份有限公司 流表项淘汰方法及相关装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721300A (zh) * 2014-12-23 2016-06-29 英特尔公司 用于网络设备流查找管理的技术
CN105357146A (zh) * 2015-10-21 2016-02-24 北京交通大学 出口网关内缓存队列饱和攻击防御方法、装置及系统
CN107276916A (zh) * 2017-06-22 2017-10-20 中国科学技术大学 基于协议无感知转发技术的交换机流表管理方法
CN109347745A (zh) * 2018-09-20 2019-02-15 郑州云海信息技术有限公司 一种基于OpenFlow交换机的流表匹配方法和装置
CN110474845A (zh) * 2019-08-19 2019-11-19 广州西麦科技股份有限公司 流表项淘汰方法及相关装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113746893A (zh) * 2021-07-16 2021-12-03 苏州浪潮智能科技有限公司 一种基于fpga的智能网卡数据转发方法、系统及终端
CN115334136A (zh) * 2022-07-05 2022-11-11 北京天融信网络安全技术有限公司 一种连接老化控制方法、系统、设备及存储介质
CN115334136B (zh) * 2022-07-05 2024-02-02 北京天融信网络安全技术有限公司 一种连接老化控制方法、系统、设备及存储介质
CN117729189A (zh) * 2024-02-08 2024-03-19 睿云联(厦门)网络通讯技术有限公司 基于云端分布式活跃度的sip注册限流方法及设备介质

Similar Documents

Publication Publication Date Title
CN111770028B (zh) 用于计算机网络的方法和网络设备
CN109802985B (zh) 数据传输方法、装置、设备及可读取存储介质
US10333835B2 (en) Packet transmission method, apparatus, and system
WO2020052605A1 (zh) 一种网络切片的选择方法及装置
WO2018152919A1 (zh) 一种路径选取方法及系统、网络加速节点及网络加速系统
WO2018000993A1 (zh) 一种分布式存储的方法和系统
US20150019740A1 (en) Network Bandwidth Allocation Method and Terminal
US9747090B2 (en) Application deployment method and scheduler
CN112838989A (zh) 一种数据流管理方法、网络设备及存储介质
US10708377B2 (en) Communication control device, communication control method, and non-transitory computer readable medium
CN107454017B (zh) 一种云数据中心网络中混合数据流协同调度方法
KR101773593B1 (ko) 멀티-에이전트 기반 코드 오프로딩을 수행하는 모바일 포그 컴퓨팅 시스템 및 그 방법
US10721295B2 (en) Popularity-based load-balancing for fog-cloud placement
WO2020042612A1 (zh) 消息存储、读取方法及装置、服务器、存储介质
WO2014094310A1 (zh) 资源调度的方法和装置
WO2020038450A1 (zh) 带宽调整方法、装置、通信设备及计算机可读存储介质
WO2021104284A1 (zh) 关于数据传输的表项建立方法及相关设备
CN111901236A (zh) 一种利用动态路由优化openstack云网络的方法及系统
WO2021197253A1 (zh) 业务报文传输方法及相关设备
CN109150760B (zh) 一种网络资源预留方法及装置
CN105656978A (zh) 一种资源共享方法及装置
EP3585013B1 (en) Data transmission method and apparatus
WO2021083196A1 (zh) 网络流量的迁移方法及装置
CN106851685B (zh) 一种控制移动终端带宽的方法及系统
CN111245740B (zh) 配置业务的服务质量策略方法、装置和计算设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WW01 Invention patent application withdrawn after publication
WW01 Invention patent application withdrawn after publication

Application publication date: 20210525