CN104811383A - 一种报文转发方法和设备 - Google Patents

Abstract

本申请实施例公开了一种报文转发方法和设备，通过应用本申请实施例所提出的技术方案，在负载均衡网络的VIP和各服务器的RIP一致的基础上，基于报文VIP与MIP的修改和复原，实现报文在负载均衡网络中的转发，从而，解决了现有技术方案中NAT模式要求性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题。

Description

一种报文转发方法和设备

技术领域

本发明涉及通信技术领域，特别涉及一种报文转发方法和设备。

背景技术

负载均衡(Load Balance)建立在现有网络结构之上，提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

现有的负载均衡架构中一般包含一或两台负载均衡设备(Load Balancer，LB)对外提供VIP(Virtual IP，虚拟IP)作为提供服务的地址。在LB设备后端挂有多台物理机或者虚拟机。当LB设备收到一个应用请求时，会根据一定算法，将请求重定向到某台后端物理机或者虚拟机，来真正提供服务。

如图1A和图1B所示，分别为现有技术中串联模式组网的负载均衡架构和旁挂模式组网的负载均衡架构的结构示意图。

无论是哪一种应用场景，当其中的LB设备根据一定算法选定后端服务器后，LB设备将用户发送过来的请求报文按照NAT(Network Address Translation,网络地址转换)方式/Full NAT方式转发给后端服务器。

LB设备按照RFC(Request For Comments，是一系列以编号排定的文件)标准，对转发到后端服务器的报文地址及报文内部的TCP(Transmission Control Protocol，传输控制协议)或者UDP(User Datagram Protocol，用户数据包协议)端口号进行转换。转换后的目的地址为后端服务器的实际地址。如果采用Full NAT方式，发送到服务器的报文转换后的源地址则转换为LB设备的地址。如果采用普通NAT方式，则发送到服务器的报文源地址为原始地址，不进行转换。后端服务器直接处理转换后的报文，并给出回应报文。回应报文的源地址为后端服务器的地址。回应报文必须要经过LB设备，以便LB 设备能够将报文地址和端口号转换为原始报文及端口号，发送给真正的客户端。

在实现本申请的过程中，发明人发现现有技术至少存在以下问题：

对于NAT方式/Full NAT方式，考虑到有些协议报文，除了在报文头中包含地址和端口信息外，在报文内容也包含有相关信息。因此，在LB设备对报文进行转换过程中，需要识别相关报文，并对报文内容进行处理。这会较大的影响LB设备的性能。而且由于转发回程报文也必须要经过LB设备，将报文转换为原始的地址和端口。这对LB设备的性能会产生进一步的影响，而且会限制组网，无法实现报文的高效转发。

发明内容

本申请实施例提供一种报文转发方法和设备，解决现有方案中NAT模式性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题。

为达到上述目的，本申请实施例一方面提供了一种报文转发方法，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述方法包括：

当一台服务器接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，所述服务器根据所述管理IP地址与所述虚拟IP地址的对应关系，通过自身所包括的代理模块将所述报文的目的地址修改为所述虚拟IP地址；

所述服务器对目的地址修改后的报文进行处理。

另一方面，本申请实施例还提供了一种服务器，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，所述服务器包括：

通信模块，用于接收所述负载均衡设备所发送的报文；

代理模块，用于当所述通信模块接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述报文的目的地址修改为所述虚拟IP地址；

处理模块，用于对目的地址经所述代理模块修改后的报文进行处理。

另一方面，本申请实施例还提供了一种报文转发方法，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述方法包括：

当所述负载均衡设备接收到客户端发送的目的地址为所述虚拟IP地址的报文时，所述负载均衡设备根据负载均衡策略和各服务器的管理IP地址，在所述多个服务器中选择处理所述报文的目的服务器；

所述负载均衡设备将所述报文的目的地址修改为所述目的服务器所对应的管理IP地址；

所述负载均衡设备将目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

另一方面，本申请实施例还提供了一种负载均衡设备，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述负载均衡设备包括：

接收模块，用于接收客户端或各所述服务器所发送的报文；

