CN105939313B - 状态码重定向方法及装置 - Google Patents

Abstract

本申请提供一种状态码重定向方法及装置，所述方法应用于负载均衡设备上，所述方法包括：根据预设的识别条件对客户端发送的第一HTTP请求进行识别；将所述第一HTTP请求发送至Web服务器；接收所述Web服务器针对第一HTTP请求返回的HTTP响应；如果识别成功且所述HTTP响应携带的状态码在预先配置的状态码表有对应的重定向URL地址，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求。应用本申请实施例，通过负载均衡设备取代Web服务器实现状态码重定向技术，可以极大简化状态码重定向的部署。

Description

状态码重定向方法及装置

技术领域

本申请涉及网络通信技术领域，尤其涉及一种状态码重定向方法及装置。

背景技术

HTTP(Hyper Text Transfer Protocol，超文本传输协议)协议是互联网上应用最为广泛的一种网络传输协议。Web服务器根据客户端发送的HTTP请求返回HTTP响应，而HTTP响应携带的状态码是用以表示Web服务器HTTP响应状态的三位数字代码，所述状态码的第一个数字代表了HTTP响应的状态，所述HTTP响应的状态包括消息(1××)、成功(2××)、重定向(3××)、客户端请求错误(4××)、Web服务器错误(5××)。在相关技术中，利用状态码重定向技术对所述HTTP响应的状态码进行控制，以重新定制状态码，从而实现客户端请求的目标网页跳转。请参考图2A，当Web服务器返回的HTTP响应的状态码为404时，表示客户端发送的HTTP请求错误，此时页面显示乱码，这会影响到用户体验。请参考图2B，通过状态码重定向技术可以改善用户体验，此时将客户端请求的目标网页被重定向至一个预设网页，该预设网页不再是乱码，这一方面可以提升用户体验，另一方面可以允许Web服务提供者在预设网页上推送一些有益的信息，比如热点新闻或公益广告等。

但是，现有的状态码重定向技术是通过在Web服务器(也就是提供Web服务的服务器上)上配置实现，一方面，该实现方式需要Web服务器软件平台的支持，不易于Web服务器的扩展和维护，并且复用性也差，导致Web服务器集群难以同时实现对状态码重定向技术的支持；另一方面，如果要实现Web服务器集群或者说大量Web服务器同时支持该技术，则需要付出极高的管理和维护成本。

发明内容

有鉴于此，本申请提供一种状态码重定向方法及装置，以解决现有技术中，通过在Web服务器上配置实现状态码重定向技术，导致不易于对Web服务器进行扩展和维护，并且难以实现Web服务器集群对状态码重定向技术支持的问题。

根据本申请实施例的第一方面，提供一种状态码重定向方法，所述方法应用于分别与客户端和Web服务器相连的负载均衡设备上，所述方法包括：

根据预设的识别条件对客户端发送的第一HTTP请求进行识别；

将所述第一HTTP请求发送至Web服务器；

接收所述Web服务器针对第一HTTP请求返回的HTTP响应；

如果识别成功且所述HTTP响应所携带的状态码在预先配置的状态码表有对应的重定向URL地址时，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的重定向URL地址。

根据本申请实施例的第二方面，提供一种状态码重定向装置，所述方法应用于分别与客户端和Web服务器相连的负载均衡设备上，所述装置包括：

识别单元，用于根据预设的识别条件对客户端发送的第一HTTP请求进行识别；

转发单元，用于将所述第一HTTP请求发送至Web服务器；

接收单元，用于接收所述Web服务器针对第一HTTP请求返回的HTTP响应；

处理单元，用于如果识别成功且所述HTTP响应所携带的状态码在预先配置的状态码表有对应的重定向URL地址时，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的重定向URL地址。

应用本申请实施例，负载均衡设备根据预先配置的识别条件对客户端发送的第一HTTP请求进行识别，对于满足识别条件的第一HTTP请求，如果其对应的HTTP响应出现问题，则负载均衡设备可以使用相应的重定向URL地址来引导客户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络中，尤其是数据中心中，负载均衡设备数量远远小于Web服务器的数量，因此可以极大简化状态码重定向的部署。

附图说明

图1为本申请根据一示例性实施例示出的状态码重定向的典型应用场景示意图；

