CN103107948A - 一种流量控制方法和装置 - Google Patents

Abstract

本申请提供了一种流量控制方法和装置，涉及网络技术领域。所述的方法包括：在应用服务器端拦截用户端的请求；根据所述请求获得用户信息组合；将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；其中，所述黑名单通过如下步骤生成：根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。本申请在解决因网络爬虫或者恶意攻击在短时间内产生巨量网络访问时，降低服务器***开销，更准确的对用户端的请求进行过滤，可降低对正常访问用户端错误过滤的情况；配置灵活，适用面广泛，可有效的提高***的过滤效率。

Description

一种流量控制方法和装置

技术领域

本申请涉及网络技术领域，特别是涉及一种流量控制方法和装置。

背景技术

随着计算机的广泛应用，对网络中的应用服务器访问也越来越多，越来越频繁，但在对应用服务器的访问中，可能会存在因为网络爬虫或者恶意攻击而产生的访问，此类访问容易使应用服务器的***资源被耗尽，并导致应用服务器不稳定。

现有技术中，通过在用户端的请求未到达应用服务器端时，对请求进行拦截，一般抓取分析该请求中的IP地址信息，确认该请求所属用户端，如果分析出同一IP地址对应的用户请求在短时间内访问频率过高，则对该IP地址对应的用户请求进行过滤。由于其在用户端的请求未到达应用服务器端时对请求进行拦截，并采用一种用户信息对请求进行过滤，导致过滤信息不全并且安全性不高，容易导致对用户端的请求的错误过滤。例如，如果以固定IP地址为过滤目标，当多个用户端共用一个IP地址时，只要其中一个用户使这个IP地址的请求满足过滤条件时，***将对这个IP地址进行过滤，这将导致此IP地址下的其他正常用户端访问也被错误过滤掉。同时，现有技术的单一性使其适用范围狭窄，不能适应现在过滤过程中越来越高，越来越灵活的要求；并且，在过滤时，对用户端的每个请求都会遍历整个过滤规则，给服务器带来大量的额外的开销，过滤效率低下。

发明内容

本申请提供一种流量控制方法和装置，通过灵活配置的流量过滤规则，解决因为网络爬虫或者恶意攻击导致的***不稳定，降低对用户端的错误过滤的情况，降低服务器***开销。

为了解决上述问题，本申请公开了一种流量控制方法，包括：

请求拦截步骤，在应用服务器端拦截用户端的请求；

用户信息获取步骤，根据所述请求获得用户信息组合；

黑名单过滤步骤，将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；

其中，所述黑名单通过如下步骤生成：

访问计数步骤，根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

黑名单生成步骤，针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

优选的，所述的用户信息包括cookie信息、和/或IP信息、和/或session信息、和/或应用请求参数信息。

优选的，所述的黑名单过滤步骤包括：

关键词匹配步骤，将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果匹配上，进入黑名单匹配步骤；

黑名单匹配步骤，将所述关键词组合对应的值组合与黑名单中的值组合进行匹配，如果匹配上，则进行过滤。

优选的，所述的黑名单匹配步骤包括：

第一黑名单匹配步骤，将所述值组合与应用服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则转入第二黑名单匹配步骤；

第二黑名单匹配步骤，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则进行过滤。

优选的，对于所述应用服务器端的缓存日志进行如下处理：

通过应用服务器端将所述缓存日志更新到流量控制中心服务器端的日志文件中。

优选的，对于所述日志文件进行如下操作：

通过流量控制中心服务器端扫描所述日志文件；

统计所述值组合的次数；

依据所述次数根据流量控制规则生成所述值组合的黑名单。

优选的，在用户信息获取步骤中包括：

步骤A1，抓取请求中包括的由应用服务器端分配给已登录用户端的session id；

步骤A2，依据所述session id，在应用服务器端中提取与session id对应session内容。

优选的，所述的过滤包括返回解锁页面给用户端。

优选的，当用户端进行解锁，则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

相应的，本申请还公开了一种流量控制装置，包括：

请求拦截模块，用于在应用服务器端拦截用户端的请求；

用户信息获取模块，用于根据所述请求获得用户信息组合；

黑名单过滤模块，用于将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；

其中，所述黑名单通过如下模块生成：

访问计数模块，用于根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

黑名单生成模块，用于针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

与现有技术相比，本申请包括以下优点：