决策模块，用于当所述接收模块接收到客户端发送的目的地址为所述虚拟IP地址的报文时，根据负载均衡策略和各服务器的管理IP地址，在所述多 个服务器中选择处理所述报文的目的服务器；

地址修改模块，用于将所述接收模块所接收的所述报文的目的地址修改为所述决策模块所选择的目的服务器所对应的管理IP地址；

发送模块，用于将所述地址修改模块进行目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例所提出的技术方案，在负载均衡网络的VIP和各服务器的RIP一致的基础上，无需对报文的内容进行识别，只需要在报文头报文VIP与MIP的修改和复原，实现报文在负载均衡网络中的转发，从而，解决了现有技术方案中NAT模式要求性能及往返路径必须一致，限制组网，无法实现报文的高效转发的问题。

附图说明

图1A为现有技术中串联模式组网的负载均衡架构的结构示意图；

图1B为现有技术中旁挂模式组网的负载均衡架构的结构示意图；

图2为本申请实施例所提出的一种报文转发方法的流程示意图；

图3为本申请实施例所提出的一种报文转发方法在负载均衡设备侧的流程示意图；

图4为本申请实施例一所提出的一种具体应用场景中的报文转发方法的流程示意图；

图5为本申请实施例一所提出的一种报文转发方法在一种反馈场景下的流程示意图；

图6为本申请实施例一所提出的一种报文转发方法在另一种反馈场景下的流程示意图；

图7为本申请实施例二所提出的一种具体应用场景中的报文转发方法的流程示意图；

图8为本申请实施例二所提出的一种报文转发方法在一种反馈场景下的流程示意图

图9为本申请实施例二所提出的一种报文转发方法在另一种反馈场景下的流程示意图

图10为本申请实施例所提出的一种服务器的结构示意图；

图11为本申请实施例所提出的一种服务器在一种具体应用场景下的结构示意图；

图12为本申请实施例所提出的一种服务器在另一种具体应用场景下的结构示意图；

图13为本申请实施例所提出的一种服务器在另一种具体应用场景下的结构示意图；

图14为本申请实施例所提出的一种负载均衡设备的结构示意图。

具体实施方式

为了解决现有方案中NAT模式性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题，本申请提出了一种报文转发方法，在负载均衡网络的VIP和各服务器的RIP一致的基础上，基于报文VIP的修改，实现报文在负载均衡网络中的转发。

如图2所示，为本申请实施例所提出的一种报文转发方法的流程示意图，该方法应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块。

该方法具体包括以下步骤：

步骤S201、当一台服务器接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，所述服务器根据所述管理IP地址与所述虚拟IP地址的对应关系，通过自身所包括的代理模块将所述报文的目的地址修改为所述虚拟IP地址。

在具体的应用场景中，管理IP地址与虚拟IP地址的对应关系，具体通过以下方式生成：

服务器接收携带管理IP地址与虚拟IP地址的对应关系信息的配置消息，在服务器本地和/或代理模块中生成管理IP地址与虚拟IP地址的对应关系；或，

服务器通过代理模块与负载均衡设备协商，确定管理IP地址与虚拟IP地址的对应关系，并保存在服务器本地和/或代理模块中。

在具体的应用场景中，可以根据实际需要确定采用上述的哪种方式，无论是哪种方式，只要能够为服务器和代理模块提供管理IP地址与虚拟IP地址的对应关系，就不会影响本申请的保护范围。

在后续的操作过程中，考虑到代理模块对上述对应模块的应用，需要说明的是：

如果上述对应关系保存在服务器本地，则代理模块需要从服务器中读取上述的对应关系，这样的处理可以节约代理模块本地的存储资源；

而如果上述对应关系保存在代理模块中，则代理模块可以直接进行读取和使用，这样的处理可以缩短信息获取的流程，简化操作过程，提高响应速度。

步骤S202、所述服务器对目的地址修改后的报文进行处理。

需要说明的是，在本步骤的服务器对报文处理完成之后，如果生成了生成源地址为所述虚拟IP地址的响应报文，则根据转发方式的差异，对于响应报文的处理过程可以包括两种方式：

方式一、直接发送源地址为虚拟IP地址的响应报文，不进行地址转换。