图2为本申请根据一示例性实施例示出的一种状态码重定向方法的实施例流程图；

图2A为本申请根据一示例性实施例示出的一种状态码重定向方法中的状态码为404时客户端显示的网页示意图；

图2B为本申请根据一示例性实施例示出的一种状态码重定向方法中的状态码重定向后客户端显示的网页示意图；

图3为本申请根据一示例性实施例示出的另一种状态码重定向方法的实施例流程图；

图4为本申请根据一示例性实施例示出的一种状态码重定向装置所在设备的硬件结构图；

图5为本申请根据一示例性实施例示出的一种状态码重定向装置的实施例框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请实施例中的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方案作进一步详细的说明。

现有的状态码重定向技术在Web服务器中实现，当Web服务器根据客户端发送的HTTP请求生成HTTP响应时，Web服务器将所述HTTP响应的状态码与预先配置的状态码重定向表进行匹配，如果匹配到所述状态码(比如404)，则将状态码重定向表中所述状态码对应的重定向URL地址，以状态码为301或302的HTTP重定向方式发送至客户端，如果未匹配到所述状态码，则将所述HTTP响应返回至客户端。由此可见，当一个数据中心或者Web服务器集群中增加一个新的Web服务器，其势必要进行状态码重定向技术的部署，增加管理员的管理难度。再者如果状态码重定向软件进行升级，比如说需要更新重定向URL地址时，则需要对所有的Web服务器都进行配置，同样会增加管理操作的成本，这样的实现方式不利于Web服务器的扩展和维护。

本申请从全新的思路来改进状态码重定向技术在多Web服务器环境下的实现以解决上述技术问题。参见图1所示，为本申请一个典型的实施例应用场景示意图。该应用场景中包括客户端、Web服务器以及位于客户端与Web服务器之间的负载均衡设备。其中，客户端可以是手机、笔记本、台式机等；负载均衡设备位于多个Web服务器的前端，负责将客户端发起的HTTP请求分发给后端的Web服务器进行处理。在本申请一个例子中，负载均衡设备根据预先配置的识别条件对HTTP请求进行识别，对于满足识别条件的HTTP请求，如果其对应的HTTP响应出现问题，则负载均衡设备可以使用相应的重定向URL地址来促使客户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络中，尤其是数据中心中，负载均衡设备数量远远小于Web服务器的数量，因此可以极大简化状态码重定向的部署。

参见图2所示，在一个例子中，本申请提供的一种状态码重定向方法的实施例流程图，该方法应用于负载均衡设备上，包括以下步骤：

步骤S201：根据预设的识别条件对客户端发送的第一HTTP请求进行识别。

客户端在发送第一HTTP请求之前，会尝试与远端的Web服务器建立TCP连接，一般来说，在有负载均衡设备的组网中，负载均衡设备会负责与客户端建立TCP连接。在TCP连接建立成功后，负载均衡设备会接收到客户端发送的第一HTTP请求，在一种可选的实现方式中，所述负载均衡设备通过预设的识别条件，对所述第一HTTP请求进行识别。这一识别过程可以理解为有选择地进行处理。如前所述，当HTTP请求所对应的HTTP响应出现问题的时候，负载均衡设备需要进行重定向处理。然而对于管理员来说，并非所有HTTP响应出现问题都有必要进行重定向处理。以下先介绍识别条件的具体示例，在后续步骤中再对识别条件所带来的技术优势进行解释。

在一个例子中，所述预先配置的识别条件可以包括以下子条件中的一种或多种的组合。

i.URL地址目录级别数量小于预设数量；

ii.请求资源类型为预设的一种或多种类型；

iii.URL地址包括有指定的关键词。

以条件i以及条件ii为例，在具体的开发中，可以使用查表的方式来实现识别，当然本申请并不排除其他实现方式。请参考表1所示，其包含了HTTP请求的URL地址目录级别数小于等于4、请求资源类型以.htm或.html后缀结尾这两个子条件。在这个例子中，两个子条件是组合使用的，两者之间的关系可以是与的关系，也就是说两个子条件都满足才算识别成功。一般来说，识别条件通常是管理员配置的。在其他例子中，上述两个子条件之间的关系可以是或的关系，对此本申请并不限定。一般来说，客户端发送的HTTP请求携带的URL地址目录级别数越小越利于服务器解析，通常情况下，建议管理员设置URL地址目录级别数不超过3或4，而且大部分网站页面的主文件资源类型以.htm或.html后缀结尾。

