CN114422272A

CN114422272A - 数据处理系统、方法及服务端设备

Info

Publication number: CN114422272A
Application number: CN202210311559.0A
Authority: CN
Inventors: 焦靖伟
Original assignee: Beijing Infosec Technologies Co Ltd
Current assignee: Beijing Infosec Technologies Co Ltd
Priority date: 2022-03-28
Filing date: 2022-03-28
Publication date: 2022-04-29
Anticipated expiration: 2042-03-28
Also published as: CN114422272B

Abstract

本申请实施例提供一种数据处理系统、方法及服务端设备。其中，系统包括：解析处理器，用于接收并解析客户端发送的请求消息；确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接；控制器，与所述解析处理器通信连接，用于通过与所述解析处理器的交互获取并汇总所述解析处理器运行过程中产生的所述数据信息；根据汇总后的所述数据信息，对所述解析处理器进行动态调控。采用本申请实施例提供的技术方案，可降低误关闭请求连接率、提升平均请求率。

Description

数据处理系统、方法及服务端设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理系统、方法及服务端设备。

背景技术

随着网络的高速发展，网络安全问题也日渐增多。拒绝服务（Denial of service，DoS）攻击是当前网络领域最常见的威胁之一，它通过各种不同手段，如消耗服务端的CPU、带宽等计算资源来迫使服务端无法提供正常服务。以往的DoS攻击主要是以单一报文的大流量攻击为主，近几年来已演变为慢速攻击。慢速攻击更具有隐蔽性，是对正常网络协议的变形，完全符合协议要求，因此对慢速攻击的防护更加困难。

HTTP慢连接攻击是一种针对Web服务端（也称HTTP服务端、网站服务端等）的DoS攻击，其根据慢速的不同阶段，分为慢速请求header（Slow Headers）、慢速提交body（Slowbody）和慢速读取（Slow read）三种形式。现有方案，多是针对Slow body形式的HTTP慢连接攻击的检测与防御，且主要采用事先设定好相关参数的静态方式实现，并无法动态调整参数，这存在请求处理效率低、具有较高的误关闭请求连接率等的问题。

发明内容

鉴于上述问题，本申请提供一种解决上述问题或至少部分地解决上述问题的数据处理系统、方法及服务端设备。

在本申请的一个实施例中，提供了一种数据处理系统。该系统包括：

解析处理器，用于接收并解析客户端发送的请求消息；确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接；

控制器，与所述解析处理器通信连接，用于通过与所述解析处理器的交互获取并汇总所述解析处理器运行过程中产生的所述数据信息；根据汇总后的所述数据信息，对所述解析处理器进行动态调控。

在本申请的另一实施例中，提供了一种数据处理方法。该方法适用于解析处理器，具体地，方法包括：

接收并解析客户端发送的请求消息；

确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；

在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接。

在本申请的又一实施例中，提供了一种数据处理方法。该方法适用于控制器，具体地，方法包括：

接收并汇总解析处理器发送的自身运行过程中产生的数据信息；

根据汇总后的数据信息，对所述解析处理器进行动态调控。

在本申请的又一个实施例中，提供了一种服务端设备。该服务端设备包括：存储器、解析处理器及控制器；其中，

所述存储器，用于存储一条或多条计算机指令；

所述解析处理器，与所述存储器耦合，用于执行所述一条或多条计算机指令，以用于实现上述相应数据处理方法中的步骤；

所述控制器，与所述存储器耦合及与所述解析处理器通信连接，用于执行所述一条或多条计算机指令，以用于实现上述相应数据处理方法中的步骤。

本申请实施例提供的技术方案中，由解析处理器来接收并解析客户端发送的请求消息，并在确定当前解析状态为解析请求消息中的请求头域时，监测解析请求头域对应的参数，且在参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前请求消息对应的连接。采用这种解析处理方式，能够有效降低误关闭请求连接率。此外，通过控制器来获取并汇总解析处理器运行过程中产生的数据信息，并根据汇总后的所述数据信息对解析处理器进行动态调整，可提高整体平均请求效率、降低攻击误报等。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要利用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为Slow Headers慢速攻击的原理示意图；

图2示出了本申请一实施例提供的数据处理系统的结构示意图；

图3示出了本申请一实施例提供的针对解析处理器确定相应调控决策的原理时序图；

图4示出了本申请另一实施例提供的针对解析处理器确定相应调控决策的原理时序图；

图5示出了本申请一实施例提供的数据处理方法的流程示意图；

图6示出了本申请另一实施例提供的数据处理方法的流程示意图；

图7示出了本申请一实施例提供的数据处理装置的结构示意图；

图8示出了本申请另一实施例提供的数据处理装置的结构示意图。

具体实施方式

Web服务端，也称HTTP服务端、www服务端、网站服务端等，它是互联网上重要的基础设施之一，主要功能是与客户端进行通信交互，为互联网用户提供各种信息服务。