在此方式下，所述服务器在生成源地址为所述虚拟IP地址的响应报文之后，直接将所述响应报文根据所述响应报文的目的地址向客户端转发所述响应报文，不做任何修改。

在此种方式下，响应报文的源地址是本服务器所对应的虚拟IP地址(VIP)，而目的地址则是客户端所对应的客户端IP地址(Client IP，CIP)，对于此类报文，可以向客户端进行直接的转发，在此种场景下，可以经过负 载均衡设备，也可以不经过负载均衡设备，但是，需要指出的是，由于响应报文的源地址是虚拟IP地址，所以，负载均衡设备无需进行地址转换。

在具体的应用场景中，本方式下的服务器可以直接将该响应报文发送给客户端，也可以由服务器所包括的代理模块将该响应报文发送给客户端，无论哪种发送方式，由于该响应报文的源地址是本服务器所对应的虚拟IP地址，也即当前负载均衡网络的虚拟IP地址，所以，对于客户端来讲，都是之前所发送报文的目的端返回的响应报文，可以正常接收，不会影响后续的处理过程。

方式二、通过代理模块发送给负载均衡设备，进行地址转换。

在此方式下，所述服务器在生成源地址为所述虚拟IP地址的响应报文之后，根据所述管理IP地址与所述虚拟IP地址的对应关系，通过自身所包括的代理模块将所述响应报文的源地址修改为所述服务器自身所对应的管理IP地址；

所述服务器通过自身所包括的代理模块将源地址修改后的响应报文发送给所述负载均衡设备，以使所述负载均衡设备在将所述响应报文的源地址修改为所述虚拟IP地址之后，根据所述响应报文的目的地址转发所述响应报文。

在此种方式下，响应报文经历了三个阶段：

阶段A、生成阶段。 

最初，服务器生成的响应报文的源地址是本服务器所对应的虚拟IP地址(VIP)，目的地址是客户端所对应的客户端IP地址(Client IP，CIP)。

阶段B、修改阶段。 

代理模块将响应报文的源地址修改为该服务器所对应的管理IP地址(Management IP，MIP)，从而，可以在负载均衡网络内部进行传输，由代理模块发送给负载均衡设备。

阶段C、复原阶段。 

源地址修改后的响应报文发送给负载均衡设备后，由负载均衡设备将管理IP地址进行复原，即将源地址修改为原始的虚拟IP地址，从而，使负载均衡设备可以向客户端进行响应报文的转发，即进行负载均衡网络的外部传输。

需要说明的是，上述的两种转发的方式均可以实现响应报文的回传，差异在于是否通过负载均衡设备进行响应报文的回传，即是否需要将响应报文的源地址修改为管理IP地址，具体的，可以根据实际场景的需要确定采用哪种方式，这样的变化并不会影响本申请的保护范围。

综上所述，考虑到管理IP地址的复原需要，可以看出，如果经过代理模块进行响应报文的反馈，并进行了源地址的修改，则必须经过负载均衡设备进行复原处理，而如果没有进行源地址的修改，而直接进行响应报文的反馈，则无需经过负载均衡设备进行复原处理。

进一步的，考虑到负载均衡网络组网模式包括串联模式和旁挂模式，则响应报文的反馈场景可以包括以下四种情况：

反馈场景1、串联模式下，服务器通过代理模块向负载均衡设备发送源地址为MIP，目的地址为CIP的响应报文，由负载均衡设备将源地址复原为VIP之后，将响应报文发送给客户端，此反馈场景进一步对应了前述的方式二。

反馈场景2、串联模式下，服务器通过代理模块(或不经过代理模块)向负载均衡设备发送源地址为VIP，目的地址为CIP的响应报文，在此过程中，代理模块没有进行源地址的转换(或者反馈过程直接没有经过代理模块)，而由于源地址为VIP，所以，负载均衡设备也无需进行源地址转换，可以直接将响应报文发送给客户端，此反馈场景进一步对应了前述的方式一。

反馈场景3、旁挂模式下，服务器(不经过代理模块)直接向客户端发送源地址为VIP，目的地址为CIP的响应报文，此反馈场景进一步对应了前述的方式一。