子条件1	URL地址级别：≦4
		子条件2	请求资源类型：.htm或.html

表1

根据上述识别条件，负载均衡设备获取所述第一HTTP请求的URL地址目录级别数和请求资源类型，如果获取到的URL地址目录级别数和请求资源类型均满足对应的子条件，则可以对所述第一HTTP请求所属的会话进行置位表明识别成功，否则表明识别不成功，按照既有的方式继续后续处理即可。

步骤S202：向Web服务器发送所述第一HTTP请求。

当所述第一HTTP请求经过识别之后，负载均衡设备可以与所述Web服务器建立TCP连接，将所述第一HTTP请求发送至所述Web服务器，以使所述Web服务器返回HTTP响应。一般来说，负载均衡设备可以根据预设的负载均衡算法将大量的HTTP请求分发到不同的Web服务器上进行处理，这些Web服务器通常可以处理相同的业务服务。

步骤S203：接收Web服务器返回的HTTP响应。

Web服务器接收到所述负载均衡设备发送的第一HTTP请求之后，根据所述第一HTTP请求访问的网页资源向负载均衡设备返回HTTP响应。

步骤S204：查询对所述第一HTTP请求是否识别成功，若识别成功，则执行步骤S205，否则执行步骤S206。

当负载均衡设备接收到所述Web服务器返回的HTTP响应时，可以先查询通过前述会话的置位确定识别结果，如果识别成功，则确定对所述第一HTTP请求识别成功，执行步骤S205，否则执行步骤S206。

步骤S205：根据所述HTTP响应的状态码在预先配置的状态码表中进行查找，若查找到所述状态码，则执行步骤S207，否则执行步骤S206。

当负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表进行查找时，可以先清除该HTTP响应所属会话的置位，若在所述状态码表中查找到所述状态码，则获取该状态码对应的重定向URL地址，执行步骤S207，若没有查找到所述状态码，则执行步骤S206。

在一种可选的实现方式中，负载均衡设备可以先使用AC(Aho and Corasick，多模式匹配算法)算法查找HTTP响应中携带的状态码。一般来说，所述HTTP响应携带的状态码位于HTTP响应的头部，因此可以从所述HTTP响应头部的起始位置开始解析，查找到所述HTTP响应头部的结束位置，一般结束的标识为\r\n\r\n。然后根据查找到的状态码在预先配置的状态码表中查找对应的重定向URL，所述状态码表可以包括状态码和状态码对应的重定向URL地址，如表2所示，为部分状态码关联的重定向URL地址的示例。

状态码	重定向URL地址
		404	http://10.30.0.1
500	http://www.qq.com/ad/1.html
		……	……..

表2

步骤S206：将所述HTTP响应转发至客户端，结束当前流程。

如果所述HTTP响应所属的会话没有置位，则确定对所述第一HTTP请求识别失败，此时，将对应的HTTP响应转发至客户端，结束当前流程。

另外，如果负载均衡设备在所述状态码表中查找不到所述状态码，即所述HTTP响应携带的状态码在所述状态码表中没有对应的重定向URL地址，大部分情况下，说明所述HTTP响应是正常的，比如说成功，此时当然不需要进行重定向，则将HTTP响应返回给客户端，结束当前流程。

步骤S207：向客户端发送携带所述重定向URL地址的HTTP重定向，以使客户端发送第二HTTP请求访问所述重定向URL地址。

如果负载均衡设备在所述状态码表中查找到所述状态码，即所述HTTP响应携带的状态码在所述状态码表中有对应的重定向URL地址，通常说明HTTP响应存在问题，比如说状态码404以及500一般表示出错。此时通过步骤S207进行重定向处理，可以引导客户端通过发送第二HTTP请求来访问表2中各个重定向ULR地址所指向的预设页面，如前所述，这些预设页面可以改善用户的使用体验，另一方面也可以允许管理员向客户端推送更多的有用信息，请参考图2A与图2B的对比。