目前，DoS攻击，尤其是慢速攻击类型的DoS攻击为互联网领域最常见的威胁之一。HTTP慢连接攻击为一种专针对Web服务端（以下简称服务端）的DoS攻击，其是客户端利用HTTP协议（HyperText Transfer Protocol，超文本传输协议）现有合法机制，先与服务端建立正常连接，指定一个较大的Content-Length（用于描述HTTP消息实体的传输长度），之后再以非常缓慢的速度向服务端发送请求或接收数据，比如每10秒发送一个字节，维护这个连接常时间不释放。此后，若客户端持续与服务端建立这样的连接，服务端的并发连接资源将会逐渐被耗尽，也就无法为正常客户端提供服务，于是就造成了拒绝服务。HTTP慢连接攻击根据实现手段分为缓慢发送请求和缓慢读取响应两大类，缓慢发送请求包含SlowHeaders（也称为Slowloris或者Slow HTTP GET）和Slow body（也称Slow Http Post）两种形式，缓慢读取响应包含Slow read形式。在针对HTTP慢连接攻击进行检测和防御时，现有方案多是针对Slow body形式的HTTP慢连接攻击的检测与防御，且主要采用事先设定好相关参数的静态方式实现，运行时并无法动态调整参数，这存在请求处理效率低、具有较高的误关闭连接等的问题。

为解决现有方案中存在的问题，本申请各实施例提供的数据处理方案，是针对Slow Headers形式的HTTP慢连接攻击（以下简称Slow Headers慢速攻击）的检测与防御，具体地：是利用所设置的精简化后的HTTP预解析处理器来检测相关的Slow Headers慢速攻击，以降低误判率，从而降低误关闭请求连接率。此外，还利用相应的预解析处理控制器对HTTP预解析处理器进行动态调控，比如调整攻击检测时间、选择是否加载（即是否开启或关闭）HTTP预解析处理器等，以此做到不停机防护，从而提高平均请求率，降低攻击误报率。为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。而本申请中术语“或/和”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如：A或/和B，表示可以单独存在A，同时存在A和B，单独存在B这三种情况；本申请中字符“/”，一般表示前后关联对象是一种“或”关系。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。此外，下述的各实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请各实施例提供的数据处理方案之前，先对本申请主要针对SlowHeaders慢速攻击进行介绍说明。

Slow Headers慢速攻击指的是客户端同服务端建立连接时，在HTTP头字段不发送代表请求结束的字符（即连续两个回车换行符（CRLF，也即\r\n），随后每隔一定时间（不大于服务端设置的连接断开时间timout）往服务端发送一个头格式的数据（如Key:Value \r\n格式）到服务端进行连接保活。因在HTTP协议规定中，客户端请求以连续的\r\n\r\n结尾表示请求头域结束，由于服务端只收到了一个\r\n，因此服务端将会一致等待请求头域中的结束符而不断开连接。当这种恶意请求连接将服务端连接池资源全部占用后，便导致服务端无法接收新的正常请求。

图1示出了Slow Headers慢速攻击的原理示意图。该图1中，客户端20通过GET方式向服务端10发送了一个请求消息，请求消息的第一行（即GET/HTTP1.1\r\n）是请求行，后面是请求头域内容，Host、User-Agent、Accept等表示不同类型的头部字段名，但是客户端20一直不发送表示请求头域结束的结束符，接下来客户端20间隔一段时间发生一个形如Key:Value \r\n表示请求头域格式的内容，以保持住连接。关于上述中GET方法的介绍，可参见下文或现有相关内容。

关于Slow body、Slow read等形式的HTTP慢连接攻击的具体介绍可参见现有内容，此处不作具体赘述。

这里需说明的是，为方便描述，在下文介绍本申请提供的数据处理方案时，将本申请所设置的精简化后的HTTP预解析处理器及预解析处理控制器，分别简称为解析处理器、控制器。

图2中示出了本申请一实施例提供的数据处理系统的结构示意图。该数据处理系统集成于服务端10，该服务端10为与客户端20通信交互的Web服务端。具体实施时，客户端20为任何能够为用户发起行为的工具，该工具常为浏览器等，当然在其他一些情况下，也可以是如工程师使用的程序、以及Web开发人员调试应用程序等，本实施例对此不作限定。Web服务端10可以为但不限于单独服务器、共享负载（负载均衡）的一组服务器组成的计算机集群、一种复杂软件等，在Web服务端为一种复杂软件的情况下，其通常向其它计算机（如缓存、数据库服务器、电子商务服务器等）发起请求来获取部分或全部资源。如图2所示，该数据处理系统包括：解析处理器11及控制器12。其中，

解析处理器11，用于接收并解析客户端20发送的请求消息；确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接；

控制器12，与所述解析处理器11通信连接，用于通过与所述解析处理器的交互获取并汇总所述解析处理器运行过程中产生的所述数据信息；根据汇总后的所述数据信息，对所述解析处理器进行动态调控。

上述中，解析处理器11接收到的请求消息为客户端发送到服务端的一个HTTP请求。在Web应用中，HTTP请求是客户端20在通过TCP（Transmission Control Protocol，传输控制协议）与服务端10建立TCP连接后，通过HTTP协议（超文本传输控制协议）向服务端10发送的一种请求消息，以从服务端10获取不同类型的文件资源，比如HTML文件、CSS文件、JavaScript文件、图片、视频等。HTTP协议是一种TCP/IP协议族上层的应用层协议，作用是用来定义互联网上客户端与Web服务端通信过程及格式。目前的HTTP协议版本包含但不限于HTTP1.0、HTTP1.1、HTTP2.0等。一般地，请求消息中的内容是由一些长度不确定的ASCII码文本串组成，其通常由请求行（request line）、请求头域（header）（包含一个空行）及请求数据三个部分组成，下述给出了请求消息的一般格式结构。