反馈场景4、旁挂模式下，服务器通过代理模块直接向客户端发送源地址为VIP，目的地址为CIP的响应报文，在此过程中，代理模块没有进行源地址的转换，此反馈场景进一步对应了前述的方式一。

反馈场景5、旁挂模式下，服务器通过代理模块向负载均衡设备发送源地址为MIP，目的地址为CIP的响应报文，由负载均衡设备将源地址复原为VIP之后，将响应报文发送给客户端，此反馈场景进一步对应了前述的方式二。

在具体的应用场景中，可以根据实际需要确定采用上述的哪种方式，这 样的变化并不会影响本申请的保护范围。

上述说明为本申请在客户端侧的实现流程，相应的，本申请还提出了上述技术方案在负载均衡设备侧的实现流程，具体如图3所示，该方法具体包括以下步骤：

步骤S301、当所述负载均衡设备接收到客户端发送的目的地址为所述虚拟IP地址的报文时，所述负载均衡设备根据负载均衡策略和各服务器的管理IP地址，在所述多个服务器中选择处理所述报文的目的服务器。

需要指出的是，由于各服务器采用的虚拟IP地址和真实IP地址都是相同的，所以，在本步骤的处理中，负载均衡设备是靠管理IP地址来对各服务器进行区分的，而具体的过程为具体的负载均衡处理流程，选择合适的服务器负责具体的业务处理，在此不再赘述。

步骤S302、所述负载均衡设备将所述报文的目的地址修改为所述目的服务器所对应的管理IP地址。

管理IP地址的修改可以方便报文在负载均衡网络中的内部传输。

步骤S303、所述负载均衡设备将目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

具体的，服务器侧的处理参见步骤S201至步骤S202的说明，在此不再重复。

考虑到前述的响应报文的两种反馈方式，其中，方式一不会向负载均衡设备发送响应报文，所以，相应的处理过程与负载均衡设备侧无关。

而对于方式二，负载均衡设备接收到服务器返回的源地址为管理IP地址的响应报文，当然，由之前的说明可知，此种响应报文实际上是通过代理模块发送而来的，在此种情况下，负载均衡设备需要将响应报文的源地址修改为虚拟IP地址，即完成对响应报文的复原，然后，负载均衡设备根据响应报文的目的地址，转发源地址修改后的响应报文。

需要说明的是，上述的处理对应的是在响应报文经过负载均衡设备的情况下，才会进行的处理，具体的，上述的处理对应了前述的反馈场景1和5，具体处理过程的说明参见前述内容，在此不再重复说明。

相应处理的目的在于使通过负载均衡设备转发给客户端的响应报文的源地址为虚拟IP地址，具体采用哪种处理方式可以根据具体的场景差异进行选择，这样的变化并不会影响本申请的保护范围。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例所提出的技术方案，在负载均衡网络的VIP和各服务器的RIP一致的基础上，基于报文VIP与MIP的修改和复原，实现报文在负载均衡网络中的转发，从而，解决了现有技术方案中NAT模式要求性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题。

为了进一步阐述本申请的技术思想，现结合具体的应用场景，对本申请的技术方案进行说明。

在本申请所提出的技术方案中，每个服务器提供应用服务的实IP地址(Real IP，RIP)配置成与对外提供应用的服务的虚拟IP一致，即在本申请所提出的技术方案下，VIP＝RIP。

根据前述的反馈响应报文过程中是否进行源地址的修改，即服务器是否经过代理模块进行报文反馈的情况，本申请通过两个实施例对本申请的实现过程进行说明。

实施例一、直接向客户端进行响应报文的转发，不经过负载均衡设备。

如图4所示，为本申请实施例一所提出的一种具体应用场景中的报文转发方法的流程示意图，该方法包括：

步骤S401、负载均衡设备(以下简称LB设备)收到客户端对应用的请求报文。

此时，LB设备收到的报文内容如下。

  源地址  目的地址

      

CIP

VIP

Payload(载荷)

其中，CIP为客户端IP地址，VIP为当前的负载均衡网络对外提供应用 的虚拟IP地址。