首先，本申请通过在应用服务器端拦截用户端的请求，根据所述请求全面地获取各用户信息，并通过黑名单机制对用户端的请求进行过滤，在解决因网络爬虫或者恶意攻击在短时间内产生巨量网络访问的同时，降低服务器***开销，能更准确的对用户端的请求进行过滤，可以降低对正常访问用户端错误过滤的情况；依据用户信息的全面获取能力，能根据不同的实际情况调整过滤的用户信息组合，配置灵活，适用面广泛，特别是针对现在分布式***，可以有效的提高***的过滤效率。

附图说明

图1是本申请一种流量控制方法的实施例的流程示意图；

图2是本申请一种流量控制装置的结构示意图；

图3是本申请一种流量控制装置的优选的结构示意图。

具体实施方式

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

本申请通过在应用服务器端拦截用户端的请求，根据所述请求全面地获取各用户信息，并通过黑名单机制对用户端的请求进行过滤，在解决因网络爬虫或者恶意攻击在短时间内产生巨量网络访问的同时，降低服务器***开销，能更准确的对用户端的请求进行过滤，可以降低对正常访问用户端错误过滤的情况；依据用户信息的全面获取能力，能根据不同的实际情况调整过滤的用户信息组合，配置灵活，适用面广泛，特别是针对现在分布式***，可以有效的提高***的过滤效率。本申请还主要针对在应用服务器端进行注册的用户端进行的处理过程。

参照图1，其示出了本申请一种流量控制方法的实施例的流程示意图。

请求拦截步骤110，在应用服务器端拦截用户端的请求；

用户端可以通过网络将其请求发送到应用服务器端，然后由应用服务器根据请求返回相关信息。用户端发送的请求由应用服务器端设置的***进行拦截。

其中，在实际中，应用服务器端可以分布式***，即可以由多个分布式应用服务器组成，本申请可在每一个应用服务器内都可设置一个***，用来拦截到各个应用服务器的请求，所述应用服务器一般为web应用服务器。

用户信息获取步骤120，根据所述请求获取用户信息组合；

实际中用户端的请求可包括cookie信息、IP地址信息、session id、requestparameter(应用请求参数)等用户信息。依据用户端请求中的上述信息，在应用服务器端可获取包括cookie信息、和/或IP信息、和/或session信息、和/或应用请求参数信息(request parameter)等用户信息。

其中对于用户信息session，可以通过如下步骤获得：

步骤A1，抓取请求中包括的由应用服务器端分配给已登录用户端的session id。

步骤A2，依据所述session id，在应用服务器端中提取与session id对应session内容。

session机制是一种应用服务器端的机制，应用服务器使用一种类似于散列表的结构(包括散列表)来保存信息。但程序需要为某个用户端的请求创建一个session的时候，应用服务器首先检查这个用户端的请求里是否包含了一个session标识即session id，如果已经包含一个session id则说明应用服务器已经为此客户创建过session，应用服务器就按照session id把这个session提取出来进行处理。如果客户请求不包含session id，则由应用服务器为此客户创建一个session，并且生成一个与此session相关联的session id，这个session id将在本次响应中返回给用户端保存。而该应用服务器中的session是与外界隔离的，无法在该应用服务器以外提取该session信息。因此，对于用户信息session来说，需要依据用户端请求中的session id，在应用服务器端提取session。

在实际中cookie信息、session信息和request parameter信息中都包括了key(关键词)及对应的value(值)，比如cookie：“key＝id，value＝100156”，该cookie中的关键词为id，其值为100156，实际中该值可以为用户的在应用服务器端的注册id。对于session信息：“key＝id，value＝100123”，该session中的关键词为id，其值为100123，实际中该值也可为用户在服务器端注册的id；对于request parameter，其中的关键词key和value值对应各实际的应用。对于IP信息，其关键词为IP，其值为其具体的IP值比如201.1.1.109。本申请可以依据上述信息进行过滤。

黑名单过滤步骤130，将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤。

优选的，所述的黑名单过滤步骤包括：

关键词匹配步骤S1，将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果匹配上，进入黑名单匹配步骤；

比如所述流量控制规则配置如下：

1、请求的用户端IP地址为*.*.*.*和请求中session：id为xx的请求每分种不能超过30次。(其中IP代表关键词，*.*.*.*代表其值，其中id代表关键词，xx代表其值)

那么对于根据用户请求获得的用户信息组合为IP信息和session信息组合，其中IP信息的关键词为IP，值为202.1.1.109，session信息的关键词为id，其值为100186。

首先，将上述用户信息组合中对应的关键词组合IP和id与流量控制规则中配置的关键词IP和id进行匹配，显然可以匹配上，则转入步骤S2。

