一种报文转发方法和设备.pdf

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

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地址，并将源地址修改后的响应报文发送给所述发送模块；
所述发送模块，还用于在接收到所述地址修改模块所发送的源地址修改后的响应报文时，根据所述响应报文的目的地址，转发所述源地址修改后的响应报文。

一种报文转发方法和设备
技术领域
本发明涉及通信技术领域，特别涉及一种报文转发方法和设备。
背景技术
负载均衡(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设备收到的报文内容如下。
  源地址  目的地址