步骤S402、LB设备根据一定算法为该请求报文选择提供服务的真实服务器。

具体的算法，即负载均衡策略，可以根据实际需要进行设定，这样的变化并不会影响本申请的保护范围。

步骤S403、LB设备将该请求报文的目的地址转换为对应后端服务器的管理IP地址，并发送该修改后的请求报文。

此时LB设备所发送的修改后的请求报文格式如下。其中目的地址的部分为被LB设备修改后的部分，其余部分则未被修改。

  源地址  目的地址

      

CIP

MIPn

Payload(载荷)

步骤S404、该请求报文经过中间网络二层或者三层转发，到达服务器的Agent(代理)模块。

步骤S405、Agent模块对该请求报文进行目的地址的复原处理，并转发复原后的请求报文。

Agent模块所执行的处理是LB设备的反向转换过程，转换时使用的MIP与VIP的对应关系可以通过手工配置，也可通过LB设备与Agent模块自动协商获取。

Agent模块收到请求报文，将目的地址替换为当前负载均衡网络对外提供服务的虚拟IP地址后将该请求报文传输给服务器相应的应用模块进行后续处理。替换后的报文如下所示，其目的地址修改回VIP地址。此时报文与原始报文一致。

  源地址  目的地址

      

CIP

VIP

Payload(载荷)

步骤S406、服务器的应用模块收到该请求报文，并处理完成后，生成相应的响应报文。

此时，响应报文内容如下。

  源地址  目的地址

      

VIP

CIP

Payload(载荷)

       步骤S407、服务器向客户端发送响应报文。

需要说明的是，本步骤的发送过程，可以是服务器直接向客户端发送响应报文，也可以是服务器通过Agent模块向客户端发送响应报文，但是，需要说明的是，虽然是通过Agent模块进行响应报文的发送，但是，Agent模块并没有对响应报文做出任何修改。

步骤S408、客户端接收到响应报文，完成当前应用的请求处理过程。

至此，在不经过负载均衡设备的场景下，完整的报文转发处理过程结束，而由于在串联模式的负载均衡网络中，负载均衡设备位于服务器与客户端的必经路径上，所以，不存在不经过负载均衡设备而直接发送给客户端的情况，相比之下，在旁挂模式下，则根据是否经过Agent模块，存在两种不同的反馈场景，分别如图5和图6所示，两种场景均是直接向客户端进行响应报文的反馈，差异在于是否经过Agent模块。

实施例二、通过Agent模块发送给负载均衡设备。

如图7所示，为本申请实施例二所提出的一种具体应用场景中的报文转发方法的流程示意图，该方法包括：

步骤S701～步骤S706、与前述的步骤S401～步骤S406相同，在此不再赘述。

步骤S707、服务器通过Agent模块完成响应报文的源地址修改。

经过Agent模块转发的报文，将源地址修改为MIPn(与当前的服务器对应的管理IP地址)。

修改后的响应报文内容如下。

  源地址  目的地址

      

MIPn

CIP

Payload(载荷)

步骤S708、服务器通过Agent模块向LB设备发送修改后的响应报文。

由于该响应报文经过了Agent模块，并将源地址替换为MIPn，则该响应报文必须要经过LB设备。

步骤S709、LB设备对该请求报文进行源地址的复原处理。

LB设备收到响应报文，将源地址替换为当前负载均衡网络对外提供服务 的虚拟IP地址。替换后的报文如下所示，其源地址修改回VIP地址。此时报文与原始报文一致。

  源地址  目的地址

      

CIP

VIP

Payload(载荷)

步骤S710、LB设备向客户端发送复原后的响应报文。

步骤S711、客户端接收到响应报文，完成当前应用的请求处理过程。

至此，在经过LB设备的场景下，完整的报文转发处理过程结束，在串联模式和旁挂模式下，存在两种不同的反馈场景，分别如图8和图9所示，两种场景均是经过LB设备向客户端进行响应报文的反馈，差异在于负载均衡网络的模式差异。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例所提出的技术方案，在负载均衡网络的VIP和各服务器的RIP一致的基础上，基于报文VIP与MIP的修改和复原，实现报文在负载均衡网络中的转发，从而，解决了现有技术方案中NAT模式要求性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题。