其中，请求行是用来告知服务端该客户端所需要的资源，主要包含请求方法、请求资源地址（即URL）和HTTP协议版本3个字段。请求方法表示客户端希望执行的动作，主要有GET（获取资源）、POST（新增资源）、PUT（更新资源）、DELETE（删除资源）等。各种不同的请求方法之中，GET和POST是最常用并且与HTTP慢连接攻击原理相关的方法，GET用于从服务端获取指定资源，如请求行GET/index.html HTTP/1.1就表示请求服务端主文件夹下index.html页面内容，而POST用于向服务端指定的资源提交需要被处理的数据，当客户端给服务端提供信息较多时可使用POST方法向服务端发送需处理的页面。请求头域主要包含多个与客户端环境及请求正文相关的基础信息，比如包含客户端所使用的操作系统、客户端内核等信息。每个请求头域由一个字段名（Key）、冒号和字段值（Value）三个部分组成，每一对值作为一行。在所有的请求头域结束后，用一个回车符和换行符组成的空行来标识请求头域的结束。由于请求头域中包含了一些服务端可能应用到的一些重要信息，为此，服务端在处理HTTP请求之前都需要接收完所有的请求头域。Slow Headers慢速攻击正式利用这一点，发起一个HTTP请求后，一直不停的发送HTTP头域来消耗服务端的连接和内存资源。

针对Slow Headers慢速攻击，一般采用的检测与防御手段是超时控制，即如图1所示：针对请求消息从整体上静态设置一个时间阈值，服务端10将请求消息发送至HTTP处理器14进行处理；HTTP处理器14在针对整体请求消息进行标准解析、响应等处理过程中，空闲超时控制器（图中未示出）会记录处理时间，若在所设置的时间阈值时限内为未处理完当前请求消息，便认为该当前请求消息为攻击请求，也就会关闭当前请求消息对应的TCP连接。不过，这种超时控制方式易造成误关闭连接（或称为误杀）。例如，假设一个正常客户端20上传一个大文件，服务端10需要执行插入数据库操作，服务端10在时间阈值规定的时限内，虽做好了处理但在超过该时间阈值时还未来得及做出响应，那么这样的话，服务端10因连接关闭也就无法针对当前请求消息做出相应的响应，导致客户端20无法收到响应结果，从而也就无法做出展示等操作。为此，在处理请求消息时，并不能简单的根据超时来判断请求消息是否为攻击请求。

这里需说明的是：上述HTTP处理器14对请求消息的标准解析流程包含：解析请求行（包括查找请求方法、指定的资源标识符（URI）以及协议版本号等）；解析请求头域，具体包括读取以\r\n结尾的请求头域以及检测以\r\n结尾的、标识请求头域结束的空行；读取请求数据。

为提高Slow Headers慢速攻击检测的准确性，降低误杀可能性，考虑到SlowHeaders慢速攻击为HTTP层的攻击，本实施例在HTTP处理器14前另设置了一个解析处理器11，利用该解析处理器11来实现采用预解析方式对请求消息进行处理，以对Slow Headers慢速攻击进行检测与防御。这里，预解析对应的解析流程，与利用HTTP处理器14对请求消息进行解析所对应的标准解析流程而言，为简化版的HTTP解析流程，在对请求消息解析过程中，仅解析请求消息相应的结构和记录当前解析位置，并不对请求消息作任何详细解析；在确定请求头域解析完成后，便结束解析，且解析结果也不会向之后的如HTTP处理器14透传，从而也就不会对之后的HTTP处理器产生任何影响。也就是说，解析处理器11，相当于旁路的一种处理模式，对于为Slow Headers慢速攻击的请求消息可起到检测、拦截等作用，对于正常的请求消息则直接放行至HTTP处理器14，以供HTTP处理器14对正常请求消息进行标准解析、响应等处理。

具体实现时，上述解析处理器11在解析客户端20发送的请求消息时，具体用于：

S11、检测所述请求消息的请求行是否满足超文本传输协议格式；

S12、确定满足超文本传输协议格式时，将当前解析状态变更为解析所述请求消息的请求头域，并启动状态监测任务，以监测解析所述请求头域对应的参数；

S13、所述请求头域解析完成后，结束对所述请求消息的解析。

实际应用中，不同性能的服务端10将会以不同的方式来处理请求消息。比如，对于单线程的服务端10，一次只处理一个请求消息，直至请求消息处理完成为止；对于多进程及多线程的服务端，其用多个进程或更高效的线程同时对请求消息处理，等等。基于上述内容，在本实施例提供的技术方案中，为符合多数用户的服务端10性能，在开发设计解析处理器11时，优先设计了解析处理器11针对请求消息采用单线程处理模式，换句话也就是说，解析处理器11一次只解析处理一个请求消息，在开始对一个新请求消息解析处理前，需确保已结束了上一个请求消息的解析。为此，解析处理器11在检测所述请求消息的请求行是否满足超文本传输协议格式之前，还具体用于：

S10a、针对所述请求消息，确定当前解析状态是否为请求解析重置状态；

S10b、在确定当前解析状态为解析重置状态的情况下，跳过所述请求消息中的控制字符，将所述当前解析状态转换为初始化解析状态，开始执行对所述请求消息的解析操作。