可选的，所述负载均衡设备向客户端发送携带所述重定向URL地址的HTTP重定向，可以以状态码为302，Location字段为该重定向URL地址的HTTP重定向发送至客户端，由于状态码为302的HTTP重定向属于临时重定向，也就是说下次客户端再访问上述第一HTTP请求携带的URL地址时，客户端浏览器不会以该重定向URL地址发起HTTP请求，而还是以之前访问的URL地址发起HTTP请求，例如，假设客户端访问http://10.30.8.100/a.htm，Web服务器向客户端返回状态码为301，重定向URL地址为http://10.30.0.1/red.htm的HTTP重定向时，客户端浏览器会缓冲该重定向URL地址，下次再访问上述URL地址时，客户端浏览器会直接以缓冲的重定向URL地址发起HTTP请求。

值得注意的是，在其他例子中，步骤S204和步骤S205的执行顺序是可以反过来的。也就是说可以先使用HTTP响应携带的状态码在状态码表中查找对应的重定向URL地址，如果查找到则继续查询识别是否成功。因此，在本申请中，步骤S204以及步骤S205可以理解为，在识别成功且HTTP响应携带的状态码在状态码表中有对应的重定向URL地址的情况下，负载均衡设备可以执行步骤S207的处理。

如前所述，识别条件的引入可以允许管理员将状态码重定向技术的应用限定在一定的范围内，这在很多实际应用中是具备比较好的技术优势的。举例来说，当客户端发送一个HTTP请求访问www.sina.com时，第一个HTTP请求对应的第一个HTTP响应通常只返回了一个主文件(也称为“资源”)，比如“新浪首页.htm”，这个主文件中只有部分可以直接使用的数据，比如一些文本数据以及页面布局的数据。这个HTTP响应中还携带了很多需要客户端浏览器再次发起HTTP请求的URL地址，这些URL地址通常为指向各种图片或其他多媒体资源的链接，客户端浏览器把这些资源都获取回来才能完成完整新浪首页的组装。

这也就是说第一个HTTP响应会要求客户端随后向很多个URL地址再次发起HTTP请求，因此在整个新浪首页的组装过程中可能要访问多到几十个甚至数百个HTTP请求。这些后续的HTTP请求通常是访问一些孤立的资源，而HTTP响应所携带的数据事实上是新浪页面上的某个特定位置上的某一个图片，如果这样的HTTP响应有问题，管理员可能也不希望其被重定向，如果重定向的话则可能出现新浪首页的某个面积很小位置上出现图2B所示的那样的界面；由于图片所占有的面积是固定的，重定向回来的图2B的页面可能无法在这样的面积上展示，造成展示异常，而且从内容本身来说，也可能会显得比较奇怪，影响用户体验。

从以上描述可以看出，设置的请求资源类型、目录级别数等识别条件可以将识别限定在管理员关注的页面，一般来说这种页面通常是主页面。因此，识别条件的引入可以允许管理员通过合理设置识别条件，一方面提升负载均衡设备的处理效率，另一方面避免影响用户体验。

在另一个例子中，本申请针对重定向过程可能引发的循环重定向提出合理优化措施。在步骤S207中，假设第二HTTP请求中携带的重定向URL地址是http://www.qq.com/ad/ 1.html，当该HTTP请求到达负载均衡设备时，此时在步骤S201，根据表1对该HTTP请求进行识别，结果将是识别成功。此时，如果服务器返回的第二HTTP响应出现问题，比如状态码500，其对应的URL重定向地址依然是http://www.qq.com/ad/1.html，此时流程又会流转到步骤S207，客户端再次因为接收到HTTP重定向而发送第三HTTP请求继续访问http:// www.qq.com/ad/1.html，这样一来就形成了死循环。为了避免这种极端情况的发生，本申请在另一个例子中对此进行优化。在配置表2的过程中，检查管理员在状态码表中配置的重定向URL地址是否满足识别条件；如果是，则将该重定向URL地址从识别条件中排除。此时表1可以更新为表3所示的示例。

表3

由上述实施例所述，负载均衡设备根据预先配置的识别条件对客户端发送的第一HTTP请求进行识别，对于满足识别条件的第一HTTP请求，如果其对应的HTTP响应出现问题，则负载均衡设备可以使用相应的重定向URL地址来引导客户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络中，尤其是数据中心中，负载均衡设备数量远远小于Web服务器的数量，因此可以极大简化状态码重定向的部署。