为了实现本申请的技术方案，本申请还提出了一种服务器，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，如图10所示，该服务器的结构包括：

通信模块101，用于接收所述负载均衡设备所发送的报文；

代理模块102，用于当所述通信模块101接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述报文的目的地址修改为所述虚拟IP地址；

处理模块103，用于对目的地址经所述代理模块102修改后的报文进行处理。

具体的，所述通信模块101，还用于： 

接收携带所述管理IP地址与所述虚拟IP地址的对应关系信息的配置消息，在所述服务器本地和/或所述代理模块102中生成所述管理IP地址与所述虚拟IP地址的对应关系；或，

通过所述代理模块102与所述负载均衡设备协商，确定所述管理IP地址与所述虚拟IP地址的对应关系，并保存在所述服务器本地和/或所述代理模块102中。

在具体的应用场景中，可以根据实际需要确定采用上述的哪种方式，无论是哪种方式，只要能够为服务器和代理模块提供管理IP地址与虚拟IP地址的对应关系，就不会影响本申请的保护范围。

在后续的操作过程中，考虑到代理模块对上述对应模块的应用，需要说明的是：

如果上述对应关系保存在服务器本地，则代理模块需要从服务器中读取上述的对应关系，这样的处理可以节约代理模块本地的存储资源；

而如果上述对应关系保存在代理模块中，则代理模块可以直接进行读取和使用，这样的处理可以缩短信息获取的流程，简化操作过程，提高响应速度。

需要进一步说明的是，在直接向客户端进行响应报文反馈的场景中，

所述处理模块103，还用于根据处理结果，生成源地址为所述虚拟IP地址的响应报文，并将所述响应报文发送给所述代理模块102或所述通信模块101；

所述代理模块102，还用于在接收到所述处理模块103所发送的源地址为所述虚拟IP地址的响应报文时，将所述响应报文发送给所述通信模块101；

所述通信模块101，还用于在接收到所述处理模块103或所述代理模块102所发送的源地址为所述虚拟IP地址的响应报文时，将所述响应报文根据所述响应报文的目的地址转发所述响应报文。

在通过负载均衡设备向客户端进行响应报文反馈的场景中，

所述处理模块103，还用于根据处理结果，生成源地址为所述虚拟IP地址的响应报文，并将所述响应报文发送给所述代理模块102；

所述代理模块102，还用于在接收到所述处理模块103所发送的源地址为所述虚拟IP地址的响应报文时，根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述响应报文的源地址修改为所述服务器自身所对应的管理IP地址，并将源地址修改后的响应报文发送给所述通信模块101；

所述通信模块101，还用于在接收到所述代理模块102所发送的源地址修改后的响应报文时，将所述源地址修改后的响应报文发送给所述负载均衡设备，以使所述负载均衡设备在将所述响应报文的源地址修改为所述虚拟IP地址之后，根据所述响应报文的目的地址转发所述响应报文。

需要进一步说明的是，在具体的应用场景中，上述的代理模块102的实现可以包括以下几种情景：

情景一、代理模块102为操作***内部的网卡驱动或者内核报文处理模块，其示意图如图11所示，其具体的处理过程可以包括：

在网卡驱动接收数据包的流程中，在网卡收包中断处理函数中，根据配置信息，对数据包中的相关地址进行修改，此处的配置信息即为前述的管理IP地址与虚拟IP地址的对应关系，相应的修改即为将管理IP地址替换为虚拟IP地址。

在网卡驱动发送数据包的流程中，在网卡发包函数中，根据配置信息对数据包中的相关地址进行修改，此处的配置信息即为前述的管理IP地址与虚拟IP地址的对应关系，相应的修改即为将虚拟IP地址替换为管理IP地址。

在操作***的内核报文处理模块接收数据包的流程中，比如在Linux内核的ip_rcv中，挂接NF_IP_PRE_ROUTING的钩子函数，对收到报文的IP地址进行修改，即将该报文的管理IP地址替换为虚拟IP地址。