具体实施时，上述请求解析重置状态为每个新的请求消息的起始状态，换句话也就是说，为一个新请求消息对应的请求解析的初始默认状态。在确定当前解析状态为解析重置状态的情况下，跳过请求消息中的控制符（如换行符、回车符、退格符等），是为寻找到请求消息中的第一个非控制符的字符，以便将当前解析状态变更为为初始化解析状态，以开始对请求消息执行解析操作。若当前接收到的整个请求消息中都没有一个非控制符，则将不做解析，会将请求消息相应的读索引设置为写索引以标志当前的请求消息中的数据都已读过。

基于上述描述的解析处理器11对请求消息的解析过程，下述展示了一相应程序代码以来说明解析处理器11对请求消息的解析处理方式。在下述程序代码中，用RESET、INIT、HEADER及OTHER四个状态标识来表示的解析处理器11对请求消息解析时所处的相应四种解析状态。其中，RESET表示请求重置状态，为解析起始状态，是一个请求解析的初始默认状态；INIT表示解析的初始化状态，表征了开始解析请求消息；HEADER表示开始且正在解析请求消息的请求头域；OTHER表示解析请求消息中除了请求头域之外的且位于请求头域之后的其它部分，如请求数据、不定长请求数据等等。具体地，与解析处理器11对请求消息的解析过程相应的程序代码如下所示：

if (重置请求) { resetNow();}

switch (当前状态) {

case RESET：if (!skipControlCharacters(buffer)) {return;}currentState= State.INIT;

case INIT：Appe### line = line###.parse(buffer);if (line == null){return;}

String[] initialLine = splitInitialLine(line);

if (initialLine.length < 3) {currentState = State.RESET;return;}

currentState = State.HEADER;

new ReadTimeoutCheckTask(###, ###, ###).start();

case HEADER：State nextState = readHeaders(buffer);

if (nextState == null) {return;} currentState = nextState;

case OTHER: resetNow(); break; }

上述中，语句“if (重置请求) { resetNow();}”功能为状态重置，以表明上一个请求消息解析完成。之后，解析处理器11便会开始以请求消息的当前解析状态（currentState）为条件，开始执行switch语句以针对当前请求消息的不同解析状态，执行不同的解析方法。具体地：一个新请求消息的初始默认状态往往为RESET状态，为此，解析起始时将会匹配到case RESET条件语句，执行case RESET语句以找到请求消息对应的数据包的开始；该case RESET语句中的“if (!skipControlCharacters(buffer)) {return;}”功能为跳过控制符，以从第一个非控制符开始，若返回false，则认为没有找到请求数据包，则直接结束解析；反之，便会执行“currentState = State.INIT”语句，将当前解析状态变更为INIT状态，从而开始执行case INIT条件语句，以开始读取请求消息的请求行。

在执行case INIT过程中，会先执行语句“Appe### line = line###.parse(buffer);if (line == null) {return;}”，以从buffer中读取一行数据，遇到回车换行符为一行，若读取不到一行数据则结束；反之，若成功读取到一行数据，则进一步地执行语句“String[]......, if (initialLine.length < 3) {.......;}”，以判断该行数据是否为为一个HTTP协议请求消息的请求行。具体实现时，是据空格符切割字符串为数组，判断该行数据分割后的数组长度是否为3，不是便认为这不是一个HTTP协议请求消息的请求行，将解析状态重置为RESET状态；反之，则执行语句“currentState = State.HEADER”，将当前解析状态变更为HEADER状态，并且，还会执行“new ReadTimeoutCheckTask(......).sta...”语句，以创建一个状态监测任务，以便在下一步执行case HEADER以读取解析请求消息的请求头域时，对解析请求头域对应的参数（如解析时长、解析状态检测次数等）进行监测，确定该请求消息是否为攻击请求，并在确定请求消息为攻击请求时实现对攻击请求拦截处理。关于状态检测任务的具体实现，将下文中进行详细描述，此处不作具体赘述。

进一步地，在完成请求头域解析后，当前解析状态会变更为OTHER状态，此时将执行case OTHER条件语句，结束对请求消息的解析。

上述中，解析处理器11在对请求消息解析过程中，进入解析请求头域时会启动“ReadTimeoutCheckTask”线程任务，即启动状态监测任务，以监测解析所述请求头域对应的参数。其中，参数可以为解析时长、解析状态检测次数中的任一种。解析请求头域过程中，若确定参数达到预设条件，比如解析时长大于等于所设定的第一阈值，或者以预设时间间隔对解析状态进行检测，检测次数达到设定次数时，当前解析状态仍为解析请求头域，便可认为当前请求消息为攻击请求，即可关闭当前请求消息对应的TCP连接，实现对攻击请求的拦截。上述解析时长或检测次数可根据实际情况灵活设置，此时不作限定。比如，解析时长可以为3秒、5秒、7秒等，检测次数可以为2次、3次等。下面以参数为检测次数为例，来介绍一下上述“ReadTimeoutCheckTask”线程任务的具体实现。具体地：

参数如下示出的用于实现“ReadTimeoutCheckTask”任务的程序代码：

Promise<Boolean> needStop = ctx.executor().newPromise();

int currentSum=2；

ctx.executor().#######-> {

int currentSum = currentSum--;

boolean stillHeaderState = Slow####.checkCurrentState();

if (!stillHeaderState && currentSum <= 0) {needStop.setSuccess(true);}

else if(stillHeaderState&&currentSum<=0){needStop.setSuccess(true);ctx.close();}

}, 0, timeout, timeUnit).addListener (future -> {

if (needStop.isDone()) {future.cancel(true);}});

