一种报文的处理方法和装置与流程

文档序号:14012687阅读:249来源:国知局
本申请涉及互联网
技术领域
,尤其涉及一种报文的处理方法和装置。
背景技术
:如图1所示,为slb(serverloadbalancing,服务器负载均衡)或者lvs(linuxvirtualserver,linux虚拟服务器)的组网示意图,服务器集群内的多个服务器共同提供同一应用,如web应用等。服务器集群内的多个服务器对应一个虚拟ip地址,且每个服务器有对应的真实ip地址。当客户端需要访问服务器时,会向负载均衡设备发送目的ip地址为该虚拟ip地址的报文。负载均衡设备在接收到该报文后,可以为该报文选择一个服务器,并利用该服务器的真实ip地址,将该报文发送给该服务器。其中,负载均衡设备可以基于负载均衡算法为报文选择服务器,这样,可以保证大量的报文被均衡地分配给各个服务器,从而提高多个服务器的整体处理性能。现有技术中,负载均衡设备上通常可以包括多个处理器,且这多个处理器可以并行处理针对不同客户端的报文。例如,处理器1用于处理来自客户端1的报文,并处理服务器1发送给客户端1的报文,处理器2用于处理来自客户端2的报文,并处理服务器2发送给客户端2的报文。但是,上述技术方案在有些场景下,会导致业务处理错误。例如,处理器1用于处理来自客户端1的报文1和报文2,并将报文1和报文2发送给服务器1,服务器1利用报文1和报文2对客户端1的业务进行处理。但是,负载均衡设备接收到报文2后,未将报文2提供给处理器1,而是将报文2提供给处理器2,此时,处理器2会重新选择服务器,如可能选择服务器2,这样,报文1和报文2就被发送给不同的服务器,因此,无法由同一个服务器利用报文1和报文2对客户端1的业务进行处理,从而导致业务处理错误。技术实现要素:本申请提供一种报文的处理方法,应用于包括多个处理器的负载均衡设备上,所述方法包括以下步骤:在接收到报文时,判断所述报文的目的地址是否为所述负载均衡设备的地址;如果否,则确定所述报文是客户端向服务器发送的报文,并计算所述报文的源地址对应的散列值;确定所述散列值所对应的处理器;将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。本申请提供一种报文的处理方法,应用于包括多个处理器的负载均衡设备上,所述方法包括以下步骤:在接收到服务器向客户端发送的报文时,通过所述报文的目的地址查询预先配置的地址与处理器的映射关系,确定所述报文的目的地址对应的处理器;将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。本申请提供一种报文的处理装置,应用于包括多个处理器的负载均衡设备上,所述装置包括:判断单元,用于在接收到报文时,判断所述报文的目的地址是否为所述负载均衡设备的地址;计算单元,用于当所述判断单元的判断结果为否时,确定所述报文是客户端向服务器发送的报文,并计算所述报文的源地址对应的散列值;确定单元,用于确定所述散列值所对应的处理器;发送单元,用于将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。本申请提供一种报文的处理装置,应用于包括多个处理器的负载均衡设备上,所述装置包括:确定单元,用于在接收到服务器向客户端发送的报文时,通过所述报文的目的地址查询预先配置的地址与处理器的映射关系,确定所述报文的目的地址对应的处理器;发送单元,用于将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。基于上述技术方案,本申请实施例中,可以将针对同一会话的多个报文发送给同一处理器,由该处理器对多个报文进行处理,从而可以避免业务处理错误。例如,针对同一会话的报文1和报文2,负载均衡设备在接收到报文1后,将报文1提供给处理器1,在接收到报文2后,将报文2提供给处理器1,处理器1将报文1和报文2均发送给服务器1,从而避免业务处理错误。而且,在负载均衡设备上,可以只由一个处理器来对同一会话的多个报文进行处理,而不是多个处理器同时竞争对这多个报文进行处理,避免了多个处理器之间的竞争,从而可以充分利用大量的处理器,节省处理器的资源,提高处理器的利用率,提升负载均衡的性能和处理能力,提升业务的性能。附图说明为了更加清楚地说明本申请实施例或者现有技术中的技术方案,下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。图1和图2是slb或者lvs的组网示意图;图3是本申请一种实施方式中的报文的处理方法的流程图;图4是本申请另一种实施方式中的报文的处理方法的流程图;图5是本申请一种实施方式中的负载均衡设备的硬件结构图;图6是本申请一种实施方式中的报文的处理装置的结构图;图7是本申请另一种实施方式中的报文的处理装置的结构图。具体实施方式在本申请使用的术语仅仅是出于描述特定实施例的目的,而非限制本申请。本申请和权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其它含义。还应当理解,本文中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,此外,所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。在一个例子中,在slb或者lvs的组网中,当负载均衡设备包括多个处理器时,针对客户端发送给服务器的tcp(transmissioncontrolprotocol,传输控制协议)报文或者udp(userdatagramprotocol,用户数据报协议)报文,负载均衡设备的转发芯片(即网卡)在接收到tcp报文或者udp报文后,可以从tcp报文或者udp报文中解析出五元组信息(如源地址,源端口号,目的地址,目的端口号,协议号等),并利用该五元组信息选取对应的处理器,并将tcp报文或者udp报文发送给该处理器。针对客户端发送给服务器的icmp(internetcontrolmessageprotocol,互联网控制报文协议)报文,负载均衡设备的转发芯片在接收到icmp报文后,可以从icmp报文中解析出源地址,目的地址,协议号,并利用解析出的源地址,目的地址,协议号选取对应的处理器,并将icmp报文发送给该处理器。当然,负载均衡设备接收报文的过程,并不局限于使用转发芯片接收报文,还可以为负载均衡设备内配置的功能单元(通过程序实现)接收报文,只要负载均衡设备能够接收到报文即可。为了方便描述,后续以负载均衡设备的转发芯片(即网卡)接收各报文为例进行说明。显然,由于tcp报文/udp报文与icmp报文的处理器的选择方式不同,因此,会导致属于同一会话的tcp报文/udp报文与icmp报文的处理器不同,从而导致业务处理错误。例如,属于同一会话的tcp报文/udp报文的处理器为处理器1,属于此会话的icmp报文的处理器为处理器2。这样,由处理器1处理tcp报文/udp报文,将tcp报文/udp报文发送给服务器1,由处理器2处理icmp报文,但是,由于处理器2没有会话信息或者只有错误的会话信息,所以icmp报文会被丢弃或者错误处理,因此,会导致业务处理错误。为了解决上述问题,在一个例子中,当tcp报文/udp报文被分配给处理器1之后,当接收到与该tcp报文/udp报文属于同一会话的icmp报文后,为了使处理icmp报文的处理器与处理tcp报文/udp报文的处理器(假设为处理器1)相同,则在处理icmp报文时,需要对处理器1之外的其它处理器进行禁止中断、加锁等操作,以使其它处理器无法处理icmp报文,从而避免处理器之间的竞争。但是,由于其它处理器被加锁,因此同一时间,只有一个处理器可以处理报文,而其它处理器的资源被浪费,导致不能发挥多个处理器并行处理报文的优势,从而无法实现负载均衡设备的高吞吐,降低了处理性能。针对上述发现,本申请实施例中提出一种报文的处理方法,该方法可以应用在slb或者lvs组网场景下的负载均衡设备上,且该负载均衡设备包括多个处理器,本实施例中的处理器可以为cpu(centralprocessingunit,中央处理器)。如图1和图2所示,为本申请实施例的应用场景示意图,与图1不同的是,在图2中包括多个负载均衡设备,通过部署这多个负载均衡设备,可以解决一个负载均衡设备的单点故障,当一个负载均衡设备停止服务(如发生故障)时,还可以由其它负载均衡设备继续提供服务,从而保证业务不中断。在图1和图2中,服务器集群内可以包括多个服务器,这多个服务器共同为客户端提供同一应用,如web(网页)应用等。服务器集群内的多个服务器对应一个虚拟地址,且每个服务器有对应的真实地址。在图2中,负载均衡集群内包括至少两个负载均衡设备,当负载均衡集群包含两个负载均衡设备时,则这两个负载均衡设备采用主备模式进行处理,即一个负载均衡设备作为主负载均衡设备,另一个负载均衡设备作为备负载均衡设备。当负载均衡集群包含三个或者三个以上的负载均衡设备时,则这些负载均衡设备采用集群部署模式。在上述两种部署模式下,当一个负载均衡设备停止服务(如发生故障)时,均可以由其它负载均衡设备继续提供服务,从而保证业务不中断。其中,图1和图2只是一种典型的网络拓扑结构,但不是唯一的拓扑结构,对于其它拓扑结构,处理方式与本申请实施例的处理方式相同,在此不再赘述。对于负载均衡集群内的多个负载均衡设备来说,多个负载均衡设备之间可以采用ecmp(equalcostmultipathrouting,等价路由)的负载均衡方式处理。针对图1和图2,本申请实施例的处理流程相同,后续以图1为例进行说明。在上述应用场景下,如图3所示,该报文的处理方法可以包括以下步骤:步骤301,在接收到报文时,判断所述报文的目的地址是否为本负载均衡设备的地址。如果否,则执行步骤302;如果是,则执行步骤305。在一个例子中,本申请实施例中的地址可以是网络地址,也就是ip地址,如ipv4地址或者ipv6地址,为了方便描述,本申请实施例中统一称为地址。在一个例子中,负载均衡设备接收到的报文,可以是客户端向服务器发送的报文,也可以是服务器向客户端发送的报文。如果是客户端向服务器发送的报文,则执行步骤302;如果是服务器向客户端发送的报文,则执行步骤305。其中,当客户端需要访问服务器时,会发送目的地址为虚拟地址的报文,因此,针对客户端向服务器发送的报文,该报文的目的地址是虚拟地址,而不是本负载均衡设备的地址,因此,如果报文的目的地址不是本负载均衡设备的地址,则说明该报文是客户端向服务器发送的报文,执行步骤302。其中,负载均衡设备在向服务器转发报文时,该报文的源地址为负载均衡设备的地址。因此,服务器在向客户端发送报文时,该报文的目的地址为负载均衡设备的地址(即收到报文的源地址)。因此,如果报文的目的地址是本负载均衡设备的地址,则说明该报文是服务器向客户端发送的报文,执行步骤305。步骤302,确定所述报文是客户端向服务器发送的报文,并计算所述报文的源地址对应的散列值。在一个例子中,针对计算所述报文的源地址对应的散列值的过程,还包括:计算所述报文的源地址和目的地址对应的散列值。本申请实施例中,在计算散列值时,只参考报文的源地址,或者,报文的源地址和目的地址,而忽略协议号、源端口标识、目的端口标识等因素。其中,在计算散列值时,针对客户端向服务器发送的报文,由于报文的源地址不变,因此可以参考报文的源地址,这样,对于客户端向服务器发送的所有报文(如tcp报文或者udp报文icmp报文),会对应同一个散列值。由于报文的源地址不变,目的地址不变,因此可以参考报文的源地址和目的地址,这样,对于客户端向服务器发送的所有报文,会对应同一个散列值。由于不同客户端向服务器发送报文的目的地址相同,因此,不能单独参考报文的目的地址。在一个例子中,计算所述报文的源地址对应的散列值的过程,可以包括但不限于如下方式:利用预设哈希算法对所述源地址进行哈希运算,得到所述源地址对应的散列值。所述预设哈希算法可以包括:能够使哈希运算后得到的散列值的总数量,与所述负载均衡设备上的多个处理器的总数量相同的哈希算法。其中,由于预设哈希算法能够使哈希运算后得到的散列值的总数量,与负载均衡设备上的多个处理器的总数量相同,因此,每个散列值可以唯一对应一个处理器,这样,就可以确定出每个散列值所对应的处理器。而且,针对每个散列值,只会确定出对应的唯一一个处理器,而不会同时确定出多个处理器。进一步的,利用预设哈希算法对所述源地址进行哈希运算,得到所述源地址对应的散列值的过程,具体可以包括但不限于如下方式:将所述源地址对所述多个处理器的总数量取余,并确定余数为所述源地址对应的散列值。其中,通过配置预设哈希算法为:将源地址对处理器的总数量取余,能够使哈希运算后得到的散列值的总数量,与负载均衡设备上的多个处理器的总数量相同。而且,将源地址对处理器的总数量取余的运算过程比较简单,计算量较小。在一个例子中,计算所述报文的源地址和所述目的地址对应的散列值的过程,具体可以包括但不限于如下方式:利用预设哈希算法对所述源地址和所述目的地址进行哈希运算,得到所述源地址和所述目的地址对应的散列值。其中,所述预设哈希算法具体可以包括:能够使哈希运算后得到的散列值的总数量,与所述负载均衡设备上的多个处理器的总数量相同的哈希算法。其中,由于预设哈希算法能够使哈希运算后得到的散列值的总数量,与负载均衡设备上的多个处理器的总数量相同,因此,每个散列值可以唯一对应一个处理器,这样,就可以确定出每个散列值所对应的处理器。而且,针对每个散列值,只会确定出对应的唯一一个处理器,而不会同时确定出多个处理器。进一步的,利用预设哈希算法对所述源地址和所述目的地址进行哈希运算,得到所述源地址和所述目的地址对应的散列值的过程,可以包括但不限于:将所述源地址和所述目的地址转换为一个新数值,并将所述新数值对所述多个处理器的总数量取余,并确定余数为所述源地址和所述目的地址对应的散列值。其中,通过配置预设哈希算法为:将源地址和目的地址转换为一个新数值,并将新数值对处理器的总数量取余,能够使哈希运算后得到的散列值的总数量,与负载均衡设备上的多个处理器的总数量相同。将源地址和目的地址转换为一个新数值,将新数值对处理器的总数量取余的运算过程比较简单,计算量较小。在一个例子中,所述多个处理器是指负载均衡设备上的所有用于数据转发的处理器。例如,当负载均衡设备上包括8个用于数据转发的处理器时,则对这8个处理器进行编号,这些处理器分别为处理器0、处理器1、….处理器7。针对“将所述源地址对所述多个处理器的总数量取余,并确定余数为所述源地址对应的散列值”的过程,假设源地址为127.118.12.12,则可以直接将1271181212对总数量8取余,并确定余数(假设为2)为源地址对应的散列值。针对“将所述源地址和所述目的地址转换为一个新数值,并将所述新数值对所述多个处理器的总数量取余,并确定余数为所述源地址和所述目的地址对应的散列值”的过程,假设源地址为127.118.12.12,目的地址为192.168.0.1,则可以将127.118.12.12和192.168.0.1转换为一个新数值,并将所述新数值对总数量8取余,并确定余数(假设为1)为源地址和目的地址对应的散列值。其中,在将127.118.12.12和192.168.0.1转换为一个新数值时,可以将其转换为数值127118121219216801,或者将其转换为数值192168011271181212,或者将其转换为数值(1271181212+19216801)等,对于将源地址和目的地址转换为新数值的方式,可以根据实际经验任意配置,本申请实施例中对此不做限制。步骤303,确定所述散列值所对应的处理器。在一个例子中,确定所述散列值所对应的处理器的过程,具体可以包括但不限于如下方式:通过所述散列值查询预先配置的散列值与处理器的映射关系,得到所述散列值所对应的处理器。其中,由于散列值的总数量与负载均衡设备上的多个处理器的总数量相同,因此可以预先配置散列值与处理器的映射关系,从而使每个散列值可以唯一对应一个处理器,这样,就可以确定出每个散列值所对应的处理器。其中,可以在负载均衡设备上预先配置散列值与处理器的映射关系,例如,当用于数据转发的处理器的数量为8个时,则该映射关系可以如表1所示。基于此映射关系,在得到散列值为1时,确定散列值1对应的处理器为处理器1。表1散列值处理器0处理器01处理器12处理器23处理器34处理器45处理器56处理器67处理器7步骤304,将报文发送给所述处理器,以使所述处理器对所述报文进行处理。例如,在确定所述散列值所对应的处理器为处理器1时,则将报文(即步骤301中接收到的报文)发送给该处理器1,以使该处理器1处理该报文。其中,该报文可以包括但不限于:udp报文、tcp报文、icmp报文。在一个例子中,针对所述处理器对所述报文进行处理的过程,可以包括但不限于如下情况:当所述报文为udp报文或者tcp报文时,如果存在所述报文对应的会话,则利用所述会话发送所述报文;如果不存在所述报文对应的会话,则在所述处理器上创建所述报文对应的会话,并利用创建的会话发送所述报文。当所述报文为icmp报文时,如果存在所述报文对应的会话,则利用所述会话发送所述报文;如果不存在所述报文对应的会话,则丢弃所述报文。在一个例子中,处理器在接收到报文(如udp报文、tcp报文、icmp报文等)后,可以利用该报文中的特征信息(如源地址、目的地址、源端口标识、目的端口标识、协议号等五元组信息)查询是否有该报文对应的会话。在一个例子中,针对在处理器上创建所述报文对应的会话的过程,处理器可以利用所述报文中的特征信息建立所述报文对应的会话。在一个例子中,针对利用所述会话发送所述报文的过程,则处理器可以利用所述会话修改所述报文,并将修改后的报文发送给服务器。以下结合具体的应用场景,对上述报文的处理过程进行详细说明。1、针对相同特征信息(如五元组信息)的首个udp报文/tcp报文,处理器上没有建立udp报文/tcp报文对应的会话,因此利用udp报文/tcp报文的特征信息查询是否有对应的会话时,查询结果为没有对应的会话,利用udp报文/tcp报文的特征信息建立会话,该会话可以包括但不限于:特征信息、会话状态信息(如连接建立状态、连接等待状态、连接关闭状态、接收数据状态等)、真实服务器信息(如真实服务器的地址、端口、可用状态等)。其中,真实服务器是处理器基于负载均衡算法为udp报文/tcp报文选择的服务器。处理器利用该会话修改udp报文/tcp报文(如将目的地址修改为真实服务器的地址,将源地址修改为本处理器的地址),将修改后的udp报文/tcp报文发送给服务器。2、针对相同特征信息(如五元组信息)的后续udp报文/tcp报文(如第二个udp报文/tcp报文、第三个udp报文/tcp报文等),处理器上已经建立udp报文/tcp报文对应的会话,因此,利用udp报文/tcp报文中的特征信息查询是否有对应的会话时,查询结果为有对应的会话,处理器利用该会话修改udp报文/tcp报文(如将目的地址修改为真实服务器的地址,将源地址修改为本处理器的地址),并将修改后的udp报文/tcp报文发送给服务器。由于首个udp报文/tcp报文和后续udp报文/tcp报文是基于同一会话进行发送的,因此,会被处理器发送给同一个服务器,由同一个服务器进行处理。3、客户端在发送udp报文/tcp报文的基础上,在实际应用中,客户端还可能向服务器发送icmp报文,如sourcequench(源端被关闭)类型的icmp报文,因此,icmp报文是在udp报文/tcp报文之后发送的,此时处理器上已经建立了udp报文/tcp报文对应的会话。基于此,针对icmp报文,处理器上已经建立icmp报文对应的会话,因此,在利用icmp报文中的特征信息查询是否有对应的会话时,查询结果为有对应的会话,处理器利用该会话修改icmp报文(如将目的地址修改为真实服务器的地址,将源地址修改为本处理器的地址),并将修改后的icmp报文发送给服务器。此外,处理器在查询是否有对应的会话时,如果查询结果为没有对应的会话,则说明icmp报文是一个错误的报文,处理器需要丢弃该icmp报文,不再发送该icmp报文。步骤305,确定报文是服务器向客户端发送的报文,通过报文的目的地址查询预先配置的地址与处理器的映射关系,确定报文的目的地址所对应的处理器。在一个例子中,针对负载均衡设备上的每个处理器,该处理器具有只属于该处理器的一个或者多个地址(称为localaddresss),且只属于该处理器的地址与属于其它处理器的地址不同。基于此,可以在负载均衡设备的本地地址表中预先维护地址与处理器的映射关系,如表2所示,为本地地址表的一个示例。表2地址处理器192.168.0.100处理器0192.168.0.101处理器1192.168.0.102处理器2192.168.0.103处理器3192.168.0.104处理器4192.168.0.105处理器5192.168.0.106处理器6192.168.0.107处理器7在一个例子中,针对每个处理器,该处理器向服务器发送的报文的源地址为该处理器的地址,以使服务器返回的报文的目的地址为该处理器的地址。其中,在处理器向服务器发送报文时,通过将源地址修改为本处理器的地址,这样,服务器在返回报文时,目的地址就是该处理器的地址。这样,可以将服务器返回的报文发送给该处理器,由该处理器对报文进行处理。即针对客户端发送给服务器的报文,服务器向客户端返回的报文,均由同一个处理器处理器。例如,当处理器1向服务器1发送报文时,针对上述“处理器利用会话修改报文”的过程,处理器1会将报文的目的地址修改为真实服务器的地址,即服务器1的地址,并将报文的源地址修改为本处理器的地址,即处理器1的地址192.168.0.101。这样,服务器1在向客户端发送报文时,该报文的目的地址就是处理器1的地址192.168.0.101。负载均衡设备在接收到该报文后,可以通过该报文的目的地址192.168.0.101查询表2,得到处理器为处理器1。步骤306,将报文发送给确定的处理器,以使确定的处理器对报文进行处理。例如,在确定报文的目的地址所对应的处理器为处理器1时,则将报文(即步骤301中接收到的报文)发送给该处理器1,以使该处理器1处理该报文。其中,该报文可以包括但不限于:udp报文、tcp报文、icmp报文。在一个例子中,针对确定的处理器对所述报文进行处理的过程,可以包括但不限于如下情况:如果存在所述报文对应的会话,则该处理器利用所述会话发送所述报文;如果不存在所述报文对应的会话,则该处理器丢弃所述报文。在一个例子中,处理器在接收到报文(如udp报文、tcp报文、icmp报文等)后,可以利用该报文中的特征信息(如源地址、目的地址、源端口标识、目的端口标识、协议号等五元组信息)查询是否有该报文对应的会话。在一个例子中,针对利用所述会话发送所述报文的过程,则处理器可以利用所述会话修改所述报文,并将修改后的报文发送给客户端。以下结合具体的应用场景,对上述报文的处理过程进行详细说明。1、服务器在接收到udp报文/tcp报文后,可以向客户端返回udp报文/tcp报文,服务器返回udp报文/tcp报文是在客户端发送udp报文/tcp报文之后进行,处理器上已经建立udp报文/tcp报文对应的会话。因此,处理器在接收到服务器返回的udp报文/tcp报文时,在利用udp报文/tcp报文的特征信息查询是否有对应会话时,查询结果为有对应会话,利用该会话修改udp报文/tcp报文,并将修改后的udp报文/tcp报文发送给客户端。在查询是否有对应的会话时,如果查询结果为没有对应的会话,则说明udp报文/tcp报文是一个错误的报文,处理器需要丢弃该udp报文/tcp报文。2、在实际应用中,服务器还可能向客户端发送icmp报文,且服务器发送的icmp报文是在客户端发送udp报文/tcp报文之后进行,处理器上已经建立udp报文/tcp报文对应的会话。因此处理器在接收到服务器发送的icmp报文时,在利用icmp报文的特征信息查询是否有对应的会话时,查询结果为有对应的会话,并利用该会话修改icmp报文,并将修改后的icmp报文发送给客户端。在查询是否有对应的会话时,如果查询结果为没有对应的会话,则说明icmp报文报文是一个错误的报文,处理器需要丢弃该icmp报文。在一个例子中,服务器向客户端发送的icmp报文可以包括但不限于:目的端口不可达的icmp错误报文、ttl(timetolive,生存时间值)超时的icmp错误报文。其中,当服务器的服务端口关闭后,该服务器在接收到来自客户端的报文后,就会向客户端返回目的端口不可达的icmp错误报文。当服务器所在的网络存在环路时,则服务器可以向客户端发送ttl超时的icmp错误报文。进一步的,客户端在接收到icmp错误报文之后,就可以根据不同的错误类型,关闭连接或者提示用户故障原因,以便于用户排查问题。在一个例子中,在处理器利用会话修改各报文(如udp报文、tcp报文、icmp报文等)时,处理器可以将该报文的源地址修改为会话中的目的地址,即虚拟地址,并将该报文的目的地址修改为会话中的源地址,即客户端的地址。显然,经过上述处理,客户端发送给服务器的udp报文/tcp报文、icmp报文会被发送给同一处理器进行处理。而且,服务器向客户端返回的udp报文/tcp报文、icmp报文也会被发送给该处理器进行处理。基于上述技术方案,本申请实施例中,可以将针对同一会话的多个报文发送给同一处理器,由该处理器对多个报文进行处理,从而可以避免业务处理错误。例如,针对同一会话的报文1和报文2,负载均衡设备在接收到报文1后,将报文1提供给处理器1,在接收到报文2后,将报文2提供给处理器1,处理器1将报文1和报文2均发送给服务器1,从而避免业务处理错误。而且,在负载均衡设备上,可以只由一个处理器来对同一会话的多个报文进行处理,而不是多个处理器同时竞争对这多个报文进行处理,避免了多个处理器之间的竞争,从而可以充分利用大量的处理器,节省处理器的资源,提高处理器的利用率,提升负载均衡的性能和处理能力,提升业务的性能。针对服务器向客户端发送报文的过程,本申请实施例中,还提出一种报文的处理方法,该方法可以应用于包括多个处理器的负载均衡设备上,如图4所示,该报文的处理方法可以包括以下步骤:步骤401,在接收到服务器向客户端发送的报文时,通过报文的目的地址查询预先配置的地址与处理器的映射关系,确定报文的目的地址对应的处理器。在一个例子中,针对负载均衡设备上的每个处理器,该处理器具有只属于该处理器的一个或者多个地址(称为localaddresss),且只属于该处理器的地址与属于其它处理器的地址不同。基于此,可以在负载均衡设备的本地地址表中预先维护地址与处理器的映射关系,如表2所示,为本地地址表的一个示例。在一个例子中,针对每个处理器,该处理器向服务器发送的报文的源地址为该处理器的地址,以使服务器返回的报文的目的地址为该处理器的地址。步骤402,将报文发送给所述处理器,以使所述处理器对报文进行处理。其中,该报文可以包括但不限于:udp报文、tcp报文、icmp报文。在一个例子中,针对确定的处理器对所述报文进行处理的过程,可以包括但不限于如下情况:如果存在所述报文对应的会话,则该处理器利用所述会话发送所述报文;如果不存在所述报文对应的会话,则该处理器丢弃所述报文。步骤401、步骤402的详细流程,参见步骤305和步骤306,在此不再赘述。基于与上述方法同样的申请构思,本申请实施例中还提供了一种报文的处理装置,该报文的处理装置可以应用在包括多个处理器的负载均衡设备上。其中,该报文的处理装置可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在的负载均衡设备的处理器,读取非易失性存储器中对应的计算机程序指令形成的。从硬件层面而言,如图5所示,为本申请提出的报文的处理装置所在的负载均衡设备的一种硬件结构图,除了图5所示的处理器、非易失性存储器外,该负载均衡设备还可以包括其他硬件,如负责处理报文的转发芯片、网络接口、内存等;从硬件结构上来讲,该负载均衡设备还可能是分布式设备,可能包括多个接口卡,以便在硬件层面进行报文处理的扩展。如图6所示,为本申请提出的报文的处理装置的结构图,所述装置包括:判断单元11,用于在接收到报文时,判断所述报文的目的地址是否为所述负载均衡设备的地址;计算单元12,用于当所述判断单元11的判断结果为否时,则确定所述报文是客户端向服务器发送的报文,并计算所述报文的源地址对应的散列值;确定单元13,用于确定所述散列值所对应的处理器;发送单元14,用于将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。在一个例子中,所述计算单元12,还用于在计算所述报文的源地址对应的散列值的过程中,计算所述报文的源地址和目的地址对应的散列值。在一个例子中,所述确定单元13,具体用于在确定所述散列值所对应的处理器的过程中,通过所述散列值查询预先配置的散列值与处理器的映射关系,得到所述散列值所对应的处理器。在一个例子中,所述确定单元13,还用于当所述判断单元11的判断结果为是时,则确定所述报文是服务器向客户端发送的报文,并通过所述报文的目的地址查询预先配置的地址与处理器的映射关系,确定所述报文的目的地址所对应的处理器;所述发送单元14,还用于将所述报文发送给所述确定的处理器,以使所述确定的处理器对所述报文进行处理。在一个例子中,针对每个处理器,该处理器具有只属于该处理器的一个或者多个地址,且只属于该处理器的地址与属于其它处理器的地址不同;针对每个处理器,该处理器向服务器发送的报文的源地址为该处理器的地址,以使服务器返回的报文的目的地址为该处理器的地址。如图7所示,为本申请提出的报文的处理装置的结构图,应用在包括多个处理器的负载均衡设备上,所述装置包括:确定单元21,用于在接收到服务器向客户端发送的报文时,通过所述报文的目的地址查询预先配置的地址与处理器的映射关系,确定所述报文的目的地址对应的处理器;发送单元22,用于将所述报文发送给所述处理器,以使所述处理器对所述报文进行处理。在一个例子中,针对每个处理器,该处理器具有只属于该处理器的一个或者多个地址,且只属于该处理器的地址与属于其它处理器的地址不同;针对每个处理器,该处理器向服务器发送的报文的源地址为该处理器的地址,以使服务器返回的报文的目的地址为该处理器的地址。通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述的方法。本领域技术人员可以理解附图只是一个优选实施例的示意图,附图中的单元或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施例中的装置中的单元可以按照实施例描述进行分布于实施例的装置中,也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的单元可以合并为一个单元,也可进一步拆分成多个子单元。上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。以上公开的仅为本申请的几个具体实施例,但是,本申请并非局限于此,任何本领域的技术人员能思之的变化都应落入本申请的保护范围。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1