当用户请求的IP信息和session信息的关键词组合与流量控制规则中的关键词组合不匹配，比如用户的IP信息和session信息的关键词组合为IP和AB，则不对其进行过滤，由应用服务器返回业务逻辑，比如返回请求错误的业务逻辑。

实际中，步骤S1可在应用服务器端进行。

实际中，流量控制规则配置可如下：

1、请求中cookie：A为xx的请求每分种不能超过30次。(其中A代表关键词，xx代表其值)

2、请求中session：A为xx的请求每分种不能超过30次。(其中A代表关键词，xx代表其值)

3、请求request parameter：A为xx的请求每分种不能超过30次。(其中A代表关键词，xx代表其值)

4、请求的用户端IP地址为*.*.*.*的请求每分种不能超过30次。(其中IP代表关键词，*.*.*.*代表其值)

其中一个或者多个的组合。

黑名单匹配步骤S2，将所述关键词组合对应的值组合与黑名单中的值组合进行匹配，如果匹配上，则进行过滤。

在通过步骤S1的关键词匹配之后，对于匹配上的关键词组合对应的值组合，比如前述IP和id关键词组合对应的202.1.1.109和100186，与黑名单中的值组合进行匹配，如果匹配上，则进行过滤。如果没有匹配上，则继续记录以该值的组合进行计数。

其中，所述黑名单通过如下步骤生成：

访问计数步骤140，根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

在实际中是以流量控制规则中的用户信息组合进行访问次数的统计。更进一步的是针对用户信息组合的关键词组合对应的值的组合进行的访问次数的统计。比如前述的根据用户请求获得的用户信息组合为IP信息和session信息组合，其中IP信息的关键词为IP，值为202.1.1.109，session信息的关键词为id，其值为100186，就以202.1.1.109和100186为组合进行访问次数的统计。

其中，对于用户信息组合的访问次数可根据流量控制规则里配置的时间长度进行统计。比如前述每分钟不得超过30次，那么从第一次接收某个用户请求开始，比如在10:00时刻第一次接收到某个请求，对于该请求对应的用户信息组合的统计从10:00时刻开始，一直统计到10:01时刻结束，然后将针对该用户组合的统计清零，再重新开始统计，如此循环；或者，也可以按照时间点的统计次数之间的差额确认流量控制规则配置的时间段内，该用户信息组合的访问次数，比如10:00时刻为0次，10:01时刻为25次，10:02时刻为40次，10:03时刻为60次，那么第一个1分钟内访问次数就是25次，第二个1分钟内就是15次，第三个1分钟内就是20次。当然，还有其他方法统计流量控制规则配置时间段内的访问次数，本申请不对其加以限制。

黑名单生成步骤150，针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

比如前述控制规则：

1、请求的用户端IP地址为*.*.*.*和请求中session：id为xx的请求每分种不能超过30次。(其中IP代表关键词，*.*.*.*代表其值，其中id代表关键词，xx代表其值)

实际中，流量控制规则可以根据实际应用环境灵活调整，比如，如果为例提高安全性，***采用session机制，而不采用cookie机制，可以单独以session信息为用户信息设置流量控制规则，也可以session信息和IP信息的组合为用户信息组合设置流量控制规则；如果需要针对应用服务器的应用进行过滤，那么可以以用户请求中的应用请求参数(request parameter)信息作为用户信息设置流量控制规则，也可以应用请求参数信息和session信息为用户信息组合进行过滤；还可根据实际情况的要求以其他的用户信息组合设置流量控制规则，其中，具体时间间隔和次数也可根据实际要求进行设定，配置灵活，应用广泛。

进一步的，所述的黑名单匹配步骤包括：

第一黑名单匹配步骤S3，将所述值组合与应用服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则转入第二黑名单匹配步骤。

比如对于前述根据用户请求获得的用户信息组合为IP信息和session信息组合，其中IP信息的关键词为IP，值为202.1.1.109，session信息的关键词为id，其值为100186，就以202.1.1.109和100186为组合首先与应用服务器端的黑名单中的值的组合进行匹配，如果匹配上，则进行过滤，如果未匹配上，则当次该组合及对应请求存入应用服务器端的缓存日志中，并按该请求的要求返回处理结果。

对于应用服务器的缓存日志，优选的，通过应用服务器端将所述缓存日志更新到流量控制中心服务器端的日志文件中。

在实际应用中，用户端的请求的拦截在应用服务器端，请求的响应处理也在应用服务器端，规则的配置和黑名单的生成都在流量控制中心服务器端。

在实际中，应用服务器端将所述缓存日志以一定的时间间隔更新到流量控制中心服务器端的日志文件中，比如，每5秒更新一次。