在上述示出的“ReadTimeoutCheckTask”线程任务中，“### needStop=###”为所设置的一个关闭条件的线程通知。用参数currentSum表征检测次数，并设置检测次数currentSum为2，在该线程中通过Slow####.checkCurrentState()函数实现以设定的时间间隔来执行一次判断当前解析状态，时间间隔可以为设置的默认时长阈值，比如为1.5秒、2.5秒等，此时不作限定。当检测次数达到要求且确定当前解析状态不再是解析请求头域状态（即满足条件!stillHeaderState && currentSum <= 0）时，认为该当前请求消息为正常请求消息，可执行关闭当前的检测任务，退还占用的线程资源，后续中该正常请求消息将被发送至HTTP处理器14中进行标准解析处理；反之，若检测次数达到要求但当前解析状态仍为解析请求头域状态（即满足条件stillHeaderState && currentSum <= 0），则认为该当前请求为异常请求（也即攻击请求），此时可执行抛出异常提醒，并通过ctx.close()函数关闭当前请求消息对应的TCP连接，同时还可通过线程监听器（addListener）释放占用的线程资源。

综上可见，解析处理器11在对请求消息进行检测是否为异常请求时，是根据对请求头域（header）的处理参数（如当前解析状态的检测次数、解析时长等）来判定的，换句话也就是说，靠着当前解析状态是否为HEADER及解析状态检测次数是否超过设定次数这两个状态为来判断请求消息是否为异常请求，从而确定是否关闭请求消息对应的连接。这种检测与防御方式，能够较大的提高异常请求检测成功率，减低误杀可能性。

这里需要说明的是，上述解析处理器可以为但不限于软件程序、物理处理器等，在为物理处理器的情况下，该物理处理器中内置有相应的软件程序以实现对本实施例提供的对请求消息的解析处理。作为优选实例，本实施例中的解析处理器为软件程序。

进一步地，为实现能够根据实际需求对解析处理器11的启停、运行处理时间参数等进行动态调控，本实施例还专设置了一个与解析处理器11通信交互的控制器12（如图2），以用于控制解析处理器11。具体地，解析处理器11在运行期间，会实时向控制器12上报其自身运行过程中产生的数据信息，如接收到的请求总量、当前已关闭请求连接数、当前运行时间等；控制器对收到的数据信息进行汇总处理，并根据汇总后的数据信息，可对解析处理器11进行动态调控。关于动态调控的具体实现可参加下述相关内容。

进一步地，如图2所示，本实施例还设置有后台管理器13，用于采集整体系统的系统相关信息，以实现从系统宏观角度通过控制器12对解析处理器11进行动态调控。为此，控制器12还与后台管理器13通信连接，且控制器12还用于在汇总后的数据信息满足发送条件时，将汇总后的所述数据信息发送至后台管理器13；相应地，后台管理器13用于基于接收到汇总后的所述数据信息，确定系统相关信息。

具体实施时，后台管理器13除了能够实现与控制器12的通信连接外，还能够实现与HTTP处理器14、其它处理器15等的通信连接，且同时TTP处理器14、其它处理器15等也会实时或定周期将各自运行过程中产生的数据信息发送至后台管理器13，后台管理器13是根据接收到的控制器12发送的汇总后的数据信息，以及TTP处理器14、其它处理器15等发送的数据信息，来综合确定系统相关信息的。其中，系统相关信息可以为但不限于请求总量、服务压力、当前流量等。

在一具体可实现技术方案中，上述控制器12在用于汇总后的所述数据信息满足发送条件时，将汇总后的所述数据信息发送至所述后台管理器时，可具体用于：

发送周期满足时，将汇总后的周期内所述解析处理器运行过程中产生的数据信息发送至所述后台管理器；或者

所述解析处理器处于无工作状态的时长达到第二阈值时，将所汇总的达到所述第二阈值之前所述解析处理器运行过程中产生的数据信息发送至所述后台管理器；其中，无工作状态是指所述解析处理器处于不再执行关闭连接操作的工作状态。

具体实施时，上述发送周期、第二阈值等均可根据实际情况进行灵活自定义，并通过控制器12管控。比如，发送周期可以为但不限于30分钟、1小时、3小时、1天等，第二阈值可以为12小时、1天、3天等，此处均不作限定。

当因没有相应的Slow Headers慢速攻击，解析处理器11不再执行关闭请求消息对应的连接操作时，便可视为解析处理器处于无工作状态。在确定解析处理器11长时间处于无工作状态的情况下，可根据相关调控决策，选择关闭解析处理器11以减少服务端资内存消耗，或者也可以对解析处理器11的运行时间参数进行调整，该运行时间参数用于控制解析处理器11自开启时刻起，可运行的总时长。比如，假设设置的运行时间参数为24小时，那么，从解析处理器11开启时刻算起，在解析处理器11运行时长达到24小时后，控制器12便控制解析处理器11自动关闭。上述中，调控决策可以是控制器12直接根据汇总后的数据信息确定出的决策，不过，这种单纯由控制器12直接确定对解析处理器11的调控决策，所依据的数据信息具有片面性，决策结果具有较低精准性。由于后台管理器13是从较为宏观角度来把控整体系统，其既可以作为系统相关信息收集平台，也可以作为决策平台，为此，可将控制器12对解析处理器11作出的调控决策作为参考决策发送至后台管理器13，以由后台管理器13根据收到的调控决策和系统相关信息，针对解析处理器11做出最终调控决策。即，

