CN107231269B

CN107231269B - 一种集群精确限速方法和装置

Info

Publication number: CN107231269B
Application number: CN201610179863.9A
Authority: CN
Inventors: 姜邦杰; 祝顺民; 文荣; 孙成浩
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-03-25
Filing date: 2016-03-25
Publication date: 2020-04-07
Anticipated expiration: 2036-03-25
Also published as: TWI721103B; TW201737664A; WO2017162117A1; CN107231269A

Abstract

本申请实施例提供了一种集群精确限速方法和装置，涉及计算机技术领域。本申请的方法包括：接收数据包；判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则将所述数据包转发给负责应对所述数据包所属客户端的服务实体；如果所述数据包是由自身负责应对的客户端的数据包，则基于所述数据包的身份信息，对所述数据包进行限速处理。本申请不用单独在集群内设置一个流控实体对整个集群内的服务实体进行限速，不会因为该流控实体的故障而影响整个集群的正常工作，适用性强。而且仅仅是服务实体之间的数据包的简单转发，复杂度低。

Description

一种集群精确限速方法和装置

技术领域

本申请涉及计算机技术领域，特别是涉及一种集群精确限速方法和一种集群精确限速装置。

背景技术

随着网络的普及，网络的应用环境也越来越多样化，例如利用由一组协同工作的服务实体构成的集群对多客户端或者多用户提供服务。在此类应用环境中，为了防止某一客户端的流量过大而影响其它客户端或者基于某一客户端所购买的宽带流量的需求，需要针对每个客户端或者用户的流量进行限速。由于集群中包含多个服务实体，例如服务器等。每个服务实体都同时提供服务，进而会造成同一客户端的流量会落到集群的多个服务实体上。这样如果每个服务实体单独限速，那么随着集群规模的扩大，每个客户端总的限速带宽也在扩大，因此需要提供一种精确的针对集群的全局的限速方案。

为了实现达到针对集群的精确限速的目的，目前主要存在如下三类方案：

第一类：集群内使用专门的流控实体，例如流控服务器等，用于控制每台服务实体的限速。流控实体负责监控服务实体上的每个限速单元的流量速率，并动态分配限速带宽大小。

第二类：集群内每个服务实体平均分配客户端或者用户购买的带宽，假设集群有N台服务实体，用户购买带宽大小为B,那么每台服务实体的限速大小就是B/N。

第三类：在客户端和集群之间提供专门的由具有限速功能的装置构成的限速结点。

但是对于上述的三类方法，均存在不同的缺点：

对于第一类方案，首先需要在集群内提供一个流控实体来控制限速，该流控实体如果故障，会影响集群的正常工作，适用性不强。其次，由于流控实体需要监控服务实体的流量速率，因此其需要与服务实体进行大量的通信来决策给每个服务实体下发的限速大小，复杂度较高。

对于第二类方案，首先很难保证每个客户端的流量均匀落到每个服务实体上，可操作性较低。其次如果客户端的流量不均匀，那么就会存在部分服务实体上针对某些客户端的流量大于具体的限速值，从而丢包，造成用户的实际带宽达不到其购买的带宽大小，精确性较低。

对于第三类方案，增加专门的限速结点，增加成本，对于小型集群不适用。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种集群精确限速方法和相应的一种集群精确限速装置。

为了解决上述问题，本申请公开了一种集群精确限速方法，包括：

接收数据包；

判断所述数据包是否为由自身负责应对的客户端的数据包；

如果所述数据包不是由自身负责应对的客户端的数据包，则将所述数据包转发给负责应对所述数据包所属客户端的服务实体；

如果所述数据包是由自身负责应对的客户端的数据包，则基于所述数据包的身份信息，对所述数据包进行限速处理。

优选地，所述将所述数据包转发给负责应对所述数据包所属客户端的服务实体的步骤，包括：

基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部；

将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

优选地，基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部的步骤，包括：

基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头，或者基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

优选地，所述基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头，或者基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头的步骤，包括：

获取所述数据包对应的身份信息；

根据所述身份信息，选择同一个五元组；所述五元组包括：源IP地址，目的IP地址，源端口,目的端口,传输协议类型；所述目的IP地址为服务实体对应的IP地址；

基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头；或者，

基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

优选地，当所述身份信息为IP地址时，所述获取所述数据包对应的身份信息的步骤包括：

在网络层解析所述数据包的IP报文头，以获取IP地址。

优选地，当所述身份信息为用户ID时，所述获取所述数据包对应的身份信息的步骤包括：

将所述数据包暂存在网络层，同时将所述数据包向上发送至应用层；

在应用层解析所述数据包的数据区，以获取所述数据包的用户ID。

优选地，所述根据所述身份信息，选择同一个五元组的步骤，包括：

在应用层根据所述身份信息，选择同一个五元组；

则在根据所述身份信息，选择同一个五元组的步骤之后，还包括：

将在应用层获得的五元组发送至网络层。

优选地，所述基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头的步骤，包括：

将所述五元组中的源端口、目的端口封装到所述数据包之外的UDP报文头中；

将所述五元组中的源IP地址、目的IP地址和传输协议类型封装到所述数据包之外的IP报文头中。

优选地，所述基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头的步骤，包括：

将所述五元组中的源端口、目的端口封装到所述数据包之外的TCP报文头中；

优选地，所述判断所述数据包是否为由自身负责应对的客户端的数据包的步骤，包括：

判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包；

如果所述数据包是由服务实体转发的数据包，则确认所述数据包是自身负责应对的客户端的数据包；

如果所述数据包是由客户端发送的数据包，则确认所述数据包不是由自身负责应对的客户端的数据包。

优选地，上述判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包的步骤，包括：

针对任一数据包，判断在所述数据包之外是否存在按照网络传输协议的规则封装的协议头部；

如果在所述数据包之外存在按照网络传输协议的规则封装的协议头部，则确认所述数据包是自身负责应对的客户端的数据包；

如果在所述数据包之外不存在按照网络传输协议的规则封装的协议头部，则确认所述数据包不是由自身负责应对的客户端的数据包。

优选地，所述基于所述数据包的身份信息，对所述数据包进行限速处理的步骤，包括：

解除所述数据包之外按照网络传输协议的规则封装的协议头部；

获取所述数据包的身份信息；

判断所述身份信息对应的流量是否超过到流量阈值；

如果所述身份信息对应的流量超过流量阈值，则丢弃所述数据包。

优选地，当所述身份信息为IP地址时，所述判断所述身份信息对应的流量是否达到阈值的步骤，包括：

查找所述IP地址对应的用户ID；

根据所述用户ID查找对应的流量阈值；

计算所述IP地址对应的流量是否超过所述流量阈值；

如果所述IP地址对应的流量超过所述流量阈值，则丢弃所述数据包。

相应地，本申请还公开了一种集群精确限速装置，包括：

接收模块，适于接收数据包；