在操作***的内核报文处理模块发送数据包的流程中，比如在Linux内核的ip_snd中，挂接NF_IP_PRE_ROUTING的钩子函数，对发送的报文的IP地址进行修改，即将该报文的虚拟IP地址替换为管理IP地址。

情景二、代理模块102为虚拟化环境中物理服务器中的虚拟交换机(virtual switch，Vswitch)，其示意图如图12所示，多台虚拟机(VMware，VM)连接在虚拟交换机上。

情景三、代理模块102为紧邻服务器的物理网络设备，此时网络设备(Device)与服务器(Server)之间为二层网络，其示意图如图13所示。

在实际的应用场景中，具体采用上述的哪种实现方式可以根据实际需要进行选择，这样的变化并不会影响本申请的保护范围。

另一方面，本申请还提供了一种负载均衡设备，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，如图14所示，该负载均衡设备的结构包括：

接收模块141，用于接收客户端或各所述服务器所发送的报文；

决策模块142，用于当所述接收模块141接收到客户端发送的目的地址为所述虚拟IP地址的报文时，根据负载均衡策略和各服务器的管理IP地址，在所述多个服务器中选择处理所述报文的目的服务器；

地址修改模块143，用于将所述接收模块141所接收的所述报文的目的地址修改为所述决策模块142所选择的目的服务器所对应的管理IP地址；

发送模块144，用于将所述地址修改模块143进行目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

在通过负载均衡设备向客户端进行响应报文反馈的场景中，

所述接收模块141，还用于在接收到所述目的服务器返回的源地址为所述管理IP地址的响应报文时，将所述响应报文发送给所述地址修改模块143；

所述地址修改模块143，还用于在接收到所述接收模块141所发送的源地址为所述管理IP地址的响应报文时，将所述响应报文的源地址修改为所述虚拟IP地址，并将源地址修改后的响应报文发送给所述发送模块114；

所述发送模块114，还用于在接收到所述地址修改模块143所发送的源地址修改后的响应报文时，根据所述响应报文的目的地址，转发所述源地址修 改后的响应报文。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例所提出的技术方案，在负载均衡网络的VIP和各服务器的RIP一致的基础上，无需对报文的内容进行识别，只需要在报文头基于VIP与MIP的修改和复原，实现报文在负载均衡网络中的转发，从而，解决了现有技术方案中NAT模式要求性能及往返路径必须一致，会限制组网，无法实现报文的高效转发的问题。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种报文转发方法，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应虚拟IP地址，其特征在于，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述方法包括：

当服务器接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，所述服务器根据所述管理IP地址与所述虚拟IP地址的对应关系，通过自身所包括的代理模块将所述报文的目的地址修改为所述虚拟IP地址；

所述服务器对目的地址修改后的报文进行处理。

2.如权利要求1所述的方法，其特征在于，所述管理IP地址与所述虚拟IP地址的对应关系，具体通过以下方式生成：

所述服务器接收携带所述管理IP地址与所述虚拟IP地址的对应关系信息的配置消息，在所述服务器本地和/或所述代理模块中生成所述管理IP地址与所述虚拟IP地址的对应关系；或，

所述服务器通过所述代理模块与所述负载均衡设备协商，确定所述管理IP地址与所述虚拟IP地址的对应关系，并保存在所述服务器本地和/或所述代理模块中。

3.如权利要求1所述的方法，其特征在于，所述服务器对目的地址修改后的报文进行处理之后，还包括：

所述服务器生成源地址为所述虚拟IP地址的响应报文；

所述服务器根据所述管理IP地址与所述虚拟IP地址的对应关系，通过自身所包括的代理模块将所述响应报文的源地址修改为所述服务器自身所对应的管理IP地址；

所述服务器通过自身所包括的所述代理模块将源地址修改后的响应报文发送给所述负载均衡设备，以使所述负载均衡设备在将所述响应报文的源地址修改为所述虚拟IP地址之后，根据所述响应报文的目的地址转发所述响应报文。

4.一种服务器，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，其特征在于，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，所述服务器包括：

通信模块，用于接收所述负载均衡设备所发送的报文；