在一种可实现的技术方案中，控制器12在根据汇总后的所述数据信息，对所述解析处理器11进行动态调控时，可具体用于：

S21、在确定解析处理器11处于无工作状态的时长达到第三阈值时，根据所汇总的达到所述第三阈值之前所述解析处理器运行过程中产生的数据信息，确定针对解析处理器11做出的调控决策并发送至所述后台管理器13；

S22、接收所述后台管理器13反馈的最终调控决策；

S23、按照所述最终调控决策对所述解析处理器执行相应的调控操作；其中，所述

调控操包括如下中的任一种：关闭解析处理器、修改解析处理器的运行时间参数；

相应地，后台管理器13，用于根据接收到所述调控决策及所述系统相关信息，确定针对所述解析处理器做出的最终调控决策；将所述最终调控决策反馈至所述控制器。

具体实施时，上述第三阈值同样可根据实际情况灵活自定义设置，并由控制器12管控。在控制器12是按照确定解析处理器11处于无工作状态的时长达到第二阈值时，来向后台管理器13发送所汇总的数据信息的情况下，上述第三阈值可以大于或等于第二阈值，此处不作限定。图3中示出了通过后台管理器做出对解析处理器11的最终调控决策的原理时序图。

如图3所示，假设控制器12是按照确定解析处理器11处于无工作状态的时长达到第二阈值时，来向后台管理器13发送所汇总的数据信息的。控制器12在对解析处理器11上报的数据信息进行汇总并发送至后台管理器后，可以同时或间隔一一定时间根据汇总后的数据信息确定出对解析处理器11做出的调控决策，并将该调控决策作为参考决策上报至后台管理器13；之后，后台管理器13可根据接收到的调控决策及系统相关信息，针对解析处理器11做出最终调控决策并反馈给控制器12，从而控制器12可按照最终调控决策对解析处理器11执行相应的调控操作，比如，通过调用相应关闭线程任务来关闭解析处理器，或者通过调用相应的参数修改线程任务来修改（如增加或缩减）解析处理器11的运行时间参数等。

在关闭解析处理器11后，还可以根据实际需求来自动和/或人工控制解析处理器11的开启。其中，解析处理器11的自动开启，可通过后台管理器13向控制器12发送启动决策指令实现；而解析处理器11的人工开启，可由服务端通过响应用户针对解析处理器11触发的启动操作实现。基于此，

后台管理器13，还可用于根据所述系统相关信息，向所述控制器发送启动所述解析处理器的启动决策。相应地，

控制器12，还用于如下中的至少一项：接收到所述启动决策，按照所述启动决策控制所述解析处理器开启；响应于用户针对所述解析处理器触发的启动操作，控制所述解析处理器开启。

具体实施时，后台管理器13可根据系统相关信息，对系统负载信息进行一个计算，在确定出系统具有较大负载时，可初步判定服务端可能在遭受Slow Headers慢速攻击，需要启动解析处理器11以拦截攻击请求，此时其可向控制器12发送一个启动决策指令，使得控制器12按照启动决策，通过调用相应的启动线程任务控制解析处理器11的开启。图4示出了控制器12按照后台管理器13下发的启动决策来控制解析处理器11开启的原理时序图。

而对于人工启动解析处理器的具体实现，可以是在服务端基于收到的异常上报信息、通过抓包等形式，确定出在遭受Slow Headers慢速攻击后，发出用户可感知的提示信息，比如：语音提示，或者在服务端对应的终端提供的交互界面上，显示包含文体、图片、字符等中的一种或组合的提示信息。用户针对该提示信息，可通过终端提供的交互界面触发解析处理器11的开启操作，从而服务端响应于用户针对解析处理器11触发的启动操作，即可控制解析处理器开启。

上述所描述的启动解析处理器两种方式，即自动方式和人工方式，二者为相辅相成的、互为备份的关系。因人工启动和自动启动均都有出错时刻，通过融合人工启动和自动启动，实现双保险可增加冗余度，利于降低Slow Headers慢速攻击误报率。

这里需补充说明的是：同解析处理器，本实施例中的控制器及后台管理器等也可以为软件程序或相应的物理实体。作为优选实例，本实施例中的控制器、后台管理器及解析处理器等均采用软件程序实现。将解析处理器、控制器及后台管理器等采用软件形式实现，方便与各种应用程序无缝集成以提高应用安全性。

上文内容是从系统整体角度来介绍本申请提供的技术方案的，下面将基于上文数据处理系统中的各模块（如解析处理器、控制器等）所执行的不同功能，从各模块角度进行介绍说明本技术方案。具体地，

图5示出了本申请一实施例提供的数据处理方法的流程示意图。本实施例提供的所述方法的执行主体可以为上述数据处理系统中的解析处理器。具体地，如图5所示，所述数据处理方法包括如下步骤：

101、接收并解析客户端发送的请求消息；

102、确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；

103、在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接。

上述参数可以为但不限于如下中的任一种：解析时长、解析状态检测次数；相应地，参数达到预设条件可包括：解析时长大于等于预设阈值；或者，以预设时间间隔对解析状态进行检测，检测次数达到预置次数。有关上述101~103的具体实现内容，可参见上文中的相应内容，此次不作赘述。

进一步地，本实施例提供的所述方法还可包括如下步骤：

104、将自身运行过程中产生的数据信息发送至控制器，以便所述控制器获取并汇总所述数据信息。