判断模块，适于判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则进入转发模块；如果所述数据包是由自身负责应对的客户端的数据包，则进入限速模块；

转发模块，适于将所述数据包转发给负责应对所述数据包所属客户端的服务实体；

限速模块，适于基于所述数据包的身份信息，对所述数据包进行限速处理。

优选地，所述转发模块，包括：

封装子模块，适于基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部；

转发子模块，适于将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

优选地，所述封装子模块，包括：

第一封装子模块，适于基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头；

或者，第二封装子模块，适于基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

优选地，所述第一封装子模块，或者，第二封装子模块，包括：

身份信息获取子模块，适于获取所述数据包对应的身份信息；

五元组选择子模块，适于根据所述身份信息，选择同一个五元组；所述五元组包括：源IP地址，目的IP地址，源端口,目的端口,传输协议类型；所述目的IP地址为服务实体对应的IP地址；

第一报文头封装子模块，适于基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头；或者，第二报文头封装子模块，适于基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

优选地，其特征在于，当所述身份信息为IP地址时，所述身份信息获取子模块包括：

第一身份信息获取子模块，适于在网络层解析所述数据包的IP报文头，以获取IP地址。

优选地，当所述身份信息为用户ID时，所述身份信息获取子模块包括：

向上发送子模块，适于将所述数据包暂存在网络层，同时将所述数据包向上发送至应用层；

第二身份信息获取子模块，适于在应用层解析所述数据包的数据区，以获取所述数据包的用户ID。

优选地，所述五元组选择子模块，包括：

应用层五元组选择子模块，适于在应用层根据所述身份信息，选择同一个五元组；

则在五元组选择子模块之后，还包括：

发送子模块，适于将在应用层获得的五元组发送至网络层；

优选地，所述第一报文头封装子模块，包括：

第一端口封装子模块，适于将所述五元组中的源端口、目的端口封装到所述数据包之外的UDP报文头中；

IP地址封装子模块，适于将所述五元组中的源IP地址、目的IP地址和传输协议类型封装到所述数据包之外的IP报文头中。

优选地，所述第二报文头封装子模块，包括：

第二端口封装子模块，适于将所述五元组中的源端口、目的端口封装到所述数据包之外的TCP报文头中；

优选地，所述判断模块，包括：

判断子模块，适于判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包；如果所述数据包是由服务实体转发的数据包，则确认所述数据包是自身负责应对的客户端的数据包；如果所述数据包是由客户端发送的数据包，则确认所述数据包不是由自身负责应对的客户端的数据包。

优选地，所述判断子模块，包括：

协议头部判断子模块，适于针对任一数据包，判断在所述数据包之外是否存在按照网络传输协议的规则封装的协议头部；如果在所述数据包之外存在按照网络传输协议的规则封装的协议头部，则进入第一确认子模块；如果在所述数据包之外不存在按照网络传输协议的规则封装的协议头部，则进入第二确认子模块。

优选地，所述限速模块，包括：

解除子模块，适于解除所述数据包之外按照网络传输协议的规则封装的协议头部；

数据包身份信息获取子模块，适于获取所述数据包的身份信息；

流量判断子模块，适于判断所述身份信息对应的流量是否超过到流量阈值；如果所述身份信息对应的流量超过流量阈值，则进入丢弃子模块；

丢弃子模块，适于丢弃所述数据包。

优选地，当所述身份信息为IP地址时，所述流量判断子模块，包括：

用户ID查找子模块，适于查找所述IP地址对应的用户ID；

流量阈值查找子模块，适于根据所述用户ID查找对应的流量阈值；

第一流量判断子模块，适于计算所述IP地址对应的流量是否超过所述流量阈值；如果所述IP地址对应的流量超过所述流量阈值，则进入丢弃子模块。

本申请实施例包括以下优点：

本申请实施例，可以在不需要增加系统复杂度的情况下，通过将不是由自身负责应对的客户端的数据包，转发给同一集群中负责应对该数据包所属客户端的服务实体，从而保证同一客户端的流量落到同一台服务实体上，然后在该服务实体上，基于对应数据包的身份信息，对该客户端的数据包进行限速处理。首先，相对背景技术的第一类方案，本申请实施例不用单独在集群内设置一个流控实体对整个集群内的服务实体进行限速，不会应为该流控实体的故障而影响整个集群的正常工作，适用性强。而且，也不存在流控实体与服务实体之间大量的通信以决策给每个服务实体下发的限速大小，仅仅是服务实体之间的数据包的简单转发，复杂度低。

其次，相对背景技术的第二类方案，本申请实施例由于同一个客户端的数据包由同一个服务实体负责对其进行具体的业务逻辑处理，决定对其进行下一步处理还是丢弃，因此，可以精确控制每个客户端的流量，可操作性高。

再次，相对背景技术的第三类方案，本申请实施例在集群的原有架构下，对数据包的处理流程做了改进，将各个服务实体接收到的同一客户端的数据包，转发到了同一个服务实体进行限速处理，未增加系统复杂度，也没有采用额外的硬件设施，没有增加硬件成本。并且，本申请实施例仅利用集群自身的计算功能，即实现了对同一客户端的流量的限速处理，可以适用于任意规模的集群，适用性更广。

总之，相对于背景技术，本申请实施例在不增加系统复杂度以及成本的同时，提高了集群限速的适用性、可操作性，以及精确性。

附图说明

图1是本申请的一种集群精确限速方法实施例的步骤流程图；

图1A是本申请的一个应用场景示意图；

图2是本申请的另一种集群精确限速方法实施例的步骤流程图；

图3是本申请的另一种集群精确限速方法实施例的步骤流程图；

图4是本申请的一种集群精确限速装置实施例的结构框图；

图5是本申请的另一种集群精确限速装置实施例的结构框图；

图6是本申请的另一种集群精确限速装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，本申请提出的一种集群精确限速方法和装置，可以在不需要增加系统复杂度的情况下，通过将不是由自身负责应对的客户端的数据包，转发给同一集群中负责应对该数据包所属客户端的服务实体，从而保证同一客户端的流量落到同一台服务实体上，然后在该服务实体上，基于对应数据包的身份信息，对该客户端的数据包进行限速处理。从而相对于背景技术，在不增加系统复杂度以及成本的同时，提高了集群限速的适用性、可操作性，以及精确性。

实施例一

参照图1，示出了本申请的一种集群精确限速方法实施例的步骤流程图，具体可以包括如下步骤：

步骤110，接收数据包。

如图1A为本申请的一个应用场景示意图。可以看出，在集群内部存在4台服务实体，服务实体通过各个交换机与外部，例如客户端，进行通信，客户端发送的数据包先经过交换机，然后由交换机再分发到至少一台服务实体上来处理。