参见图3所示，为本申请根据一示例性实施例示出的另一种状态码重定向方法的实施例流程图，该实施例结合图1示出的应用场景对状态码重定向的过程进行详细描述，包括以下步骤：

步骤S301：客户端与负载均衡设备建立TCP连接。

步骤S302：客户端向负载均衡设备发送第一HTTP请求。

步骤S303：负载均衡设备根据预设的识别条件对所述第一HTTP请求进行识别。

负载均衡设备将所述第一HTTP请求与预设的识别条件进行比较，所述识别条件的配置如前所述，在此不再一一赘述。若所述第一HTTP请求满足预设的识别条件，则将所述第一HTTP请求所属的会话进行置位，否则不进行置位，按照既有的方式继续后续处理。

步骤S304：负载均衡设备与Web服务器建立TCP连接。

步骤S305：负载均衡设备将所述第一HTTP请求发送至Web服务器。

负载均衡设备对所述第一HTTP请求进行识别之后，将所述第一HTTP请求发送至Web服务器，以使所述Web服务器返回对应的HTTP响应。

步骤S306：Web服务器向负载均衡设备返回对应的HTTP响应。

步骤S307：负载均衡设备查询对所述第一HTTP请求的识别结果。

当负载均衡设备接收到所述Web服务器返回的HTTP响应时，查询所述HTTP响应所属会话的置位结果，如果会话被置位，则确定对所述第一HTTP请求识别成功，执行步骤S308，否则识别不成功，将所述HTTP响应发送至所述客户端，结束当前流程。

步骤S308：负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表中进行查找。

当负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表进行查找时，首先清除该HTTP响应所属会话的置位，具体查找过程，如前所述，在此不再一一赘述。若查找到所述状态码，则获取该状态码对应的重定向URL地址，执行步骤S309，若没有查找到所述状态码，则将所述HTTP响应发送至所述客户端，结束当前流程。

步骤S309：负载均衡设备向客户端返回携带所述重定向URL地址的HTTP重定向。

负载均衡设备从所述状态码表中获取所述状态码对应的重定向URL地址，以状态码为302、Location字段为所述重定向URL地址的HTTP重定向的方式发送至所述客户端。

步骤S310：负载均衡设备与Web服务器以RST结束连接。

当负载均衡设备将匹配到的状态码关联的重定向URL地址发送至所述客户端后，首先在TCP层与Web服务器以RST结束连接，防止Web服务器连续向负载均衡设备发送HTTP响应，该方式结束连接速度快，节省设备资源。而如果与客户端以RST结束连接，会导致客户端异常。

步骤S312：负载均衡设备与客户端以FIN结束连接。

步骤S313：客户端根据接收到的重定向URL地址通过负载均衡设备向所述Web服务器发送第二HTTP请求。

客户端根据所述重定向URL地址，通过负载均衡设备向Web服务器发送第二HTTP请求，访问所述重定向ULR地址所指向的预设页面。

需要说明的是，上述步骤S307与步骤S308的执行顺序可以倒过来执行，具体处理流程如前所述，在此不再一一赘述。。

由上述实施例所述，负载均衡设备根据预先配置的识别条件对客户端发送的第一HTTP请求进行识别，对于满足识别条件的第一HTTP请求，如果其对应的HTTP响应出现问题，则负载均衡设备可以使用相应的重定向URL地址来引导客户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络中，尤其是数据中心中，负载均衡设备数量远远小于Web服务器的数量，因此可以极大简化状态码重定向的部署。

与前述状态码重定向方法的实施例相对应，本申请还提供了状态码重定向装置的实施例。

本申请状态码重定向装置的实施例可以应用在负载均衡设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4示，为本申请根据一示例性实施例示出的一种状态码重定向装置所在设备的硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际技术，还可以包括其他硬件，对此不再赘述。

参见图5所示，为本申请根据一示例性实施例示出的一种状态码重定向装置的实施例框图，该实施例应用于负载均衡设备上，所述装置包括：识别单元510、转发单元520、接收单元530、处理单元540。

其中，识别单元510，用于根据预设的识别条件对客户端发送的第一HTTP请求进行识别；

转发单元520，用于将所述第一HTTP请求发送至Web服务器；

接收单元530，用于接收所述Web服务器针对第一HTTP请求返回的HTTP响应；