图6示出了本申请另一实施例提供的数据处理方法的流程示意图。本实施例提供的所述方法的执行主体可以为上述数据处理系统中的控制器。具体地，如图6所示，所述数据处理方法包括如下步骤：

201、接收并汇总解析处理器发送的自身运行过程中产生的数据信息；

202、根据汇总后的数据信息，对所述解析处理器进行动态调控。

上述中，述数据信息可以包括但不限于如下中的至少一项：接收到的请求总量、当前已关闭请求连接数、当前运行时间。有关上述101~103的具体实现内容，可参见上文中的相应内容，此次不作赘述。

进一步地，本实施例提供的所述方法还可包括如下步骤：

203、汇总后的数据信息满足发送条件时，将汇总后的数据信息发送至后台管理器，以便后台管理器根据所述汇总后的数据信息，确定系统相关信息。

进一步地，在一具体可实现的技术方案中，上述202“根据汇总后的数据信息，对所述解析处理器进行动态调控”，可具体包括：

2021、在确定所述解析处理器处于无工作状态的时长达到设定阈值时，根据所汇总的达到所述设定阈值所述解析处理器运行过程中产生的数据信息，确定针对所述解析处理器做出的调控决策并发送至所述后台管理器；

2022、接收所述后台管理器反馈的最终调控决策；其中，所述最终调控决策是根据接收到所述调控决策及所述系统相关信息确定的；

2023、按照所述最终调控决策，对所述解析处理器执行相应的调控操作；其中，所述调控操作包括如下中的任一种：关闭解析处理器、修改解析处理器的运行时间参数。

进一步地，本实施例提供的所述方法还可包括如下中的至少一项：

接收所述后台管理器发送的针对所述解析处理器做出的启动决策，并按照所述启动决策控制所述解析处理器开启；

响应于用户针对所述解析处理器触发的启动操作，控制所述解析处理器开启。

综上内容，本申请各实施例提供的技术方案具有如下特点：

1、采用解析处理器来对HTTP协议类型的请求消息进行精简化解析，实现对SlowHeaders慢速攻击的检测与防御，能够有效减低误判率；

2、利用控制器，实现对解析处理器的启动、停止、时间参数修改等进行动态调整方，可以做到不停机防护，且还可以提高平均请求率、降低攻击误报等；

3、解析处理器、控制器等采用软件形式实现，方便与各种应用程序无缝集成，从而提高应用安全性。

4、具有较高的检测与防御性能。经测试，单页面加上解析处理器后性能能达到原有的90%以上，且攻击请求阻断基本无错误产生。

图7示出了本申请一实施例提供的数据处理装置的结构框图，该数据处理装置集成于上述数据处理系统中的解析处理器。如图7所示，该数据处理装置包括：接收解析模块31、确定模块32及关闭模块33；其中，

接收解析模块31，用于接收并解析客户端发送的请求消息；

确定模块32，用于确定当前解析状态为解析所述请求消息中的请求头域时，监测解析所述请求头域对应的参数；

关闭模块33，用于在所述参数达到预设条件且当前解析状态仍为解析所述请求头域时，关闭当前所述请求消息对应的连接。

上述中，参数包括如下中的任一种：解析时长、解析状态检测次数；相应地，参数达到预设条件包括：所述解析时长大于等于预设阈值；或者，以预设时间间隔对解析状态进行检测，检测次数达到预置次数。

进一步地，本实施例提供的装置还可包括：发送模块，用于将自身运行过程中产生的数据信息发送至控制器，以便所述控制器获取并汇总所述数据信息。

这里需要说明的是：上述实施例提供的数据处理装置可实现上述各方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述各方法实施例中的相应内容，此处不再赘述。

图8示出了本申请另一实施例提供的数据处理装置的结构框图，该数据处理装置集成于上述数据处理系统中的控制器。如图8所示，该数据处理装置包括：接收汇总模块41及调控模块42；其中，

接收汇总模块41，用于接收并汇总解析处理器发送的自身运行过程中产生的数据信息；

调控模块42，用于根据汇总后的数据信息，对所述解析处理器进行动态调控。

进一步地，本实施例提供的所述装置还可包括：

发送模块，用于汇总后的数据信息满足发送条件时，将汇总后的数据信息发送至后台管理器，以便后台管理器根据所述汇总后的数据信息，确定系统相关信息。

进一步地，上述调控模块42，在用于根据汇总后的数据信息，对所述解析处理器进行动态调控时，具体用于：

在确定所述解析处理器处于无工作状态的时长达到设定阈值时，根据所汇总的达到所述设定阈值所述解析处理器运行过程中产生的数据信息，确定针对所述解析处理器做出的调控决策并发送至所述后台管理器；

接收所述后台管理器反馈的最终调控决策；其中，所述最终调控决策是根据接收到所述调控决策及所述系统相关信息确定的；

按照所述最终调控决策，对所述解析处理器执行相应的调控操作；其中，所述调控操作包括如下中的任一种：关闭解析处理器、修改解析处理器的运行时间参数。

进一步地，本实施例提供的所述装置还可包括：

接收启动模块，用于接收所述后台管理器发送的针对所述解析处理器做出的启动决策，并按照所述启动决策控制所述解析处理器开启；和/或

响应模块，用于响应于用户针对所述解析处理器触发的启动操作，控制所述解析处理器开启。

本申请一实施例还提供了一种服务端设备。服务端设备的结构如图2示出的服务端10结构。具体地，该服务端设备包括：存储器（图中未示出）、解析处理器11及控制器12；其中，