其中，集群是指一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。主要包括高可用集群(High Availability Cluster)，负载均衡集群(Load Balance Cluster)，科学计算集群(High Performance Computing Cluster)，本申请主要针对高可用集群和负载均衡集群。服务实体是可以提供某些服务的装置，例如服务器等，在本申请实施例中可以接收数据包并进行限速操作。

在互联网中，客户端与服务器交互，是先将其请求等信息以数据包的形式向服务器发送。而且在本申请中，由于集群中包含多个服务实体可以同时提供服务，进而造成同一客户端发送的数据包可能会落到集群中的多个服务实体上。

以现今的互联网为例，基本上采用的TCP/IP协议等互联网协议，那么TCP/IP协议的数据包(Data Packet)是TCP/IP(Transmission Control Protocol/InternetProtocol)协议通信传输中的数据单位，一般也称为“包”(Packet)，在网络信息传递过程中，单个消息被划分为多个数据块，这些数据块就称为数据包，它包含发送者和接收者的地址信息。这些数据包然后沿着不同的路径在一个或多个网络中传输，并且在目的地重新组合。在实际应用中，数据包主要由报文头和数据两部分组成。

在实际应用中，TCP/IP协议是一个协议族，其包括TCP((Transmission ControlProtocol，传输控制协议)、IP(Internet Protocol，网间网协议)、UDP(User DatagramProtocol，用户数据包协议)、ICMP(Internet Control Message Protocol，互联网控制信息协议)、RIP(Routing Information Protocol，路由信息协议)、SMTP(Simple MailTransfer Protocol，简单邮件传输协议)、SNMP(Simple Network manage Protocol，简单网络管理协议)、ARP(Address Resolution Protocol，地址解析协议)、FTP(File TransferProtocol，文件传输协议)等许多协议。TCP/IP协议采用分层结构，其分层模型及协议如下表(1)：

应用层(Application)	HTTP、Telnet、FTP、SMTP、SNMP
		传输层(Transport)	TCP、UDP
网络层(Internet)	IP【ARP、RARP、ICMP】
		链路层(Link)	Ethernet、X.25、SLIP、PPP

表(1)

不同的协议层对数据包有不同的称谓，在传输层叫做段(segment)，在网络层叫做数据报(datagram)，在链路层叫做帧(frame)。

本申请的一种集群精确限速方法，就是针对信息传输中的数据包进行限速，所以首先需要接收数据包。

步骤120，判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则进入步骤130；如果所述数据包是由自身负责应对的客户端的数据包，则进入步骤140。

在本申请实施例中，对于集群中各服务实体，可以由交换机根据一定算法确定集群中各服务实体自身负责应对的客户端，即集群中某一服务实体可以只对由该算法确定由自身负责应对的客户端发送的数据包进行限速，在本申请实施例中，此特定的客户端可以称为数据包自身负责应对的客户端。

所以，在接收到客户端的数据包后，需要进一步判断所述数据包是否为由自身负责应对的客户端的数据包，如果所述数据包不是由自身负责应对的客户端的数据包，考虑到服务实体只对由自己负责应对的客户端发送的数据包进行限速，所以此时需要将所述数据包转发至负责应对所述数据包所述客户端的服务实体；而如果所述数据包是由自身负责应对的客户端的数据包，则可以直接基于所述数据包的身份信息，对所述数据包进行限速处理。

步骤130，将所述数据包转发给负责应对所述数据包所属客户端的服务实体。

如图1A所示的场景图示例，服务实体接收到客户端发送的数据包后，可以经过交换机，将接收到的不是由自身负责应对的数据包转发给负责应对所述数据包所属客户端的服务实体。例如，服务实体1接收到一数据包，该数据包所属的客户端是由服务实体3负责应对的，则在服务实体接收到该数据包后，会将该数据包再次发送至交换机1，然后交换机1再将该数据包发送至服务实体3。

在本申请另一优选的实施例中，步骤130包括：

子步骤131，基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部。

在本申请实施例中，可以基于数据包的身份信息，在数据包之外封装协议头部，且该协议头部是按照网络传输协议的规则封装在数据包之外的。

其中，数据包的身份信息可以包括用户ID，和/或客户端的IP地址等；网络传输协议(Communications Protocol)一般是指网络层协议和传输层协议，例如，表(1)中所示的IP(Internet Protocol，网络协议)协议、TCP协议、UDP协议等。实际应用中，TCP协议和UDP协议同一个数据包只会使用一种。

其中TCP协议和UDP协议的区别主要为以下几点：

1、TCP协议需要存在通信关系的对象之间进行连接，UDP协议不需要存在通信关系的对象之间进行连接；

2、TCP协议的传输速度较慢，UDP协议的传输速度较快；

3、TCP协议可以保证数据顺序，UDP协议不可以保证数据顺序；

4、TCP协议可以保证数据正确性，UDP协议则可能丢包；

5、TCP协议对系统资源要求多，UDP协议系统资源要求少。

因此，可以理解，本申请在所述数据包之外再按照网络传输协议的规则封装协议头部，可以按照IP协议+TCP协议或者IP协议+UDP协议的规则封装协议头部。

在实际应用中，在本申请封装上述协议头部时，会在协议头部中封装指示数据包所属客户端的身份信息等第一数据。对同一客户端来说，在其任意数据包的协议头部中封装的上述第一数据是唯一的，可以跟其他客户端区别开来。

子步骤132，将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

在本申请实施例中，需要将同一客户端发送的数据包归并到预设的与该客户端对应的服务实体中，然后进行精确地限速，对于封装了协议头部的数据包，则可以根据协议头部的内容，利用交换机，将封装了协议头部的数据包转发给负责应对该数据包所属客户端的服务实体。

在实际应用中，可以利用交换机的HASH(哈希/散列)策略，将封装了协议头部的数据包准确地转发至负责对应该数据包所属客户端的服务实体。

在实际应用中，集群的交换机是对数据包的协议头部中的上述第一数据进行哈希，然后根据哈希结果，将数据包分发至相应的服务实体中。比如计算第一数据的哈希值，然后将该哈希值对服务实体的总个数取余数，然后根据余数与服务实体的对应关系，将该数据包发送至于该余数对应的服务实体中。

步骤140，基于所述数据包的身份信息，对所述数据包进行限速处理。

在实际应用中，集群需要对多个客户端提供服务，为了防止某一客户端的流量过大而影响其它客户端或者是导致该客户端的带宽收费较高等原因，需要针对每个客户端进行限速。在本申请实施例中，将各客户端的数据包全部归并到对该客户端对应的服务实体后，即可以利用一个服务实体实现对某客户端进行限速。

在实际应用中，可以首先根据不同的客户端预置不同的流量阈值，然后判断服务实体所对应接收的客户端的各数据包的流量是否超出该客户端对应的流量阈值的范围，若某一数据包的流量超出该客户端对应的流量阈值的范围，则可以将该数据包丢弃，而若数据包的流量未超出该客户端对应的流量阈值的范围，则保留该数据包。

在本申请实施例中，在不需要增加系统复杂度的情况下，通过将不是由自身负责应对的客户端的数据包，转发给同一集群中负责应对该数据包所属客户端的服务实体，从而保证同一客户端的流量落到同一台服务实体上，然后在该服务实体上，基于对应数据包的身份信息，对该客户端的数据包进行限速处理，因此本申请具备以下优点：

首先，相对背景技术的第一类方案，本申请实施例不用单独在集群内设置一个流控实体对整个集群内的服务实体进行限速，不会应为该流控实体的故障而影响整个集群的正常工作，适用性强。而且，也不存在流控实体与服务实体之间大量的通信以决策给每个服务实体下发的限速大小，仅仅是服务实体之间的数据包的简单转发，复杂度低。

总之，相对于背景技术的集群限速三类方案，在不增加系统复杂度以及成本的同时，提高了集群限速的适用性、可操作性，以及精确性。

实施例二

参照图2，示出了本申请的一种集群精确限速方法实施例的步骤流程图，具体可以包括如下步骤：

步骤210，接收数据包。

步骤220，判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则进入步骤230；如果所述数据包是由自身负责应对的客户端的数据包，则进入步骤250。

步骤230，基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

基于前述的TCP的优点，为了保证数据包在转发过程中数据的正确性，在本申请实施例中，可以基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。按照TCP协议封装一层TCP报文头，再按照IP协议封装一层IP报文头。

其中，TCP是面向连接的传输协议，需要在需要通信的客户端和服务实体之间以及不同的服务实体之间建立连接关系。TCP采用“三次握手”的方式建立连接，以客户端和服务实体为例，具体步骤如下：

第一次握手：建立连接时，客户端发送syn包(syn＝j)到服务实体，并进入SYN_SEND状态，等待服务实体确认；

第二次握手：服务实体收到syn包，必须确认客户的SYN(ack＝j+1)，同时自己也发送一个SYN包(syn＝k)，即SYN+ACK包，此时服务实体进入SYN_RECV状态；

第三次握手：客户端收到服务实体的SYN+ACK包，向服务实体发送确认包ACK(ack＝k+1)，此包发送完毕，客户端和服务实体进入ESTABLISHED状态，完成三次握手。

完成三次握手后，客户端与服务实体可以开始传送数据。

TCP报文头的数据格式如表(2)所示：

表(2)

其中，序列号：TCP序号，即本报文段所发送的数据的第一个字节的序号。

确认号：即希望下次收到对方传送的数据的第一个字节的序号。

数据偏移：指出TCP报文段的数据起始处距离TCP报文段的距离，实际就是TCP头部长度。注意，数据偏移的单位不是字节而是32bit，即4字节。TVP首部最大长度为(2^4-1)*4＝60字节。

保留：保留为今后使用，目前统一置为0.

代码位：

1、URG：紧急比特。当URG＝1时，表明紧急指针字段有效。该报文应尽快传送。而不要按原来的队列顺序来传送。

2、ACK：确认比特。当ACK＝1时确认号字段才有效，ACK＝0时，表明确认号无效。

3、PSH：推送比特：按对队传输到对方，不用待缓存填满后再提交给上层，而是立即提交。

4、RST：复位比特。TCP连接中出现严重差错，必须立即释放并重新建立连接。也用于拒绝一个非法的报文段或拒绝打开一个连接。

5、SYN：同步比特。在连接建立时用来同步序号。当SYN＝1而ACK＝0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使用SYN＝1和ACK＝1。因此，SYN＝1时，就表明这是一个连接请求或连接接受。

6、FIN：终止比特。用来释放一个连接。当FIN＝1时，表明数据发送完毕，要求释放连接。

窗口：接收端告知自己的接收能力，即自己接收窗口的大小，发送方将按这个大小发送数据。

校验和：检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。

紧急指针：当紧急指针代码位被设置时为有效字段。如果有效，这个值指明了当前序列号的八位组的偏移值，即第一个非紧急数据的起始位置。

在本申请另一优选的实施例中，步骤230，包括：

子步骤231，获取所述数据包对应的身份信息；

子步骤232，根据所述身份信息，选择同一个五元组；所述五元组包括：源IP地址，目的IP地址，源端口,目的端口,传输协议类型；所述目的IP地址为服务实体对应的IP地址；

子步骤233，基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

若要在数据包之外再封装一层IP报文头和TCP报文头，则此时五元组中的传输协议类型为TCP协议，即在数据包之外是按照TCP协议的规则再封装一层IP报文头和TCP报文头。根据表(2)和表(4)分别所示的IP报文头结构和TCP报文头结构可知，在实际应用中，五元组中的源IP地址、目的IP地址、传输协议类型分别与IP报文头中的源地址、目的地址、协议一一对应，五元组中的源端口、目的端口分别与TCP报文头中的源端口号、目的端口号一一对应。对于IP报文头和TCP报文头中其他部分的内容，本申请实施例也不加以限定。

在本申请另一优选的实施例中，步骤233，包括：

子步骤2331，将所述五元组中的源端口、目的端口封装到所述数据包之外的TCP报文头中。

具体而言，是将五元组中的源端口、目的端口分别封装到数据包之外的TCP报文头中的源端口号、目的端口号中。对于TCP报文头中的其他部分的数据内容，可以采用任意一种TCP报文头适用的数据，对此本申请实施例不加以限定。

子步骤2332，将所述五元组中的源IP地址、目的IP地址和传输协议类型封装到所述数据包之外的IP报文头中。

步骤240，将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

步骤250，基于所述数据包的身份信息，对所述数据包进行限速处理。

在本申请实施例中，同样在不需要增加系统复杂度的情况下，通过将不是由自身负责应对的客户端的数据包，转发给同一集群中负责应对该数据包所属客户端的服务实体，从而保证同一客户端的流量落到同一台服务实体上，然后在该服务实体上，基于对应数据包的身份信息，对该客户端的数据包进行限速处理。相对于现有的集群限速三类方案，在不增加系统复杂度以及成本的同时，提高了集群限速的适用性、可操作性，以及精确性。

另外，在本申请实施例中，通过在服务实体接收到的由客户端发送的数据包之外封装一层IP报文头和TCP报文头，然后再将封装后的数据包转发至负责应对该数据包所属的客户端的服务实体中，相对于UDP而言，本申请实施例需要在实体之间建立连接，可以进一步保证数据包中数据的准确性，将数据包准确地转发至相应地服务实体中，进一步提高了集群限速的精确性。

实施例三

参照图3，示出了本申请的另一种集群精确限速方法实施例的步骤流程图，具体可以包括如下步骤：

步骤310，接收数据包。

步骤320，判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包；如果所述数据包是由服务实体转发的数据包，则确认所述数据包不是由自身负责应对的客户端的数据包，然后进入步骤330；如果所述数据包是由客户端发送的数据包，则确认所述数据包是自身负责应对的客户端的数据包，然后进入步骤350。

由实施例一所述可知，在实际应用中，若服务实体接收到的数据包是由客户端的数据包，则会将该数据包转发至负责应对所述数据包所属客户端的服务实体，而且在转发之前，服务实体并不能确认其所接收的客户端发送的是数据包是否为自身负责应对的客户端发送的数据包。另外，一般而言，只需一次转发过程，即可以将该数据包转发至负责应对所述数据包所属客户端的服务实体。

在本申请实施例中，确认某一数据包不是由接收到该数据包的某服务实体自身应对的客户端的数据包，则表明该服务实体需要将接收到的该数据包进行转发操作，以将该数据包转发至负责应对该数据包所属的客户端的服务实体中。

在本申请实施例中，确认某一数据包是由某服务实体自身应对的客户端的数据包，则表明该服务实体不需要将该数据包进行再次转发操。

所以在本申请实施例中，若服务实体所接收的数据包是由服务实体转发的数据包，则可以确认该数据包是由自身负责应对的客户端的数据包；而若服务实体所接收的数据包是由客户端发送的数据包，则可以先默认该数据包不是由该服务实体自身负责应对的客户端的数据包。该步骤是实施例一中步骤120的优选方案。需要说明的是，在本申请实施例中，服务实体所接收到的数据包可能是由其自身转发的数据包。

例如，对于服务实体A，其接收到两个数据包分别为：数据包a、数据包b，其中数据包a是由服务实体B转发的，数据包b是由客户端C发送的。则经过上述步骤，可以直接确认数据包a是由服务实体A负责应对的客户端的数据包，数据包b则不是由服务实体A负责应对的客户端的数据包。而且，在服务实体A对数据包b进行转发之前，并不能确认数据包b所属的客户端C是否为服务实体A负责应对的客户端，另外，其中的服务实体A和服务实体B可能为同一服务实体。

在本申请另一优选的实施例中，步骤320，包括：

子步骤321，针对任一数据包，判断在所述数据包之外是否存在按照网络传输协议的规则封装的协议头部；如果在所述数据包之外存在按照网络传输协议的规则封装的协议头部，则确认所述数据包是自身负责应对的客户端的数据包，然后进入步骤350；如果在所述数据包之外不存在按照网络传输协议的规则封装的协议头部，则确认所述数据包不是由自身负责应对的客户端的数据包，然后进入步骤330。

根据实施例一所述的内容，在本申请实施例中，若服务实体要对所接收到的数据包进行转发，则需要先在该数据包之外再按照网络传输协议的规则封装协议头部；若服务实体不对所接收到的数据包进行转发，则不需要在该数据包之外再按照网络传输协议的规则封装协议头部。

所以，在本申请实施例中，针对服务实体接收到的任一数据包，判断在所述数据包之外是否存在按照网络传输协议的规则封装的协议头部。如果在所述数据包之外存在按照网络传输协议的规则封装的协议头部，则说明该服务实体接收到的该数据包是由服务实体转发的数据包，从而可以确认该数据包是由该服务实体自身负责应对的客户端的数据包；如果在数据包之外不存在按照网络传输协议的规则封装的协议头部，则说明该服务实体接收到的该数据包是由客户端发送的数据包，从而可以确认该数据包不是由自身负责应对的客户端的数据包。

步骤330，基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头。

如前述，若要对接收到的数据包进行转发，则需要先基于所述数据包的身份信息，在数据包之外按照网络传输协议的规则再封装协议头部。

其中，UDP是一种无连接的数据报服务。源服务实体在传送数据前不需要和目标服务实体建立连接。数据被冠以源、目标端口号等UDP报头字段后直接发往目的服务实体。这时，每个数据段的可靠性依靠上层协议来保证。在传送数据较少、较小的情况下，UDP比TCP更加高效。考虑到UDP协议不需要在通信的服务实体之间建立连接的特性，在本申请实施例中，基于数据包的身份信息，在数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头，从而可以避免在各服务实体之间建立连接的过程。在本申请实施例中，在数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头的过程并不会影响到数据包本身。

在实际应用中，IP报文头格式如表(3)所示：

表(3)

其中，版本(Version)字段：占4比特。用来表明IP协议实现的版本号，当前一般为IPv4，即0100。

报头长度(Internet Header Length，IHL)字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报(没有任何选项)，该字段的值是5，即160比特＝20字节。此字段最大值为60字节。

服务类型(Type of Service，TOS)字段：占8比特。其中前3比特为优先权子字段(Precedence，现已被忽略)。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。服务类型字段声明了数据报被网络系统传输时可以被怎样处理。例如：TELNET协议可能要求有最小的延迟，FTP协议(数据)可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP(Network News Transfer Protocol，网络新闻传输协议)可能要求最小费用，而ICMP协议可能无特殊要求(4比特全为0)。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF(Open Shortest Path First Protocol)、IS-IS(Intermediate System toIntermediate System Protocol)可以根据这些字段的值进行路由决策。

总长度字段：占16比特。指明整个数据报的长度(以字节为单位)。最大长度为65535字节。

标志字段：占16比特。用来唯一地标识主机发送的每一份数据报。通常每发一份报文，它的值会加1。

标志位字段：占3比特。标志一份数据报是否要求分段。

段偏移字段：占13比特。如果一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。

生存期(TTL：Time to Live)字段：占8比特。用来设置数据报最多可以经过的路由器数。由发送数据的源主机设置，通常为32、64、128等。每经过一个路由器，其值减1，直到0时该数据报被丢弃。

协议字段：占8比特。指明IP层所封装的上层协议类型，如ICMP(1)、IGMP(2)、TCP(6)、UDP(17)等。

头部校验和字段：占16比特。内容是根据IP头部计算得到的校验和码。计算方法是：对头部中每个16比特进行二进制反码求和。(和ICMP、IGMP、TCP、UDP不同，IP不对头部后的数据进行校验)。

源IP地址、目标IP地址字段：各占32比特。用来标明发送IP数据报文的源主机地址和接收IP报文的目标主机地址。

可选项字段：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项很少被使用，同时并不是所有主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，如果不足，必须填充0以达到此长度要求。

UDP报头文格式如表(4)所示：

表(4)

其中，源、目标端口号字段：占16比特。用来标识源端和目标端的应用进程。

长度：占16比特，标明UDP报头和UDP数据的长度。

校验和：占16比特，用来对UDP报头和UDP数据进行校验。

在本申请另一优选的实施例中，步骤330包括：

子步骤331，获取所述数据包对应的身份信息。

如步骤330所述，在对数据包进行封装之前，首先需要获取数据包对应的身份信息。一般而言，数据包对应的身份信息可以为IP地址，如发送该数据包的客户端的IP地址，也可以为用户ID，如发送该数据包的用户ID。当然，用户身份也可以为其他可用的信息，对此本申请实施例不加以限定。

在本申请另一优选的实施例中，当所述身份信息为IP地址时，子步骤351，包括：

子步骤3311，在网络层解析所述数据包的IP报文头，以获取IP地址。

如果要获取的身份信息为IP地址，例如发送该数据包的客户端的IP地址。如表(1)所示，在TCP/IP协议的网络层支持IP协议，所以，在本申请实施例中，在网络层解析数据包的IP报文头，从中获取所需的IP地址。数据包的IP报文头是数据包本身的IP报文头，与在数据包之外再封装的IP报文头不相关，但是数据包本身的IP报文头的结构也如表(3)所示，其中的源地址即为本申请实施例所要获取的IP地址。对于具体的解析过程，可以采用现有技术中的任何一种可用的解析方法，对此本申请实施例不加以限定。

在本申请另一优选的实施例中，当所述身份信息为用户ID时，子步骤331，包括：

子步骤3312，将所述数据包暂存在网络层，同时将所述数据包向上发送至应用层。

而如果要获取的身份信息为用户ID时，例如发送该数据包的用户ID，此时需要在应用层才可以获取到用户ID等信息，所以在本申请实施例中会将数据包暂存在网络层的内存中，同时将数据包向上发送至应用层。在本申请实施例中网路层的IP数据包上传至传输层，传输层解析TCP报文头或者UDP报文头后，将数据区的内容上传至应用层。应用层对数据区的内容进行解析。

子步骤3313，在应用层解析所述数据包的数据区，以获取所述数据包的用户ID。

在实际应用中，用户ID等信息被存放于数据包的数据区，将数据包发送至应用层后，则可以在应用层解析数据包的数据区，获取其中数据包的用户ID。同样对于具体的解析过程，可以采用现有技术中的任何一种可用的解析方法，对此本申请实施例也不加以限定。

子步骤332，根据所述身份信息，选择同一个五元组；所述五元组包括：源IP地址，目的IP地址，源端口，目的端口，传输协议类型；所述目的IP地址为服务实体对应的IP地址。

在实际应用中，五元组能够区分不同的通信，并且对应的通信是唯一的。所以在本申请实施例中，会根据身份信息，选择同一个五元组与该身份信息对应，则利用五元组，可以将不同的身份信息对应的用户终端完全区分开来。

在本申请实施例中，五元组包括的源IP地址是指用户端的IP地址，目的IP地址为服务实体对应的IP地址，源端口为用户终端发送数据包的端口，目的端口为服务实体接收数据包的端口，传输协议类型为发送数据包的具体的协议类型。

源端口可以采用客户端的端口的唯一标识ID，另外因为客户端的IP地址唯一，可以使用客户端IP地址的后2个字节作为源端口，当然也可以采用其他可利用的方式用以标识源端口，对此本申请实施例不加以限定。对于目的端口，使用固定的端口以唯一标记针对同一集群的数据包的目的端口。在本申请实施例中，传输协议类型和在数据包之外再封装的头部类型有关，例如，若传输协议类型为UDP协议，则在数据包外再封装一层IP报文头和UDP报文头；若传输协议类型为TCP协议，则在数据包外再封装一层IP报文头和TCP报文头。

需要说明的是，在本申请实施例中，所针对的是由一组协同工作的服务实体组成的集群，而且在实际应用中，集群服务实体对外提供的统一的服务地址，是虚拟IP地址，也称为集群VIP(Virtual IP，虚拟IP)地址，客户端通过访问集群VIP地址获取集群内部各服务实体的功能。所以上述的目的IP地址即为集群VIP地址，针对同一集群中的服务实体，五元组中的目的IP地址是一致的。

子步骤333，基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头。

若要在数据包之外再封装一层IP报文头和UDP报文头，则此时五元组中的传输协议类型为UDP协议，即在数据包之外是按照UDP协议的规则再封装一层IP报文头和UDP报文头。根据表(3)和表(4)分别所示的IP报文头结构和UDP报文头结构可知，在实际应用中，五元组中的源IP地址、目的IP地址、传输协议类型分别与IP报文头中的源地址、目的地址、协议一一对应，五元组中的源端口、目的端口分别与UDP报文头中的源端口号、目的端口号一一对应。对于IP报文头和UDP报文头中其他部分的内容，本申请实施例不加以限定。

在本申请另一优选的实施例中，步骤333包括：

子步骤A3331，将在应用层获得的五元组发送至网络层。

由于对数据包进行封装的操作需要在网络层进行，所以在本申请实施例中需要将在应用层获得的五元组发送至网络层。如前述，若是根据用户ID信息获取的五元组信息，则可以是在应用层获取的五元组，此时需要将在应用层获得的五元组发送至网络层，而若是根据IP地址获取的五元组，则可以是在网络层获取的五元组，此时不需要本步骤的发送过程。当然，不管是根据何种类型的用户信息获取的五元组，只要所获得的五元组不在网络层，都需要将获取的五元组发送至网络层。

子步骤A3332，在网络层基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头。

在本申请实施例中，具体而言，是由网络层基于五元组，在数据包之外按照UDP协议的规则再封装一层UDP报文头，再按照UDP协议封装一层IP报文头。

当然，对于本申请实施例也可以在，在网络层基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头,其原理基本类似。

在本申请另一优选的实施例中，步骤333包括：

子步骤B3331，将所述五元组中的源端口、目的端口封装到所述数据包之外的UDP报文头中。

具体而言，是将五元组中的源端口、目的端口分别封装到数据包之外的UDP报文头中的源端口号、目的端口号中。对于UDP报文头中的其他部分的数据内容，可以采用任意一种UDP报文头适用的数据，对此本申请实施例不加以限定。

子步骤B3332，将所述五元组中的源IP地址、目的IP地址和传输协议类型封装到所述数据包之外的IP报文头中。

具体而言，是将五元组中的源IP地址、目的IP地址、传输协议类型分别封装到数据包之外的IP报文头中的源端口号、目的端口号、协议中。对于IP报文头中的其他部分的数据，可以采用可任意一种IP报文头可适用的数据，对此本申请实施例也不加以限定。

在本申请的另一优选的实施例中，所述子步骤332包括：

子步骤3321，在应用层根据所述身份信息，选择同一个五元组。

在实际应用中，五元组所包含的信息存在于应用层中，所以可以在应用层根据所述身份信息，选择同一个五元组。

则在子步骤332之后，还包括：

子步骤334，将在应用层获得的五元组发送至网络层。

因为具体的根据五元组对数据包进行封装的过程在网络层执行，所以需要将在应用层获得的五元组发送至网络层。本步骤在子步骤353之前执行。

步骤340，将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

经过前述步骤可知，在本申请实施例中，针对同一客户端的数据包的五元组是一致的，另外，因为同一客户端的IP地址是唯一的，不同客户端的IP地址是不同的，所以针对不同客户端的数据包的五元组是不一致的。

在本申请实施例中，可以根据五元组，预先设定负责应对不同客户端的服务实体。在实际应用中，可以利用交换机的HASH策略保证将同一五元组的数据包发送到与该五元组对应的服务实体上。

步骤350，解除所述数据包之外按照网络传输协议的规则封装的协议头部。

在本申请实施例中，即解除数据包之外封装的IP报文头和UDP报文头，

当然，若是在数据包之外封装的协议头部为IP报文头和TCP报文头，则此时是解除数据包之外封装的协议头部为IP报文头和TCP报文头。

另外，在本申请实施例中，可以采用现有的任何一种解封装方法，解除数据包之外按照网络传输协议的规则封装的协议头部，对此本申请不加以限定。

步骤360，获取所述数据包的身份信息。

该步骤与前述的子步骤331类似，在此不再赘述。

步骤370，判断所述身份信息对应的流量是否超过到流量阈值；如果所述身份信息对应的流量超过流量阈值，则进入步骤380；而若所述身份信息对应的流量超过流量阈值，则保留该身份信息对应的数据包。

其中的流量阈值是可以根据实际情况预先设置，对此本申请实施例不加以限定。身份信息对应的流量是指该身份信息对应的数据包的流量，也即身份信息对应的客户端的数据包的流量。若身份信息对应的流量超过流量阈值，则将身份信息对应的数据包丢弃，若身份信息对应的流量未超过流量阈值，则保留身份信息对应的数据包。

例如，若用户A购买的带宽是50M/s，即流量阈值为50M/s。在用户A对应的终端设备收到当前数据包后，根据当前时刻到之前的1秒内收到的数据包记录，计算该用户A的流量速度是否大于50M/s，如果大于，则丢弃该数据包，如果不大于，则保留该数据包。

在本申请另一优选的实施例中，当所述身份信息为IP地址时，步骤370包括：

子步骤371，查找所述IP地址对应的用户ID。

在实际应用中，流量阈值一般是和用户ID对应的，所以在本申请实施例中，根据IP地址查找与之对应的用户ID。其中，IP地址与用户ID的对应关系是预置的，可以预先放置在一配置文件中，或者是通过其他方式存储，对此本申请实施例不加以限定。

子步骤372，根据所述用户ID查找对应的流量阈值。

用户ID与流量阈值的对应关系是预置的，可以预先存储于一配置文件中，或者是通过其他方式存储，对此本申请实施例不加以限定。

另外，在本申请实施例中，可以将用户与流量阈值的对应关系和上述的IP地址与用户ID的对应关系存储于同一配置文件中，也可以存储与不同的配置文件中，或者是利用不同的存储方式，对此本申请实施例也不加以限制。

子步骤373，计算所述IP地址对应的流量是否超过所述流量阈值；如果所述IP地址对应的流量超过所述流量阈值，则进入步骤3110。

此时，IP地址对应的流量是指IP地址对应的数据包的流量，也即IP地址对应的客户端的数据包的流量。

步骤380，丢弃所述数据包。

若数据包的流量超过对应的流量阈值，则会将该数据包从客户端的流量中删除，以保证客户端的网络速度在浏览阈值之内。

另外，在本申请实施例中，通过在服务实体接收到的由客户端发送的数据包之外封装一层IP报文头和UDP报文头，然后再将封装后的数据包转发至负责应对该数据包所属的客户端的服务实体中，从而可以在不需要建立连接的情况下，将数据包转发至相应地服务实体中，进一步提高了集群限速的适用性、可操作性以及精确性。而且对于封装了IP报文头和TCP报文头的数据包，则需要先在接收的服务实体以及转发的服务实体之间建立连接，才可以在其两者之间转发，所以相对于实施例二中在数据包外封装IP报文头和TCP报文头的方式，本申请实施例所述的在数据包之外封装IP报文头和UDP报文头的方式适应性、可操作性以及效率都更高。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

实施例四

参照图4，示出了本申请的一种集群精确限速装置实施例的结构框图，该集群包括至少一个交换机410和多个服务实体420，每个服务实体具体可以包括如下模块：

接收模块421，适于接收数据包。

判断模块422，适于判断所述数据包是否为由自身负责应对的客户端的数据包。如果所述数据包不是由自身负责应对的客户端的数据包，则进入转发模块423；如果所述数据包是由自身负责应对的客户端的数据包，则进入限速模块424。

转发模块423，适于将所述数据包转发给负责应对所述数据包所属客户端的服务实体。

在本申请另一优选的实施例中，所述转发模块，包括：

封装子模块，适于基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部。

限速模块424，适于基于所述数据包的身份信息，对所述数据包进行限速处理。

实施例五

参照图5，示出了本申请的一种集群精确限速装置实施例的结构框图，该集群包括至少一个交换机510和多个服务实体520，每个服务实体具体可以包括如下模块：

接收模块521，适于接收数据包。

判断模块522，适于判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则进入转发模块523；如果所述数据包是由自身负责应对的客户端的数据包，则进入限速模块524。

转发模块523，适于将所述数据包转发给负责应对所述数据包所属客户端的服务实体，具体包括：

封装子模块5231，适于基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部，具体包括：

第二封装子模块52311，适于基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

在本申请另一优选的实施例中，第二封装子模块52311，包括：

身份信息获取子模块，适于获取所述数据包对应的身份信息。

五元组选择子模块，适于根据所述身份信息，选择同一个五元组；所述五元组包括：源IP地址，目的IP地址，源端口,目的端口,传输协议类型；所述目的IP地址为服务实体对应的IP地址。

第二报文头封装子模块，适于基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头。

在本申请另一优选的实施例中，所述第二报文头封装子模块，包括：

第二端口封装子模块，适于将所述五元组中的源端口、目的端口封装到所述数据包之外的TCP报文头中。

转发子模块5232，适于将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

限速模块524，适于基于所述数据包的身份信息，对所述数据包进行限速处理。

实施例六

参照图6，示出了本申请的一种集群精确限速装置实施例的结构框图，该集群包括至少一个交换机610和多个服务实体620，每个服务实体具体可以包括如下模块：

接收模块621，适于接收数据包。

判断模块622，适于判断所述数据包是否为由自身负责应对的客户端的数据包；如果所述数据包不是由自身负责应对的客户端的数据包，则进入转发模块623；如果所述数据包是由自身负责应对的客户端的数据包，则进入限速模块624。具体包括：

判断子模块6221，适于判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包；如果所述数据包是由服务实体转发的数据包，则确认所述数据包是自身负责应对的客户端的数据包，然后进入限速模块624；如果所述数据包是由客户端发送的数据包，则确认所述数据包不是由自身负责应对的客户端的数据包，然后进入转发模块623。

在本申请另一优选的实施例中，判断子模块6221，包括：

协议头部判断子模块，适于针对任一数据包，判断在所述数据包之外是否存在按照网络传输协议的规则封装的协议头部；如果在所述数据包之外存在按照网络传输协议的规则封装的协议头部，则确认所述数据包是自身负责应对的客户端的数据包，然后进入限速模块624；如果在所述数据包之外不存在按照网络传输协议的规则封装的协议头部，则确认所述数据包不是由自身负责应对的客户端的数据包，然后进入转发模块623。

转发模块623，适于将所述数据包转发给负责应对所述数据包所属客户端的服务实体，具体包括：

封装子模块6231，适于基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部，具体包括：

第一封装子模块62311，适于基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头。

转发子模块6232，适于将封装了协议头部的数据包通过交换机转发给负责应对所述数据包所属客户端的服务实体。

在本申请另一优选的实施例中，第一封装子模块62311，包括：

在本申请另一优选的实施例中，当所述身份信息为IP地址时，所述身份信息获取子模块包括：

当所述身份信息为用户ID时，所述身份信息获取子模块包括：

向上发送子模块，适于将所述数据包暂存在网络层，同时将所述数据包向上发送至应用层。

第一报文头封装子模块，适于基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头。

在本申请另一个在本申请另一优选的实施例中实施例中，所述五元组选择子模块，包括：

应用层五元组选择子模块，适于在应用层根据所述身份信息，选择同一个五元组。

则在应用层五元组选择子模块之后，还包括：

发送子模块，适于将在应用层获得的五元组发送至网络层。

在本申请另一个在本申请另一优选的实施例中实施例中，所述第一报文头封装子模块，包括：

第一端口封装子模块，适于将所述五元组中的源端口、目的端口封装到所述数据包之外的UDP报文头中。

限速模块624，适于基于所述数据包的身份信息，对所述数据包进行限速处理。具体包括：

解除子模块6241，适于解除所述数据包之外按照网络传输协议的规则封装的协议头部。

数据包身份信息获取子模块6242，适于获取所述数据包的身份信息。

流量判断子模块6243，适于判断所述身份信息对应的流量是否超过到流量阈值；如果所述身份信息对应的流量超过流量阈值，则进入丢弃子模块6244。

在本申请另一优选的实施例中，当所述身份信息为IP地址时，所述流量判断子模块，包括：

用户ID查找子模块，适于查找所述IP地址对应的用户ID。

流量阈值查找子模块，适于根据所述用户ID查找对应的流量阈值。

第一流量判断子模块，适于计算所述IP地址对应的流量是否超过所述流量阈值。如果所述IP地址对应的流量超过所述流量阈值，则进入丢弃子模块6244。

丢弃子模块6244，适于丢弃所述数据包。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种集群精确限速方法和一种集群精确限速装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种集群精确限速方法，其特征在于，包括：

接收数据包；

判断所述数据包是否为由自身负责应对的客户端的数据包；

如果所述数据包是由自身负责应对的客户端的数据包，则基于所述数据包的身份信息，对所述数据包进行限速处理；

所述将所述数据包转发给负责应对所述数据包所属客户端的服务实体的步骤，包括：

基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部；其中，所述封装后的协议头部用于区分不同的客户端；

2.根据权利要求1所述的方法，其特征在于，基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部的步骤，包括：

3.根据权利要求2所述的方法，其特征在于，所述基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头，或者基于所述数据包的身份信息，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头的步骤，包括：

获取所述数据包对应的身份信息；

4.根据权利要求3所述的方法，其特征在于，

当所述身份信息为IP地址时，所述获取所述数据包对应的身份信息的步骤包括：

在网络层解析所述数据包的IP报文头，以获取IP地址。

5.根据权利要求3所述的方法，其特征在于，

当所述身份信息为用户ID时，所述获取所述数据包对应的身份信息的步骤包括：

6.根据权利要求5所述的方法，其特征在于，所述根据所述身份信息，选择同一个五元组的步骤，包括：

在应用层根据所述身份信息，选择同一个五元组；

将在应用层获得的五元组发送至网络层。

7.根据权利要求3所述的方法，其特征在于，所述基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和UDP报文头的步骤，包括：

8.根据权利要求3所述的方法，其特征在于，所述基于所述五元组，在所述数据包之外按照网络传输协议的规则再封装一层IP报文头和TCP报文头的步骤，包括：

9.根据权利要求1-7其中之一所述的方法，其特征在于，所述判断所述数据包是否为由自身负责应对的客户端的数据包的步骤，包括：

10.根据权利要求9所述的方法，其特征在于，上述判断所述数据包是由服务实体转发的数据包还是由客户端发送的数据包的步骤，包括：

11.根据权利要求1-7其中之一的方法，其特征在于，所述基于所述数据包的身份信息，对所述数据包进行限速处理的步骤，包括：

获取所述数据包的身份信息；

判断所述身份信息对应的流量是否超过到流量阈值；

12.根据权利要求11所述的方法，其特征在于，当所述身份信息为IP地址时，所述判断所述身份信息对应的流量是否达到阈值的步骤，包括：

查找所述IP地址对应的用户ID；

根据所述用户ID查找对应的流量阈值；

计算所述IP地址对应的流量是否超过所述流量阈值；

13.一种集群精确限速装置，其特征在于，包括：

接收模块，适于接收数据包；

限速模块，适于基于所述数据包的身份信息，对所述数据包进行限速处理；

所述转发模块，包括：

封装子模块，适于基于所述数据包的身份信息，在所述数据包之外再按照网络传输协议的规则封装协议头部；其中，所述封装后的协议头部用于区分不同的客户端；

14.根据权利要求13所述的装置，其特征在于，所述封装子模块，包括：

15.根据权利要求14所述的装置，其特征在于，所述第一封装子模块，或者，第二封装子模块，包括：

16.根据权利要求13所述的装置，其特征在于，

当所述身份信息为IP地址时，所述身份信息获取子模块包括：

17.根据权利要求13所述的装置，其特征在于，

18.根据权利要求17所述的装置，其特征在于，所述五元组选择子模块，包括：

则在五元组选择子模块之后，还包括：

发送子模块，适于将在应用层获得的五元组发送至网络层；

19.根据权利要求15所述的装置，其特征在于，所述第一报文头封装子模块，包括：

20.根据权利要求15所述的装置，其特征在于，所述第二报文头封装子模块，包括：

21.根据权利要求13-19其中之一所述的装置，其特征在于，所述判断模块，包括：

22.根据权利要求21所述的装置，其特征在于，所述判断子模块，包括：

23.根据权利要求13-19其中之一的装置，其特征在于，所述限速模块，包括：

丢弃子模块，适于丢弃所述数据包。

24.根据权利要求23所述的装置，其特征在于，当所述身份信息为IP地址时，所述流量判断子模块，包括：

用户ID查找子模块，适于查找所述IP地址对应的用户ID；