处理单元540，用于如果识别成功且所述HTTP响应所携带的状态码在预先配置的状态码表有对应的重定向URL地址时，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的重定向URL地址。

其中，所述识别单元中的识别条件包括以下子条件中的一种或者多种的组合：

i.URL地址目录级别数量小于预设数量；

ii.请求资源类型为预设的一种或多种类型；

iii.URL地址包括有指定的关键词。

在一个可选的实现方式中，所述装置还包括(图5中未示出)：

检查单元，用于检查管理员在状态码表中配置的重定向URL地址是否满足识别条件；如果是，则将该重定向URL地址从识别条件中排除。

在另一个可选的实现方式中，所述处理单元，还用于如果对所述第一HTTP请求识别失败，将所述对应的HTTP响应发送给所述客户端。

在另一个可选的实现方式中，所述处理单元，还用于如果所述HTTP响应携带的状态码在所述状态码表中没有对应的重定向URL地址，将所述对应的HTTP响应发送给所述客户端。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

由上述实施例可见，负载均衡设备根据预先配置的识别条件对客户端发送的第一HTTP请求进行识别，对于满足识别条件的第一HTTP请求，如果其对应的HTTP响应出现问题，则负载均衡设备可以使用相应的重定向URL地址来引导客户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络中，尤其是数据中心中，负载均衡设备数量远远小于Web服务器的数量，因此可以极大简化状态码重定向的部署。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种状态码重定向方法，所述方法应用于位于客户端和Web服务器之间的负载均衡设备上，其特征在于，所述方法包括：

根据预设的识别条件对客户端发送的第一超文本传输协议HTTP请求进行识别；所述识别条件用于筛选需要在HTTP响应出现问题时进行重定向处理的HTTP；

将所述第一HTTP请求发送至Web服务器；

接收所述Web服务器针对第一HTTP请求返回的HTTP响应；

如果识别成功且所述HTTP响应携带的状态码在预先配置的状态码表有对应的重定向统一资源定位符URL地址，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的重定向URL地址。

2.根据权利要求1所述的方法，其特征在于，所述识别条件包括以下子条件中的一种或者多种的组合：

i.URL地址目录级别数量小于预设数量；

ii.请求资源类型为预设的一种或多种类型；

iii.URL地址包括有指定的关键词。

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

检查管理员在状态码表中配置的重定向URL地址是否满足识别条件；如果是，则将该重定向URL地址从识别条件中排除。

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

如果对所述第一HTTP请求识别失败，将所述对应的HTTP响应发送给所述客户端。

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

如果所述HTTP响应携带的状态码在所述状态码表中没有对应的重定向URL地址，将所述对应的HTTP响应发送给所述客户端。

6.一种状态码重定向的装置，所述装置应用于位于客户端和Web服务器之间的负载均衡设备上，其特征在于，所述装置包括：

识别单元，用于根据预设的识别条件对客户端发送的第一HTTP请求进行识别；所述识别条件用于筛选需要在HTTP响应出现问题时进行重定向处理的HTTP；

转发单元，用于将所述第一HTTP请求发送至Web服务器；

接收单元，用于接收所述Web服务器针对第一HTTP请求返回的HTTP响应；

处理单元，用于如果识别成功且所述HTTP响应携带的状态码在预先配置的状态码表有对应的重定向URL地址，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的重定向URL地址。

7.根据权利要求6所述的装置，其特征在于，所述识别单元中的识别条件包括以下子条件中的一种或者多种的组合：

i.URL地址目录级别数量小于预设数量；

ii.请求资源类型为预设的一种或多种类型；

iii.URL地址包括有指定的关键词。

8.根据权利要求6所述的装置，其特征在于，所述装置，还包括：

检查单元，用于检查管理员在状态码表中配置的重定向URL地址是否满足识别条件；如果是，则将该重定向URL地址从识别条件中排除。

9.根据权利要求6所述的装置，其特征在于，所述处理单元还用于如果对所述第一HTTP请求识别失败，将所述对应的HTTP响应发送给所述客户端。

10.根据权利要求6所述的装置，其特征在于，所述处理单元还用于如果所述HTTP响应携带的状态码在所述状态码表中没有对应的重定向URL地址，将所述对应的HTTP响应发送给所述客户端。