状态码重定向方法及装置的制造方法

状态码重定向方法及装置的制造方法
【专利摘要】本申请提供一种状态码重定向方法及装置，所述方法应用于负载均衡设备上，所述方法包括：根据预设的识别条件对客户端发送的第一HTTP请求进行识别；将所述第一HTTP请求发送至Web服务器；接收所述Web服务器针对第一HTTP请求返回的HTTP响应；如果识别成功且所述HTTP响应携带的状态码在预先配置的状态码表有对应的重定向URL地址，则向所述客户端发送携带该重定向URL地址的HTTP重定向，以使所述客户端针对该重定向URL地址发送第二HTTP请求。应用本申请实施例，通过负载均衡设备取代Web服务器实现状态码重定向技术，可以极大简化状态码重定向的部署。
【专利说明】
状态码重定向方法及装置
技术领域
[0001] 本申请设及网络通信技术领域，尤其设及一种状态码重定向方法及装置。
【背景技术】
[0002] HTTP (Hyper Text Transfer Protocol,超文本传输协议）协议是互联网上应用 最为广泛的一种网络传输协议。Web服务器根据客户端发送的HTTP请求返回HTTP响应， 而HTTP响应携带的状态码是用W表示Web服务器HTTP响应状态的=位数字代码，所述状 态码的第一个数字代表了 HTTP响应的状态，所述HTTP响应的状态包括消息（IX X)、成功 (2XX)、重定向（3XX)、客户端请求错误（4XX)、Web服务器错误巧XX)。在相关技术 中，利用状态码重定向技术对所述HTTP响应的状态码进行控制，W重新定制状态码，从而 实现客户端请求的目标网页跳转。请参考图2A，当Web服务器返回的HTTP响应的状态码为 404时，表示客户端发送的HTTP请求错误，此时页面显示乱码，运会影响到用户体验。请参 考图2B，通过状态码重定向技术可W改善用户体验，此时将客户端请求的目标网页被重定 向至一个预设网页，该预设网页不再是乱码，运一方面可W提升用户体验，另一方面可W允 许Web服务提供者在预设网页上推送一些有益的信息，比如热点新闻或公益广告等。
[0003] 但是，现有的状态码重定向技术是通过在Web服务器（也就是提供Web服务的服 务器上）上配置实现，一方面，该实现方式需要Web服务器软件平台的支持，不易于Web服 务器的扩展和维护，并且复用性也差，导致Web服务器集群难W同时实现对状态码重定向 技术的支持；另一方面，如果要实现Web服务器集群或者说大量Web服务器同时支持该技 术，则需要付出极高的管理和维护成本。

【发明内容】