代理模块，用于当所述通信模块接收到所述负载均衡设备发送的目的地址为所述服务器自身所对应的管理IP地址的报文时，根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述报文的目的地址修改为所述虚拟IP地址；

处理模块，用于对目的地址经所述代理模块修改后的报文进行处理。

5.如权利要求4所述的服务器，其特征在于，所述通信模块，还用于：

接收携带所述管理IP地址与所述虚拟IP地址的对应关系信息的配置消息，在所述服务器本地和/或所述代理模块中生成所述管理IP地址与所述虚拟IP地址的对应关系；或，

通过所述代理模块与所述负载均衡设备协商，确定所述管理IP地址与所述虚拟IP地址的对应关系，并保存在所述服务器本地和/或所述代理模块中。

6.如权利要求4所述的服务器，其特征在于，

所述处理模块，还用于根据处理结果，生成源地址为所述虚拟IP地址的响应报文，并将所述响应报文发送给所述代理模块；

所述代理模块，还用于在接收到所述处理模块所发送的源地址为所述虚拟IP地址的响应报文时，根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述响应报文的源地址修改为所述服务器自身所对应的管理IP地址，并将源地址修改后的响应报文发送给所述通信模块；

所述通信模块，还用于在接收到所述代理模块所发送的源地址修改后的响应报文时，将所述源地址修改后的响应报文发送给所述负载均衡设备，以使所述负载均衡设备在将所述响应报文的源地址修改为所述虚拟IP地址之后，根据所述响应报文的目的地址转发所述响应报文。

7.一种报文转发方法，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，其特征在于，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述方法包括：

当所述负载均衡设备接收到客户端发送的目的地址为所述虚拟IP地址的报文时，所述负载均衡设备根据负载均衡策略和各服务器的管理IP地址，在所述多个服务器中选择处理所述报文的目的服务器；

所述负载均衡设备将所述报文的目的地址修改为所述目的服务器所对应的管理IP地址；

所述负载均衡设备将目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

8.如权利要求7所述的方法，其特征在于，所述负载均衡设备将目的地址修改后的报文发送给所述目的服务器的代理模块之后，还包括：

当所述负载均衡设备接收到所述目的服务器返回的源地址为所述管理IP地址的响应报文时，所述负载均衡设备将所述响应报文的源地址修改为所述虚拟IP地址；

所述负载均衡设备根据所述响应报文的目的地址，转发源地址修改后的响应报文。

9.一种负载均衡设备，应用于通过负载均衡设备和多个服务器所组成的负载均衡网络中，所述负载均衡网络对应一个虚拟IP地址，其特征在于，各所述服务器的实际IP地址与所述虚拟IP地址相一致，各所述服务器分别对应一个不同的管理IP地址，并分别包括代理模块，所述负载均衡设备包括：

接收模块，用于接收客户端或各所述服务器所发送的报文；

决策模块，用于当所述接收模块接收到客户端发送的目的地址为所述虚拟IP地址的报文时，根据负载均衡策略和各服务器的管理IP地址，在所述多个服务器中选择处理所述报文的目的服务器；

地址修改模块，用于将所述接收模块所接收的所述报文的目的地址修改为所述决策模块所选择的目的服务器所对应的管理IP地址；

发送模块，用于将所述地址修改模块进行目的地址修改后的报文发送给所述目的服务器的代理模块，以使所述代理模块根据所述管理IP地址与所述虚拟IP地址的对应关系，将所述修改后的报文进行复原，并由所述目的服务器进行报文处理。

10.如权利要求9所述的负载均衡设备，其特征在于，

所述接收模块，还用于在接收到所述目的服务器返回的源地址为所述管理IP地址的响应报文时，将所述响应报文发送给所述地址修改模块；

所述地址修改模块，还用于在接收到所述接收模块所发送的源地址为所述管理IP地址的响应报文时，将所述响应报文的源地址修改为所述虚拟IP地址，并将源地址修改后的响应报文发送给所述发送模块；

所述发送模块，还用于在接收到所述地址修改模块所发送的源地址修改后的响应报文时，根据所述响应报文的目的地址，转发所述源地址修改后的响应报文。