进一步的，对于所述日志文件进行如下操作：

步骤m1，通过流量控制中心服务器端扫描所述日志文件；

步骤m2，统计所述值组合的次数；

步骤m3，依据所述次数根据流量控制规则生成所述值组合的黑名单。

对于流量控制中心服务器端的日志文件，流量控制中心服务器可实时依据该日志，根据流量控制规则生成黑名单。

在实际生成过程中，可以由流量控制中心服务器端的规则引擎扫描流量控制中心服务器的日志文件，通过tair(Key/Value结构数据存储***，默认支持基于内存和文件的两种存储方式)做访问计数器统计所述值组合的次数。然后由规则引擎依据流量控制规则里面的次数阈值生成黑名单。

第二黑名单匹配步骤S4，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则进行过滤。

此步骤的目的是对请求的值组合的进一步的核查，因为通过前述黑名单生成过程知道，应用服务器端的黑名单与流量控制中心服务器端的黑名单可能存在同步的延迟，此步骤可以增加过滤的精确度和有效性。

在此步骤中，如果未匹配上，说明应用服务器端的黑名单失效，比如，用户端根据要求进行解锁操作，则***(流量控制中心服务器端)会将解锁的用户端的请求相关用户信息组合从黑名单删除。那么，此时就需要将流量控制中心服务器端的黑名单再次更新到应用服务器端，使应用服务器端的黑名单保持准确。同时，对于该值组合，***会将其存入应用服务器端的缓存日志。

优选的，所述的过滤包括返回解锁页面给用户端。

优选的，当用户端进行解锁，则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

实际中，用户端的解锁处理在应用服务器中进行，当用户端的解锁请求发送到应用服务器端后，应用服务器端将对该请求的解锁信息发送到流量控制中心服务器端，流量控制中心服务器端则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到分布式***的各应用服务器端。

另外，所述的过滤也可为限制被过滤用户端在一定时间段内不能进行访问，本申请不对过滤方法加以限制。

参照图2，其是本申请一种流量控制装置的结构示意图。

请求拦截模块210，用于在应用服务器端拦截用户端的请求；

用户信息获取模块220，用于根据所述请求获得用户信息组合；

黑名单过滤模块230，用于将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；

其中，所述黑名单通过如下模块生成：

访问计数模块240，用于根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

黑名单生成模块250，用于针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

优选的，所述黑名单过滤模块包括：

关键词匹配模块，用于将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果匹配上，进入黑名单匹配步骤。

黑名单匹配模块，用于将所述关键词组合对应的值组合与黑名单中的值组合进行匹配，如果匹配上，则进行过滤。

进一步，优选的，所述的黑名单匹配模块包括：

第一黑名单匹配模块，将所述值组合与应用服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则转入第二黑名单匹配步骤；

第二黑名单匹配模块，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则进行过滤。

进一步的，优选的，所述的应用服务器端还包括：

缓存日志模块，用于存储每次未匹配上黑名单的用户信息组合对应的值组合。

解锁模块，用于解除解锁页面对用户端请求的锁定。

优选的，所述流量控制中心服务器端的访问计数模块以tair(Key/Value结构数据存储***，默认支持基于内存和文件的两种存储方式)做访问计数器统计所述值组合的访问次数。

所述流量控制中心服务器端的黑名单生成模块为规则引擎，用于配置规则，并针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

优选的，所述流量控制中心服务器端还包括解锁信息发送模块，用于当用户端进行解锁，则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

参照图3，其示出了本申请一种流量控制装置的优选的结构示意图。

本申请包括应用服务器端210和流量控制中心服务器端220；其中所述的应用服务器端可以为分布式应用服务器端。

所述的应用服务器端210包括：

请求拦截模块，用于在应用服务器端拦截所有用户端的请求。

用户信息获取模块，用于根据所述请求获得用户信息组合。

关键词匹配模块，用于将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果匹配上，进入黑名单匹配步骤。

第一黑名单匹配模块，将所述值组合与应用服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则转入第二黑名单匹配步骤。

缓存日志模块，用于存储每次未匹配上黑名单的用户信息组合对应的值组合。

解锁模块，用于解除解锁页面对用户端请求的锁定。

所述的流量控制中心服务器端220包括：

访问计数模块，根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数。

规则引擎，用于配置规则，并针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

第二黑名单匹配模块，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则进行过滤。

解锁信息发送模块，用于当用户端进行解锁，则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

本申请在应用服务器对用户端的请求进行拦截以前，流量控制中心服务器端将黑名单推送给应用服务器端；

应用服务器端的请求拦截模块对到达应用服务器的请求进行拦截；