[0004] 有鉴于此，本申请提供一种状态码重定向方法及装置，W解决现有技术中，通过在 Web服务器上配置实现状态码重定向技术，导致不易于对Web服务器进行扩展和维护，并且 难W实现Web服务器集群对状态码重定向技术支持的问题。 阳0化]根据本申请实施例的第一方面，提供一种状态码重定向方法，所述方法应用于分 别与客户端和Web服务器相连的负载均衡设备上，所述方法包括：
[0006] 根据预设的识别条件对客户端发送的第一 HTTP请求进行识别；
[0007] 将所述第一 HTTP请求发送至Web服务器；
[0008] 接收所述Web服务器针对第一 HTTP请求返回的HTTP响应；
[0009] 如果识别成功且所述HTTP响应所携带的状态码在预先配置的状态码表有对应的 重定向U化地址时，则向所述客户端发送携带该重定向U化地址的HTTP重定向，W使所述 客户端针对该重定向U化地址发送第二HTTP请求，其中所述状态码表包括状态码和对应的 重定向U化地址。
[0010] 根据本申请实施例的第二方面，提供一种状态码重定向装置，所述方法应用于分 别与客户端和Web服务器相连的负载均衡设备上，所述装置包括：
[0011] 识别单元，用于根据预设的识别条件对客户端发送的第一 HTTP请求进行识别；
[0012] 转发单元，用于将所述第一 HTTP请求发送至Web服务器；
[0013] 接收单元，用于接收所述Web服务器针对第一 HTTP请求返回的HTTP响应；
[0014] 处理单元，用于如果识别成功且所述HTTP响应所携带的状态码在预先配置的状 态码表有对应的重定向U化地址时，则向所述客户端发送携带该重定向U化地址的HTTP重 定向，W使所述客户端针对该重定向U化地址发送第二HTTP请求，其中所述状态码表包括 状态码和对应的重定向U化地址。
[0015] 应用本申请实施例，负载均衡设备根据预先配置的识别条件对客户端发送的第一 HTTP请求进行识别，对于满足识别条件的第一 HTTP请求，如果其对应的HTTP响应出现问 题，则负载均衡设备可W使用相应的重定向U化地址来引导客户端重新访问预设的页面。 通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络 中，尤其是数据中屯、中，负载均衡设备数量远远小于Web服务器的数量，因此可W极大简化 状态码重定向的部署。
【附图说明】
[0016] 图1为本申请根据一示例性实施例示出的状态码重定向的典型应用场景示意图；
[0017] 图2为本申请根据一示例性实施例示出的一种状态码重定向方法的实施例流程 图；
[0018] 图2A为本申请根据一示例性实施例示出的一种状态码重定向方法中的状态码为 404时客户端显示的网页示意图；
[0019] 图2B为本申请根据一示例性实施例示出的一种状态码重定向方法中的状态码重 定向后客户端显示的网页示意图；
[0020] 图3为本申请根据一示例性实施例示出的另一种状态码重定向方法的实施例流 程图；
[0021] 图4为本申请根据一示例性实施例示出的一种状态码重定向装置所在设备的硬 件结构图；
[0022] 图5为本申请根据一示例性实施例示出的一种状态码重定向装置的实施例框图。
【具体实施方式】
[0023] 为了使本技术领域的人员更好地理解本申请实施例中的技术方案，并使本申请实 施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方 案作进一步详细的说明。
[0024] 现有的状态码重定向技术在Web服务器中实现，当Web服务器根据客户端发送的 HTTP请求生成HTTP响应时，Web服务器将所述HTTP响应的状态码与预先配置的状态码重 定向表进行匹配，如果匹配到所述状态码（比如404)，则将状态码重定向表中所述状态码 对应的重定向U化地址，W状态码为301或302的HTTP重定向方式发送至客户端，如果未 匹配到所述状态码，则将所述HTTP响应返回至客户端。由此可见，当一个数据中屯、或者Web 服务器集群中增加一个新的Web服务器，其势必要进行状态码重定向技术的部署，增加管 理员的管理难度。再者如果状态码重定向软件进行升级，比如说需要更新重定向U化地址 时，则需要对所有的Web服务器都进行配置，同样会增加管理操作的成本，运样的实现方式 不利于Web服务器的扩展和维护。
[00巧]本申请从全新的思路来改进状态码重定向技术在多Web服务器环境下的实现W 解决上述技术问题。参见图1所示，为本申请一个典型的实施例应用场景示意图。该应用 场景中包括客户端、Web服务器W及位于客户端与Web服务器之间的负载均衡设备。其中， 客户端可W是手机、笔记本、台式机等；负载均衡设备位于多个Web服务器的前端，负责将 客户端发起的HTTP请求分发给后端的Web服务器进行处理。在本申请一个例子中，负载均 衡设备根据预先配置的识别条件对HTTP请求进行识别，对于满足识别条件的HTTP请求，如 果其对应的HTTP响应出现问题，则负载均衡设备可W使用相应的重定向U化地址来促使客 户端重新访问预设的页面。通过改进负载均衡设备的实现进而取代Web服务器实现状态码 重定向技术。由于大型网络中，尤其是数据中屯、中，负载均衡设备数量远远小于Web服务器 的数量，因此可W极大简化状态码重定向的部署。
[00%] 参见图2所示，在一个例子中，本申请提供的一种状态码重定向方法的实施例流 程图，该方法应用于负载均衡设备上，包括W下步骤：
[0027] 步骤S201 :根据预设的识别条件对客户端发送的第一 HTTP请求进行识别。
[0028] 客户端在发送第一 HTTP请求之前，会尝试与远端的Web服务器建立TCP连接，一 般来说，在有负载均衡设备的组网中，负载均衡设备会负责与客户端建立TCP连接。在TCP 连接建立成功后，负载均衡设备会接收到客户端发送的第一 HTTP请求，在一种可选的实现 方式中，所述负载均衡设备通过预设的识别条件，对所述第一 HTTP请求进行识别。运一识 别过程可W理解为有选择地进行处理。如前所述，当HTTP请求所对应的HTTP响应出现问 题的时候，负载均衡设备需要进行重定向处理。然而对于管理员来说，并非所有HTTP响应 出现问题都有必要进行重定向处理。W下先介绍识别条件的具体示例，在后续步骤中再对 识别条件所带来的技术优势进行解释。
[0029] 在一个例子中，所述预先配置的识别条件可W包括W下子条件中的一种或多种的 组合。
[0030] i. U化地址目录级别数量小于预设数量；
[0031] ii.请求资源类型为预设的一种或多种类型；
[0032] iii. U化地址包括有指定的关键词。
[003引 W条件i W及条件ii为例，在具体的开发中，可W使用查表的方式来实现识别，当 然本申请并不排除其他实现方式。请参考表1所示，其包含了 HTTP请求的U化地址目录级 别数小于等于4、请求资源类型W . htm或.html后缀结尾运两个子条件。在运个例子中，两 个子条件是组合使用的，两者之间的关系可W是与的关系，也就是说两个子条件都满足才 算识别成功。一般来说，识别条件通常是管理员配置的。在其他例子中，上述两个子条件之 间的关系可W是或的关系，对此本申请并不限定。一般来说，客户端发送的HTTP请求携带 的U化地址目录级别数越小越利于服务器解析，通常情况下，建议管理员设置U化地址目录 级别数不超过3或4,而且大部分网站页面的主文件资源类型W . htm或.html后缀结尾。 [0034]
[0035] 表1
[0036] 根据上述识别条件，负载均衡设备获取所述第一 HTTP请求的U化地址目录级别 数和请求资源类型，如果获取到的U化地址目录级别数和请求资源类型均满足对应的子 条件，则可W对所述第一 HTTP请求所属的会话进行置位表明识别成功，否则表明识别不成 功，按照既有的方式继续后续处理即可。
[0037] 步骤S202 :向Web服务器发送所述第一 HTTP请求。
[0038] 当所述第一 HTTP请求经过识别之后，负载均衡设备可W与所述Web服务器建立 TCP连接，将所述第一 HTTP请求发送至所述Web服务器，W使所述Web服务器返回HTTP响 应。一般来说，负载均衡设备可W根据预设的负载均衡算法将大量的HTTP请求分发到不同 的Web服务器上进行处理，运些Web服务器通常可W处理相同的业务服务。
[0039] 步骤S203 :接收Web服务器返回的HTTP响应。
[0040] Web服务器接收到所述负载均衡设备发送的第一 HTTP请求之后，根据所述第一 HTTP请求访问的网页资源向负载均衡设备返回HTTP响应。
[0041] 步骤S204 :查询对所述第一 HTTP请求是否识别成功，若识别成功，则执行步骤 S205,否则执行步骤S206。
[0042] 当负载均衡设备接收到所述Web服务器返回的HTTP响应时，可W先查询通过前述 会话的置位确定识别结果，如果识别成功，则确定对所述第一 HTTP请求识别成功，执行步 骤S205,否则执行步骤S206。
[0043] 步骤S205 :根据所述HTTP响应的状态码在预先配置的状态码表中进行查找，若查 找到所述状态码，则执行步骤S207,否则执行步骤S206。
[0044] 当负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表进行查找 时，可W先清除该HTTP响应所属会话的置位，若在所述状态码表中查找到所述状态码，贝U 获取该状态码对应的重定向U化地址，执行步骤S207,若没有查找到所述状态码，则执行步 骤 S206。
[0045] 在一种可选的实现方式中，负载均衡设备可W先使用AC(Ak) and Corasick,多模 式匹配算法）算法查找HTTP响应中携带的状态码。一般来说，所述HTTP响应携带的状态 码位于HTTP响应的头部，因此可W从所述HTTP响应头部的起始位置开始解析，查找到所述 HTTP响应头部的结束位置，一般结束的标识为\r\n\r\n。然后根据查找到的状态码在预先 配置的状态码表中查找对应的重定向U化，所述状态码表可W包括状态码和状态码对应的 重定向U化地址，如表2所示，为部分状态码关联的重定向U化地址的示例。
[0046]
[0047] 表 2
[0048] 步骤S206 :将所述HTTP响应转发至客户端，结束当前流程。
[0049] 如果所述HTTP响应所属的会话没有置位，则确定对所述第一 HTTP请求识别失败， 此时，将对应的HTTP响应转发至客户端，结束当前流程。
[0050] 另外，如果负载均衡设备在所述状态码表中查找不到所述状态码，即所述HTTP响 应携带的状态码在所述状态码表中没有对应的重定向U化地址，大部分情况下，说明所述 HTTP响应是正常的，比如说成功，此时当然不需要进行重定向，则将HTTP响应返回给客户 端，结束当前流程。
[0051] 步骤S207 :向客户端发送携带所述重定向U化地址的HTTP重定向，W使客户端发 送第二HTTP请求访问所述重定向U化地址。
[0052] 如果负载均衡设备在所述状态码表中查找到所述状态码，即所述HTTP响应携带 的状态码在所述状态码表中有对应的重定向U化地址，通常说明HTTP响应存在问题，比如 说状态码404 W及500 -般表示出错。此时通过步骤S207进行重定向处理，可W引导客户 端通过发送第二HTTP请求来访问表2中各个重定向ULR地址所指向的预设页面，如前所 述，运些预设页面可W改善用户的使用体验，另一方面也可W允许管理员向客户端推送更 多的有用信息，请参考图2A与图2B的对比。
[0053] 可选的，所述负载均衡设备向客户端发送携带所述重定向U化地址的HTTP重定 向，可W W状态码为302, Location字段为该重定向U化地址的HTTP重定向发送至客户 端，由于状态码为302的HTTP重定向属于临时重定向，也就是说下次客户端再访问上述第 一 HTTP请求携带的U化地址时，客户端浏览器不会W该重定向U化地址发起HTTP请求，而 还是W之前访问的U化地址发起HTTP请求，例如，假设客户端访问http://10. 30. 8. 100/ a. htm，Web服务器向客户端返回状态码为301，重定向U化地址为http ://!0. 30. 0. 1/red. 边的HTTP重定向时，客户端浏览器会缓冲该重定向U化地址，下次再访问上述U化地址 时，客户端浏览器会直接W缓冲的重定向U化地址发起HTTP请求。
[0054] 值得注意的是，在其他例子中，步骤S204和步骤S205的执行顺序是可W反过来 的。也就是说可W先使用HTTP响应携带的状态码在状态码表中查找对应的重定向U化地 址，如果查找到则继续查询识别是否成功。因此，在本申请中，步骤S204 W及步骤S205可 W理解为，在识别成功且HTTP响应携带的状态码在状态码表中有对应的重定向U化地址的 情况下，负载均衡设备可W执行步骤S207的处理。 阳化5] 如前所述，识别条件的引入可W允许管理员将状态码重定向技术的应用限定在一 定的范围内，运在很多实际应用中是具备比较好的技术优势的。举例来说，当客户端发送一 个HTTP请求访问丽W. Sina. com时，第一个HTTP请求对应的第一个HTTP响应通常只返回 了一个主文件（也称为"资源"），比如"新浪首页.htm"，运个主文件中只有部分可W直接 使用的数据，比如一些文本数据W及页面布局的数据。运个HTTP响应中还携带了很多需要 客户端浏览器再次发起HTTP请求的U化地址，运些U化地址通常为指向各种图片或其他多 媒体资源的链接，客户端浏览器把运些资源都获取回来才能完成完整新浪首页的组装。 [0056] 运也就是说第一个HTTP响应会要求客户端随后向很多个U化地址再次发起HTTP 请求，因此在整个新浪首页的组装过程中可能要访问多到几十个甚至数百个HTTP请求。运 些后续的HTTP请求通常是访问一些孤立的资源，而HTTP响应所携带的数据事实上是新浪 页面上的某个特定位置上的某一个图片，如果运样的HTTP响应有问题，管理员可能也不希 望其被重定向，如果重定向的话则可能出现新浪首页的某个面积很小位置上出现图2B所 示的那样的界面；由于图片所占有的面积是固定的，重定向回来的图2B的页面可能无法在 运样的面积上展示，造成展示异常，而且从内容本身来说，也可能会显得比较奇怪，影响用 户体验。
[0057] 从W上描述可W看出，设置的请求资源类型、目录级别数等识别条件可W将识别 限定在管理员关注的页面，一般来说运种页面通常是主页面。因此，识别条件的引入可W允 许管理员通过合理设置识别条件，一方面提升负载均衡设备的处理效率，另一方面避免影 响用户体验。
[0058] 在另一个例子中，本申请针对重定向过程可能引发的循环重定向提出合理优化措 施。在步骤S207中，假设第二HTTP请求中携带的重定向册L化化是http: //www.日日.com/ ad/l.html,当该HTTP请求到达负载均衡设备时，此时在步骤S201，根据表1对该HTTP请 求进行识别，结果将是识别成功。此时，如果服务器返回的第二HTTP响应出现问题，比如 状态码500,其对应的册L重定向地址依然是http://www. gg. com/ad/1. html,此时流程又 会流转到步骤S207,客户端再次因为接收到HTTP重定向而发送第S HTTP请求继续访问http://www. gg. com/ad/1. html,运样一来就形成了死循环。为了避免运种极端情况的发 生，本申请在另一个例子中对此进行优化。在配置表2的过程中，检查管理员在状态码表中 配置的重定向U化地址是否满足识别条件；如果是，则将该重定向U化地址从识别条件中排 除。此时表1可W更新为表3所示的示例。
[0059]
[0060]
[0061] 表 3
[0062] 由上述实施例所述，负载均衡设备根据预先配置的识别条件对客户端发送的第一 HTTP请求进行识别，对于满足识别条件的第一 HTTP请求，如果其对应的HTTP响应出现问 题，则负载均衡设备可W使用相应的重定向U化地址来引导客户端重新访问预设的页面。 通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络 中，尤其是数据中屯、中，负载均衡设备数量远远小于Web服务器的数量，因此可W极大简化 状态码重定向的部署。
[0063] 参见图3所示，为本申请根据一示例性实施例示出的另一种状态码重定向方法的 实施例流程图，该实施例结合图1示出的应用场景对状态码重定向的过程进行详细描述， 包括W下步骤： 阳064] 步骤S301 :客户端与负载均衡设备建立TCP连接。 阳0化]步骤S302 :客户端向负载均衡设备发送第一 HTTP请求。
[0066] 步骤S303 :负载均衡设备根据预设的识别条件对所述第一 HTTP请求进行识别。
[0067] 负载均衡设备将所述第一 HTTP请求与预设的识别条件进行比较，所述识别条件 的配置如前所述，在此不再一一寶述。若所述第一 HTTP请求满足预设的识别条件，则将所 述第一 HTTP请求所属的会话进行置位，否则不进行置位，按照既有的方式继续后续处理。
[0068] 步骤S304 :负载均衡设备与Web服务器建立TCP连接。
[0069] 步骤S305 :负载均衡设备将所述第一 HTTP请求发送至Web服务器。
[0070] 负载均衡设备对所述第一 HTTP请求进行识别之后，将所述第一 HTTP请求发送至 Web服务器，W使所述Web服务器返回对应的HTTP响应。
[0071] 步骤S306 :Web服务器向负载均衡设备返回对应的HTTP响应。 阳072] 步骤S307 :负载均衡设备查询对所述第一 HTTP请求的识别结果。
[0073] 当负载均衡设备接收到所述Web服务器返回的HTTP响应时，查询所述HTTP响应 所属会话的置位结果，如果会话被置位，则确定对所述第一 HTTP请求识别成功，执行步骤 S308,否则识别不成功，将所述HTTP响应发送至所述客户端，结束当前流程。
[0074] 步骤S308 :负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表中 进行查找。
[0075] 当负载均衡设备根据所述HTTP响应的状态码在预先配置的状态码表进行查找 时，首先清除该HTTP响应所属会话的置位，具体查找过程，如前所述，在此不再一一寶述。 若查找到所述状态码，则获取该状态码对应的重定向U化地址，执行步骤S309,若没有查找 到所述状态码，则将所述HTTP响应发送至所述客户端，结束当前流程。 阳076] 步骤S309 :负载均衡设备向客户端返回携带所述重定向U化地址的HTTP重定向。
[0077] 负载均衡设备从所述状态码表中获取所述状态码对应的重定向U化地址，W状态 码为302、Location字段为所述重定向U化地址的HTTP重定向的方式发送至所述客户端。
[0078] 步骤S310 :负载均衡设备与Web服务器W RST结束连接。
[0079] 当负载均衡设备将匹配到的状态码关联的重定向U化地址发送至所述客户端后， 首先在TCP层与Web服务器W RST结束连接，防止Web服务器连续向负载均衡设备发送HTTP 响应，该方式结束连接速度快，节省设备资源。而如果与客户端W RST结束连接，会导致客 户端异常。
[0080] 步骤S312 :负载均衡设备与客户端W FIN结束连接。
[0081] 步骤S313 :客户端根据接收到的重定向U化地址通过负载均衡设备向所述Web服 务器发送第二HTTP请求。
[0082] 客户端根据所述重定向U化地址，通过负载均衡设备向Web服务器发送第二HTTP 请求，访问所述重定向ULR地址所指向的预设页面。
[0083] 需要说明的是，上述步骤S307与步骤S308的执行顺序可W倒过来执行，具体处理 流程如前所述，在此不再一一寶述。。
[0084] 由上述实施例所述，负载均衡设备根据预先配置的识别条件对客户端发送的第一 HTTP请求进行识别，对于满足识别条件的第一 HTTP请求，如果其对应的HTTP响应出现问 题，则负载均衡设备可W使用相应的重定向U化地址来引导客户端重新访问预设的页面。 通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络 中，尤其是数据中屯、中，负载均衡设备数量远远小于Web服务器的数量，因此可W极大简化 状态码重定向的部署。
[00化]与前述状态码重定向方法的实施例相对应，本申请还提供了状态码重定向装置的 实施例。
[0086] 本申请状态码重定向装置的实施例可W应用在负载均衡设备上。装置实施例可W 通过软件实现，也可W通过硬件或者软硬件结合的方式实现。W软件实现为例，作为一个逻 辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令 读取到内存中运行形成的。从硬件层面而言，如图4示，为本申请根据一示例性实施例示 出的一种状态码重定向装置所在设备的硬件结构图，除了图4所示的处理器、内存、网络接 口、W及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际技术，还可 W包括其他硬件，对此不再寶述。
[0087] 参见图5所示，为本申请根据一示例性实施例示出的一种状态码重定向装置的实 施例框图，该实施例应用于负载均衡设备上，所述装置包括：识别单元510、转发单元520、 接收单元530、处理单元540。
[0088] 其中，识别单元510,用于根据预设的识别条件对客户端发送的第一 HTTP请求进 行识别；
[0089] 转发单元520,用于将所述第一 HTTP请求发送至Web服务器；
[0090] 接收单元530，用于接收所述Web服务器针对第一 HTTP请求返回的HTTP响应；
[0091] 处理单元540,用于如果识别成功且所述HTTP响应所携带的状态码在预先配置的 状态码表有对应的重定向U化地址时，则向所述客户端发送携带该重定向U化地址的HTTP 重定向，W使所述客户端针对该重定向U化地址发送第二HTTP请求，其中所述状态码表包 括状态码和对应的重定向U化地址。
[0092] 其中，所述识别单元中的识别条件包括W下子条件中的一种或者多种的组合：
[0093] i. U化地址目录级别数量小于预设数量；
[0094] ii.请求资源类型为预设的一种或多种类型；
[0095] iii. U化地址包括有指定的关键词。
[0096] 在一个可选的实现方式中，所述装置还包括（图5中未示出）：
[0097] 检查单元，用于检查管理员在状态码表中配置的重定向U化地址是否满足识别条 件；如果是，则将该重定向U化地址从识别条件中排除。
[0098] 在另一个可选的实现方式中，所述处理单元，还用于如果对所述第一 HTTP请求识 别失败，将所述对应的HTTP响应发送给所述客户端。
[0099] 在另一个可选的实现方式中，所述处理单元，还用于如果所述HTTP响应携带的状 态码在所述状态码表中没有对应的重定向U化地址，将所述对应的HTTP响应发送给所述客 户端。
[0100] 上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的 实现过程，在此不再寶述。 阳101] 对于装置实施例而言，由于其基本对应于方法实施例，所W相关之处参见方法实 施例的部分说明即可。W上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件 说明的单元可W是或者也可W不是物理上分开的，作为单元显示的部件可W是或者也可W 不是物理单元，即可W位于一个地方，或者也可W分布到多个网络单元上。可W根据实际的 需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付 出创造性劳动的情况下，即可W理解并实施。 阳102] 由上述实施例可见，负载均衡设备根据预先配置的识别条件对客户端发送的第一 HTTP请求进行识别，对于满足识别条件的第一 HTTP请求，如果其对应的HTTP响应出现问 题，则负载均衡设备可W使用相应的重定向U化地址来引导客户端重新访问预设的页面。 通过改进负载均衡设备的实现进而取代Web服务器实现状态码重定向技术。由于大型网络 中，尤其是数据中屯、中，负载均衡设备数量远远小于Web服务器的数量，因此可W极大简化 状态码重定向的部署。 阳103] W上所述仅为本申请的较佳实施例而已，并不用W限制本申请，凡在本申请的精 神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。
【主权项】
1. 一种状态码重定向方法，所述方法应用于位于客户端和Web服务器之间的负载均衡 设备上，其特征在于，所述方法包括： 根据预设的识别条件对客户端发送的第一超文本传输协议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请求发送至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响应发送 给所述客户端。
【文档编号】H04L29/06GK105939313SQ201510552450
【公开日】2016年9月14日
【申请日】2015年9月1日
【发明人】刘勤龙
【申请人】杭州迪普科技有限公司