所述存储器，用于存储一条或多条计算机指令；

所述解析处理器，与所述存储器耦合，用于执行所述一条或多条计算机指令，以用于实现上述图5示出的数据处理方法中的步骤；

所述控制器，与所述存储器耦合及与所述解析处理器通信连接，用于执行所述一条或多条计算机指令，以用于实现上述图6中示出的数据处理方法中的步骤。

上述存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步，如图2所示，服务端设备还包括：TTTP处理器14、其他处理器15等其它组件。图2中仅示意性给出部分组件，并不意味着服务端设备只包括图2所示组件。

本申请还有一实施例提供一种计算机程序产品（说明书附图中无相应附图示出）。该计算机程序产品包括计算机程序或指令，当所述计算机程序或指令被处理器执行时，致使所述处理器能够实现上述各方法实施例中的步骤。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例提供的方法步骤或功能。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims

1.一种数据处理系统，其特征在于，包括：

2.根据权利要求1所述的系统，其特征在于，所述解析处理器在解析客户端发送的请求消息时，具体用于：

检测所述请求消息的请求行是否满足超文本传输协议格式；

确定满足超文本传输协议格式时，将当前解析状态变更为解析所述请求消息的请求头域，并启动状态监测任务，以监测解析所述请求头域对应的参数；

所述请求头域解析完成后，结束对所述请求消息的解析。

3.根据权利要求2所述的系统，其特征在于，所述参数包括如下中的任一种：解析时长、解析状态检测次数；以及，

所述参数达到预设条件包括：所述解析时长大于等于第一阈值；或者，以预设时间间隔对解析状态进行检测，检测次数达到设定次数。

4.根据权利要求1至3中任一项所述的系统，其特征在于，还包括：

后台管理器；

所述控制器，还与后台管理器通信连接，用于汇总后的所述数据信息满足发送条件时，将汇总后的所述数据信息发送至所述后台管理器；

所述后台管理器，用于基于接收到汇总后的所述数据信息，确定系统相关信息。

5.根据权利要求4所述的系统，其特征在于，所述控制器在用于汇总后的所述数据信息满足发送条件时，将汇总后的所述数据信息发送至所述后台管理器时，具体用于：

6.根据权利要求5所述的系统，其特征在于，

所述控制器，在根据汇总后的所述数据信息，对所述解析处理器进行动态调控时，具体用于：在确定所述解析处理器处于无工作状态的时长达到第三阈值时，根据所汇总的达到所述第三阈值之前所述解析处理器运行过程中产生的数据信息，确定针对所述解析处理器做出的调控决策并发送至所述后台管理器；接收所述后台管理器反馈的最终调控决策；按照所述最终调控决策对所述解析处理器执行相应的调控操作；其中，所述调控操作包括如下中的任一种：关闭解析处理器、修改解析处理器的运行时间参数；

所述后台管理器，用于根据接收到所述调控决策及所述系统相关信息，确定针对所述解析处理器做出的最终调控决策；将所述最终调控决策反馈至所述控制器。

7.根据权利要求6所述的系统，其特征在于，

所述后台管理器，还用于根据所述系统相关信息，向所述控制器发送启动所述解析处理器的启动决策；

所述控制器，还用于如下中的至少一项：接收到所述启动决策，按照所述启动决策控制所述解析处理器开启；响应于用户针对所述解析处理器触发的启动操作，控制所述解析处理器开启。

8.根据权利要求4所述的系统，其特征在于，

所述数据信息包括如下中的至少一项：接收到的请求总量、当前已关闭请求连接数、当前运行时间；

所述系统相关信息包括如下中的至少一项：请求总量、服务压力、当前流量。

9.一种数据处理方法，其特征在于，适用于解析处理器，所述方法包括：

接收并解析客户端发送的请求消息；

10.根据权利要求9所述的方法，其特征在于，所述参数包括如下中的任一种：解析时长、解析状态检测次数；以及

所述参数达到预设条件包括：所述解析时长大于等于预设阈值；或者，以预设时间间隔对解析状态进行检测，检测次数达到预置次数。

11.根据权利要求9或10所述的方法，其特征在于，还包括：

将自身运行过程中产生的数据信息发送至控制器，以便所述控制器获取并汇总所述数据信息。

12.一种数据处理方法，其特征在于，适用于控制器，所述方法包括：

根据汇总后的数据信息，对所述解析处理器进行动态调控。

13.根据权利要求12所述的方法，其特征在于，还包括：

汇总后的数据信息满足发送条件时，将汇总后的数据信息发送至后台管理器，以便后台管理器根据所述汇总后的数据信息，确定系统相关信息。

14.根据权利要求13所述的方法，其特征在于，根据汇总后的数据信息，对所述解析处理器进行动态调控，包括：

15.根据权利要求14所述的方法，其特征在于，还包括如下中的至少一项：

16.一种服务端设备，其特征在于，包括：存储器、解析处理器及控制器；其中，

所述存储器，用于存储一条或多条计算机指令；

所述解析处理器，与所述存储器耦合，用于执行所述一条或多条计算机指令，以用于实现上述权利要求9至11中任一项所述方法中的步骤；

所述控制器，与所述存储器耦合及与所述解析处理器通信连接，用于执行所述一条或多条计算机指令，以用于实现上述权利要求12至15中任一项所述方法中的步骤。