应用服务器端的用户信息获取模块获取用户信息组合，所述的用户信息包括cookie信息、和/或IP信息、和/或session信息、和/或应用请求参数信息(request parameter)等；

应用服务器端的关键词匹配模块首先将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果未匹配，则返回业务逻辑；如果匹配上，进入第一黑名单匹配模块；

应用服务器端的第一黑名单匹配模块，根据被推送到应用服务器端的黑名单，对所述请求的用户信息组合的关键词组合对应的值组合与黑名单中值组合的进行匹配；如果未匹配上，则将该值组合存入应用服务器端的缓存日志模块，并返回业务逻辑；如果匹配上，则进入第二黑名单匹配模块；

流量控制中心服务器端的第二黑名单匹配模块，根据其当时的黑名单，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志模块，并返回业务逻辑，反之，则进行过滤，即返回解锁页面给用户端。

用户端根据要求发送解锁请求到应用服务器端后，应用服务器端将解锁消息发送给流量控制中心服务器端。

流量控制中心服务器端的解锁信息发送模块将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

其中，应用服务器端的缓存日志模块中的记录则定时更新到流量控制中心服务器端的日志文件中；流量控制中心的规则引擎扫描该日志文件，tair访问计数器统计对应用户请求的所述值组合的次数，然后由规则引擎依据所述次数，根据流量控制规则生成黑名单；流量控制中心再将该新的黑名单推送到各应用服务器端。

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

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

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

Claims (10)

1.一种流量控制方法，其特征在于，包括：

请求拦截步骤，在应用服务器端拦截用户端的请求；

用户信息获取步骤，根据所述请求获得用户信息组合；

黑名单过滤步骤，将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；

其中，所述黑名单通过如下步骤生成：

访问计数步骤，根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

黑名单生成步骤，针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

2.根据权利要求1所述的方法，其特征在于：

所述的用户信息包括cookie信息、和/或IP信息、和/或session信息、和/或应用请求参数信息。

3.根据权利要求1或2所述的方法，其特征在于，所述的黑名单过滤步骤包括：

关键词匹配步骤，将用户信息组合中对应的关键词组合与流量控制规则中的关键词组合进行匹配，如果匹配上，进入黑名单匹配步骤；

黑名单匹配步骤，将所述关键词组合对应的值组合与黑名单中的值组合进行匹配，如果匹配上，则进行过滤。

4.根据权利要求3所述的方法，其特征在于，所述的黑名单匹配步骤包括：

第一黑名单匹配步骤，将所述值组合与应用服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则转入第二黑名单匹配步骤；

第二黑名单匹配步骤，将所述值组合与流量控制中心服务器端的黑名单中的值组合进行匹配，如果未匹配上，则将流量控制服务器中心服务器端的黑名单更新到应用服务器端，将该值组合存入应用服务器端的缓存日志，并返回业务逻辑，反之，则进行过滤。

5.根据权利要求4所述的方法，其特征在于，对于所述应用服务器端的缓存日志进行如下处理：

通过应用服务器端将所述缓存日志更新到流量控制中心服务器端的日志文件中。

6.根据权利要求5所述的方法，其特征在于，对于所述日志文件进行如下操作：

通过流量控制中心服务器端扫描所述日志文件；

统计所述值组合的次数；

依据所述次数根据流量控制规则生成所述值组合的黑名单。

7.根据权利要求1所述的方法，其特征在于，在用户信息获取步骤中包括：

步骤A1，抓取请求中包括的由应用服务器端分配给已登录用户端的session id；

步骤A2，依据所述session id，在应用服务器端中提取与session id对应session内容。

8.根据权利要求1所述的方法，其特征在于：

所述的过滤包括返回解锁页面给用户端。

9.根据权利要求8所述的方法，其特征在于：

当用户端进行解锁，则将该用户端对应的请求的关键词值从黑名单删除，并将删除后的黑名单更新到各应用服务器端。

10.一种流量控制装置，其特征在于，包括：

请求拦截模块，用于在应用服务器端拦截用户端的请求；

用户信息获取模块，用于根据所述请求获得用户信息组合；

黑名单过滤模块，用于将所述用户信息组合，与黑名单中的用户信息组合进行匹配，如果匹配，则进行过滤；

其中，所述黑名单通过如下模块生成：

访问计数模块，用于根据所述请求对应用户信息组合的记录日志，统计所述用户请求对应的用户信息组合的访问次数；

黑名单生成模块，用于针对所述访问次数，依据流量控制规则生成所述用户信息组合的黑名单。

Images