CN103023942A - 一种服务器负载均衡方法、装置及系统 - Google Patents

一种服务器负载均衡方法、装置及系统 Download PDF

Info

Publication number
CN103023942A
CN103023942A CN2011102958204A CN201110295820A CN103023942A CN 103023942 A CN103023942 A CN 103023942A CN 2011102958204 A CN2011102958204 A CN 2011102958204A CN 201110295820 A CN201110295820 A CN 201110295820A CN 103023942 A CN103023942 A CN 103023942A
Authority
CN
China
Prior art keywords
address
port
packet
client
destination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN2011102958204A
Other languages
English (en)
Other versions
CN103023942B (zh
Inventor
陈建
唐会军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Original Assignee
Qizhi Software Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qizhi Software Beijing Co Ltd filed Critical Qizhi Software Beijing Co Ltd
Priority to CN201110295820.4A priority Critical patent/CN103023942B/zh
Publication of CN103023942A publication Critical patent/CN103023942A/zh
Application granted granted Critical
Publication of CN103023942B publication Critical patent/CN103023942B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本申请提供了一种服务器负载均衡方法、装置及系统,以使LVS实现跨网段的负载均衡。在LVS和RS之间采用三层互联,并对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。这种三层互联的方式实现了真正意义上的跨网段负载均衡,LVS上能够提供服务的RS数目不再受限制,因此可以扩展出层次化的网络拓扑。而且,简化了LVS和RS的配置和运营维护。

Description

一种服务器负载均衡方法、装置及系统
技术领域
本申请涉及负载均衡技术,特别是涉及一种服务器负载均衡方法、装置及系统。
背景技术
在互联网应用技术中,负载均衡一直是热门话题,LVS负载均衡是其中的一种负载均衡技术。LVS的英文全称是Linux Virtual Server,即Linux虚拟服务器。LVS主要用于多服务器的负载均衡,工作在网络层,可以实现高性能、高可用的服务器集群技术。
LVS负载均衡的系统结构如图1所示,主要包括客户端(Client)、虚拟服务器(LVS)和真实服务器(Real Server,简称RS)。其中,LVS最主要的功能是提供包转发和负载均衡,LVS通过虚拟一个对外访问的IP(vip),当用户访问vip时到达LVS,LVS根据一定的规则选择一个RS,RS处理完成后返回给客户端数据。
LVS目前支持VS/DR、VS/NAT和VS/TUN三种工作模式。
VS/DR(Virtual Server via Direct Routing),即通过直接路由技术实现虚拟服务器。VS/DR通过改写请求报文的MAC地址,将请求发送到RS,而RS将响应直接返回给客户。
VS/NAT(Virtual Server via Network Address Translation),即通过网络地址转换技术实现虚拟服务器。当请求来到时,VS/NAT将数据报文中的目标地址(即虚拟IP地址vip)改成具体的某台RS,端口也改成RS的端口,然后把报文发给RS。RS处理完数据后,需要返回给VS/NAT,然后VS/NAT将数据包中的源地址和源端口改成vip的地址和端口,最后把数据发送出去。
VS/TUN(Virtual Server via IP Tunneling),即通过IP隧道技术实现虚拟服务器。是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。它跟VS/NAT基本一样,但是RS是直接返回数据给客户端,不需要经过VS/TUN。
在上述三种工作模式下,LVS与后端的RS均需要两层互联,即LVS与RS处在同一个网段中并使用两层协议通信,由此带来的问题是:限制了LVS和RS的部署和级联方式,LVS不能为跨网段的RS提供服务,只能使用较为扁平的网络拓扑,从而大大局限了网络拓扑。
为了能为多个网段的RS服务,现有的技术提出一种在VS/DR和VS/NAT工作模式下的实现方法,该方法通过在LVS网卡上打tag来实现。
通常,服务器的网卡通过网线与路由器/交换机端口相连以连通网络。交换机端口一般有两种工作模式,一种是access模式,一种是trunk模式。在access模式下,交换机端口只能属于一个vlan(Virtual Local Area Network,虚拟局域网),对应的服务器网卡就配置一个网段的ip;在trunk模式下,交换机端口可以属于多个vlan,因此,对应的服务器网卡就可以配置多个网段的ip,为了在网卡上配置多个网段,就需要对网卡打tag,每个tag对应着一个网段。
对应到LVS的VS/DR和VS/NAT模式,一般情况下LVS需要和后端的RS位于同一个网段,但是如果后端RS位于多个网段,就需要把LVS网卡的上联端口设置为trunk模式,并且在LVS的网卡上打上多个tag,然后在每个tag上配置不同的网段来实现。
这种在LVS网卡上打tag的方式可以使LVS服务于多个网段的RS,但是同一个路由器/交换机上的端口比较有限,限制了LVS上能够提供服务的RS数目。而且,LVS和RS之间仍是两层互联,并没有实现真正意义上的跨网段服务。
因此,需要实现一种全新的跨网段技术,使LVS能为更多不同网段的RS提供服务,在真正意义上扩展网络拓扑。
发明内容
本申请提供了一种服务器负载均衡方法、装置及系统,以使LVS实现跨网段的负载均衡。
为了解决上述问题,本申请公开了一种服务器负载均衡方法,包括:
配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
优选的,所述将转换后的数据包转发给真实服务器之前,还包括:在所述转换后的数据包中添加客户端的真实地址及其端口。
优选的,还包括:真实服务器收到所述转换后的数据包,通过解析获取客户端的真实地址及其端口。
优选的,还包括:判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,当接收客户端发来的数据包时,所述转换之前还包括:根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,还包括:判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后进行所述的转换;如果否,则退出。
优选的,当接收真实服务器发来的数据包时,所述转换之前还包括:根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
本申请还提供了一种服务器负载均衡装置,包括:
虚拟配置单元,用于配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
第一地址转换单元,用于当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
第二地址转换单元,用于当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
优选的,所述装置还包括:地址添加单元,用于在所述第一地址转换单元将转换后的数据包转发给真实服务器之前,在所述转换后的数据包中添加客户端的真实地址及其端口。
优选的,所述装置还包括:数据包判断单元,用于判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,所述装置还包括:第一查询单元,用于根据客户端发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第一地址转换单元;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,所述装置还包括:连接建立单元,用于判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后触发所述第一地址转换单元;如果否,则退出。
优选的,所述装置还包括:第二查询单元,用于根据真实服务器发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第二地址转换单元;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
优选的,所述装置还包括:地址解析单元,设在真实服务器上,用于真实服务器收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
本申请还提供了一种服务器负载均衡系统,包括:虚拟服务器和与之相连的真实服务器,所述虚拟服务器包括如上述的服务器负载均衡装置。
优选的,所述真实服务器还包括:地址解析单元,用于收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
与现有技术相比,本申请包括以下优点:
首先,本申请基于原VS/NAT工作模式,在LVS和RS之间采用三层互联,并对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。这种三层互联的方式实现了真正意义上的跨网段负载均衡,LVS上能够提供服务的RS数目不再受限制,因此可以扩展出层次化的网络拓扑。
其次,本申请简化了LVS和RS的配置和运营维护,原因如下:
第一,LVS和RS只需要三层互通,大大简化了前端部署的难度,并有利于层次化地网络拓扑;
第二,RS在接入LVS时只需要加载一个用于解析客户端真实地址和端口的内核模块,不需要做其他任何修改;不需要为vip添加额外配置,只需要和LVS三层互通,易于部署和维护;
第三,LVS不需要配置任何tag信息,简化了运营维护的复杂度。
当然,实施本申请的任一产品不一定需要同时达到以上所述的所有优点。
附图说明
图1是现有技术中LVS负载均衡的系统结构图;
图2是现有技术中原VS/NAT工作模式下的TCP交互流程示意图;
图3是本申请实施例所述跨网段的LVS负载均衡工作模式示意图;
图4是图3所示工作模式下跨网段的TCP交互流程示意图;
图5是本申请实施例所述一种服务器负载均衡方法的流程图;
图6是图5的详细实现流程图;
图7是本申请实施例中ipv4_specific.syn_recv_sock的Hook函数处理流程图;
图8是本申请实施例中inet_stream_ops.getname Hook函数的处理流程图;
图9是本申请实施例所述一种服务器负载均衡装置的结构图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实现了一种跨网段的LVS负载均衡。本申请在LVS和RS之间采用三层互联,并对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。
本申请基于原VS/NAT工作模式,下面首先介绍原VS/NAT工作模式下的TCP交互流程。
参照图2,是现有技术中原VS/NAT工作模式下的TCP交互流程示意图。
其中,Client表示客户端,LVS表示虚拟服务器,RS表示真实服务器;
cip:Client ip,客户端的ip地址;
cport:Client port,客户端上为cip提供服务的端口;
vip:virtual ip,LVS上绑定的虚拟ip,供用户客户端访问;
vport:virtual port,LVS上为vip提供服务的端口;
rip:Real Server ip,后端真实服务器的ip地址;
rport:Real Server port,后端真实服务器为rip提供服务的端口。
原VS/NAT工作模式下,LVS与后端的RS是两层互联,即LVS与RS处在同一个网段中并使用两层协议通信,相应的TCP交互流程如下:
1)Client端与LVS提供的vip、vport建立TCP连接;
2)LVS收到Client端发来的数据包后,进行DNAT(Destination NetworkAddress Translation,目的网络地址转换),把vip、vport转换为RS的rip和rport,然后转发给RS;
Client端发来的数据包中,源地址为cip,源端口为cport,目的地址为vip,目的端口为vport。经DNAT转换后的数据包为:源地址cip,源端口cport,目的地址rip,目的端口rport。
3)RS处理收到的报文,然后回复数据,数据包的源ip和port是RS的rip和rport,目的ip和port是Client的cip和cport;由于RS的默认路由设置为LVS的ip,所以RS发向Client的报文会被路由到LVS;
4)LVS收到RS发给Client的报文后,进行SNAT(Source Network AddressTranslation,源网络地址转换),把RS的rip和rport转换为LVS的vip和vport,然后发送给Client端。
基于图2所示的原VS/NAT工作模式,本申请所述的跨网段的LVS负载均衡工作模式如图3所示,其中:
Client表示客户端,LVS表示虚拟服务器,RS表示真实服务器,cip、cport、vip、vport、rip、rport的含义与图1和图2也相同。不同的是,图3中在LVS上还设定了bip和bport,含义如下:
bip:backend ip,LVS机器网卡上绑定的ip地址,用来与后端RS建立连接。
bport:backend port,backend ip可以使用的端口。
图3所示工作模式的基本工作原理是:LVS提供vip和vport供Client连接,连接成功后,LVS会使用bip和bport去和后端的RS建立连接,在后续的包交互过程中,LVS主要完成以下两个功能:
第一,session的维护:session中存放着vip、vport、bip和bport,分别用来关联LVS与Client之间的连接、LVS与RS之间的连接;
第二,在包转发的过程中进行SNAT和DNAT,以便发向Client和RS的数据包都有正确的源和目的ip、源和目的端口。
在图3所示工作模式下,本申请中跨网段的TCP交互流程如图4所示,与原VS/NAT工作模式下的TCP交互流程存在以下区别:
1)LVS在处理从Client发向RS的报文时,不只进行DNAT,还需要进行SNAT,把源ip和port修改为LVS上配置的bip和bport;
2)LVS在处理从RS发向Client的报文时,不只进行SNAT,还需要进行DNAT,把bip和bport修改为Client的cip和cport;
3)在发给RS的报文中添加一个自定义的tcp_option,在option中放置真实的客户端ip和port(cip、cport);
4)RS端加载自定义的TCP协议Hook模块,该模块会获取报文tcp_option中的客户端真实ip和port,以便返回给用户程序真实的Client ip和port。
上述区别中的3)和4)并不是实现本申请必须的,是一个可选步骤,如果无需向用户程序或其他调用程序返回客户端真实的ip和port,则无需进行3)和4)的处理。
综上所述,由上述内容可以看出,本申请可通过以下方法实现跨网段的LVS负载均衡。
参照图5,是本申请实施例所述一种服务器负载均衡方法的流程图。
LVS进行以下处理:
步骤501,配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
其中,第一虚拟地址及其端口如上述的vip和vport,第二虚拟地址及其端口如上述的bip和bport。
步骤502,当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
其中,客户端发来的数据包的源地址及源端口为cip和cport,将其转换为bip和bport;目的地址及目的端口为vip和vport,将其转换为rip和rport。
步骤503,当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
其中,真实服务器发来的数据包的源地址及源端口为rip和rport,将其转换为vip和vport;目的地址及目的端口为bip和bport,将其转换为cip和cport。
需要说明的是,上述步骤502和503没有先后顺序的限制。
基于图5,详细的实现流程如图6所示,具体如下:
本实施例的实现流程均在Netfilter(包过滤系统)的IP_LOCAL_INHOOK点,因为从Client发来的报文目的ip是vip,会走到IP_LOCAL_IN点,从RS发来的报文目的ip是bip,也会走到IP_LOCAL_IN。此时就可以根据目的ip是否为vip来区分是Out-In(处理从Client发向RS的报文)还是In-Out(处理从RS发向Client的报文)。
步骤S10,报文进入到LVS的IP_LOCAL_IN HOOK点进行处理;
步骤S11,判断接收到的数据包的目的ip是否为vip;
如果是,则为Out-In,转入步骤S12;如果否,则目的ip是bip,为In-Out,转入步骤S13;
同理,也可以判断接收到的数据包的目的端口,如果目的端口为所述第一虚拟地址的端口vport,则所述数据包是客户端发来的数据包;否则,目的端口为bport,是真实服务器发来的数据包。
以下S12至S26是Out-In流程:
步骤S12,根据cip、cport、vip和vport查询session;
如果查询到与所述四元组(cip、cport、vip和vport)对应的session,表示Client与对应的RS之间已经建立连接,转入步骤S22;如果未查询到,表示Client与对应的RS之间未建立连接,本次传输是该Client第一次与对应的RS建立连接,转入步骤S14。
其中,所述cip、cport是数据包的源地址、源端口,vip、vport是数据包的目的地址和目的端口。
步骤S14,判断是否需要新建连接;
一般的标准是检查是否是SYN包,如果是,转入步骤S16;如果否,返回NF_ACCEPT,退出处理。
步骤S16,选择RS;
即根据预定义的负载均衡策略选择一个与当前Client建立连接的RS,所述负载均衡策略可选用现有技术中的任何一种策略。选择成功后,转入步骤S18。
步骤S18,选择backend ip和port;
所述bip和bport用于LVS与S16选择的RS建立连接。本实施例中,backend ip是用户态的工具采用setsockopt的方式发送到内核中的,LVS会利用轮询的方式来选择backend ip和port。
步骤S20,创建session;
步骤S22,DNAT:将vip、vport转换为rip、rport;
步骤S24,SNAT:将cip、cport转换为bip、bport;
步骤S26,插入tcp_option,option中存放客户端的真实ip和port(cip、cport),进入IP_LOCAL_OUT点。
本步骤是可选步骤。
以下S13至S17是In-Out流程:
步骤S13,根据bip、bport、rip和rport查询session;
如果查询到与所述四元组(bip、bport、rip和rport)对应的session,表示RS与对应的Client之间已经建立连接,转入步骤S15;如果未查询到,表示RS与对应的Client之间未建立连接,返回NF_ACCEPT,退出处理。
步骤S15,SNAT:将rip、rport转换为vip、vport;
步骤S17,DNAT:将bip、bport转换为cip、cport,进入IP_LOCAL_OUT点。
上述流程中,如果选择执行步骤S26,则对应的RS中还需配置加载一个内核模块,在TCP协议中所述内核模块为Hook模块,用于在RS收到所述转换后的数据包后,通过解析获取客户端的真实ip及port。
在TCP协议中,Hook模块是通过Hook inet_stream_ops.getname与ipv4_specific.syn_recv_sock这两个函数实现。其中,通过Hookipv4_specific.syn_recv_sock函数,解析出Client ip与port并存入socket的sk_user_data中;通过Hook inet_stream_ops.getname函数,在应用层调用accet()、getpeername()时,返回sk_user_data中保存的Client ip与port。
参照图7,ipv4_specific.syn_recv_sock的Hook函数处理流程如下:
步骤701,调用原有的tcp_v4_syn_recv_sock函数创建sock;
步骤702,判断sock是否创建成功,并且sk_user_data是否为空;
如果是,则转入步骤703;如果否,则返回错误;
步骤703,解析报文中的tcp_option,解析出cip和cport,并放入sk_user_data中;
步骤704,返回socket。
相比于原有流程,只是添加了自定义tcp_option的解析。
参照图8,inet_stream_ops.getname Hook函数的处理流程如下:
步骤801,调用原有的inet_getname函数解析socket的相关信息;
步骤802,判断所述函数是否正常返回并且sk_user_data是否存在cip和cport信息;
如果是,则转入步骤803;如果否,则返回错误;
步骤803,从sk_user_data中解析出cip和cport信息,并更新上述调用的socket信息;
步骤804,返回调用结果。
相比于原有流程,只是添加了从sk_user_data中解析cip和cport的操作。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请所必须的。
综上所述,本申请实施例提供的LVS负载均衡方法在LVS和RS之间采用三层互联,进而为实现三层互联对LVS从客户端和真实服务器接收的数据包都进行源地址和目的地址的转换,从而使LVS能为更多个不同网段的RS服务。这种三层互联的方式实现了真正意义上的跨网段负载均衡,LVS上能够提供服务的RS数目不再受限制,因此可以扩展出层次化的网络拓扑。
更进一步分析,现有的DR模式是通过修改MAC的方式把数据包转发给RS,所以LVS工作在链路层,所以无法进行跨网段。原有的NAT模式仅仅修改Out-In报文的目的IP,并且RS回复的报文必须经过LVS以便进行地址转换,所以RS必须把默认网关指向LVS,而RS与默认网关必须在同一网段,此时LVS的角色类似RS上联的出口路由器,所以限制了LVS和RS必须在同一网段。而本申请提出的方式在Out-In时同时修改了源和目的IP,此时为了使RS回复的报文能经过LVS,只需要新的源IP和RS在内网中是三层互通的,这样RS回复的报文(目的IP是LVS的第二虚拟IP)就可以回到LVS以便进行地址转换,此时LVS的角色类似7层的负载均衡软件(HAProxy等),只不过是工作在内核中而已,因此可以实现跨网段的功能。
而且,本申请实施例所述方法还大大简化了LVS和RS的配置和运营维护,下面通过与其他方式相比较进行说明。
第一,背景技术中提到,在LVS的VS/DR和VS/NAT工作模式下,通过在LVS网卡上打tag的方式可以使LVS服务于多个网段的RS,但是这种方式的配置和运营维护十分复杂,这种复杂性体现在如下方面:
1)更改交换机端口工作模式的工作较为危险,容易导致网卡连接不上,增加运营维护成本:默认情况下,交换机端口工作在access模式,当需要更改为trunk模式时,需要首先修改服务器上的配置然后重启网络,再由运维部门同事修改端口工作模式。如果服务器上的配置修改有误,则工作模式修改后会导致网络无法连接,即使修改回原来的工作模式也不能正常连接,只能去现场操作,增加了运营维护的成本。
2)需要跨部门合作,步骤比较繁琐:首先要和业务部门同事确认后端RS所处的网段,再和运维部门同事确认该网段所处于的vlan,然后为每个vlan号配置网卡的tag设置。
3)后期的维护较为复杂:如果后端的RS由于机器搬迁或者其他原因更换了网段,需要重新确认vlan号,再重新设置网卡的tag设置。
第二,在原有的VS/TUN工作模式的基础上,LVS与后端RS经改造后也可以实现三层互联(跨多个网段)的功能,但是在该模式下,RS的配置较为复杂,体现在如下方面:
1)RS上需要建立tunnel设备,tunnel设备依赖于ipip模块(IPIP隧道协议是使用在两个路由器间对IP数据包进行封装的简单协议),因此需要为内核添加ipip模块的支持,另外RS的稳定性也会依赖于ipip的稳定性;
2)RS上需要为每个vip建立一个tunnel设备,同时配置tunnel设备的arp_annouce和arp_ignore选项,当vip较多时配置会较为繁琐,并且容易出错;
3)在修改vip时,容易出现忘记删除原tunnel设备及vip等问题,导致配置出错。
相比于上述两种方式,本申请不仅能够实现三层互联(跨多个网段)的功能,其配置和运营维护的简化性体现在以下方面:
1)LVS和RS只需要三层互通,大大简化了前端部署的难度,并有利于层次化地网络拓扑;
2)RS在接入LVS时只需要加载一个内核模块(Hook),不需要做其他任何修改;不需要为vip添加额外配置,只需要和LVS三层互通,易于部署和维护;
3)LVS不需要配置任何tag信息,简化了运营维护的复杂度。
基于上述方法实施例的说明,本申请还提供了相应的装置和系统实施例。
参照图9,是本申请实施例所述一种服务器负载均衡装置的结构图。
所述服务器负载均衡装置可设在LVS上运行,具体包括虚拟配置单元10、第一地址转换单元20和第二地址转换单元30,其中,
虚拟配置单元10,用于配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
第一地址转换单元20,用于当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
第二地址转换单元30,用于当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
可选的,所述服务器负载均衡装置还可以包括:
地址添加单元40,用于在所述第一地址转换单元20将转换后的数据包转发给真实服务器之前,在所述转换后的数据包中添加客户端的真实地址及其端口。
可选的,如果设置地址添加单元40,则所述服务器负载均衡装置还可以包括:
地址解析单元50,设在真实服务器上,用于真实服务器收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
优选的,所述服务器负载均衡装置还可以包括:
数据包判断单元60,用于判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
优选的,所述服务器负载均衡装置还可以包括:
第一查询单元70,用于根据客户端发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第一地址转换单元20;其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
优选的,如果未查询到,所述服务器负载均衡装置还可以包括:
连接建立单元80,用于判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后触发所述第一地址转换单元20;如果否,则退出。
优选的,所述服务器负载均衡装置还可以包括:
第二查询单元90,用于根据真实服务器发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第二地址转换单元30;如果未查询到,则退出;其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
对于上述装置实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
基于图9所示的服务器负载均衡装置,本申请实施例还提供了一种服务器负载均衡系统。所述服务器负载均衡系统主要包括虚拟服务器和与所述虚拟服务器相连的跨网段的多个真实服务器,其中所述虚拟服务器上可以设置上述虚拟配置单元10、第一地址转换单元20、第二地址转换单元30、地址添加单元40、数据包判断单元60、第一查询单元70、连接建立单元80、第二查询单元90,所述真实服务器上可以设置上述地址解析单元50。
上述服务器负载均衡装置及服务器负载均衡系统实现了一种全新的跨网段技术,可以使网络拓扑得到很大的改进,并简化了LVS和RS的配置,减少了运维的成本。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
而且,上文中的“和/或”表示本文既包含了“和”的关系,也包含了“或”的关系,其中:如果方案A与方案B是“和”的关系,则表示某实施例中可以同时包括方案A和方案B;如果方案A与方案B是“或”的关系,则表示某实施例中可以单独包括方案A,或者单独包括方案B。
以上对本申请所提供的一种服务器负载均衡方法、装置及系统,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。

Claims (16)

1.一种服务器负载均衡方法,其特征在于,包括:
配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
2.根据权利要求1所述的方法,其特征在于,所述将转换后的数据包转发给真实服务器之前,还包括:
在所述转换后的数据包中添加客户端的真实地址及其端口。
3.根据权利要求2所述的方法,其特征在于,还包括:
真实服务器收到所述转换后的数据包,通过解析获取客户端的真实地址及其端口。
4.根据权利要求1至3任一所述的方法,其特征在于,还包括:
判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
5.根据权利要求4所述的方法,其特征在于,当接收客户端发来的数据包时,所述转换之前还包括:
根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;
其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
6.根据权利要求5所述的方法,其特征在于,如果未查询到,还包括:
判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后进行所述的转换;如果否,则退出。
7.根据权利要求4所述的方法,其特征在于,当接收真实服务器发来的数据包时,所述转换之前还包括:
根据数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则进行所述的转换;如果未查询到,则退出;
其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
8.一种服务器负载均衡装置,其特征在于,包括:
虚拟配置单元,用于配置第一虚拟地址及其端口,和,第二虚拟地址及其端口,其中第一虚拟地址及其端口用于与客户端建立连接,第二虚拟地址及其端口用于与真实服务器建立连接;
第一地址转换单元,用于当接收客户端发来的数据包时,将该数据包中的源地址及源端口转换为第二虚拟地址及其端口,将该数据包的目的地址及目的端口转换为真实服务器的地址及其端口,然后将转换后的数据包转发给真实服务器;
第二地址转换单元,用于当接收真实服务器发来的数据包时,将该数据包中的源地址及源端口转换为第一虚拟地址及其端口,将该数据包的目的地址及目的端口转换为客户端的真实地址及其端口,然后将转换后的数据包转发给客户端。
9.根据权利要求8所述的装置,其特征在于,还包括:
地址添加单元,用于在所述第一地址转换单元将转换后的数据包转发给真实服务器之前,在所述转换后的数据包中添加客户端的真实地址及其端口。
10.根据权利要求8或9所述的装置,其特征在于,还包括:
数据包判断单元,用于判断接收到的数据包的目的地址或目的端口,如果目的地址为所述第一虚拟地址,或者,目的端口为所述第一虚拟地址的端口,则所述数据包是客户端发来的数据包;否则,是真实服务器发来的数据包。
11.根据权利要求10所述的装置,其特征在于,还包括:
第一查询单元,用于根据客户端发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第一地址转换单元;
其中,所述源地址和源端口为客户端真实的地址和端口,所述目的地址和目的端口为所述第一虚拟地址及其端口。
12.根据权利要求11所述的装置,其特征在于,如果未查询到,还包括:
连接建立单元,用于判断是否需要新建连接,如果是,则选择建立连接的真实服务器,并选择用于与所述真实服务器建立连接的第二虚拟地址及其端口,创建session,然后触发所述第一地址转换单元;如果否,则退出。
13.根据权利要求10所述的装置,其特征在于,还包括:
第二查询单元,用于根据真实服务器发来的数据包的源地址、源端口、目的地址和目的端口查询对应的session,如果查询到,则触发所述第二地址转换单元;如果未查询到,则退出;
其中,所述源地址和源端口为真实服务器的地址和端口,所述目的地址和目的端口为所述第二虚拟地址及其端口。
14.根据权利要求9所述的装置,其特征在于,还包括:
地址解析单元,设在真实服务器上,用于真实服务器收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
15.一种服务器负载均衡系统,其特征在于,包括:虚拟服务器和与之相连的真实服务器,所述虚拟服务器包括如上述权利要求8至13任一权利要求所述的服务器负载均衡装置。
16.根据权利要求15所述的系统,其特征在于,所述真实服务器还包括:
地址解析单元,用于收到所述转换后的数据包后,通过解析获取客户端的真实地址及其端口。
CN201110295820.4A 2011-09-27 2011-09-27 一种服务器负载均衡方法、装置及系统 Expired - Fee Related CN103023942B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201110295820.4A CN103023942B (zh) 2011-09-27 2011-09-27 一种服务器负载均衡方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201110295820.4A CN103023942B (zh) 2011-09-27 2011-09-27 一种服务器负载均衡方法、装置及系统

Publications (2)

Publication Number Publication Date
CN103023942A true CN103023942A (zh) 2013-04-03
CN103023942B CN103023942B (zh) 2016-08-03

Family

ID=47972070

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201110295820.4A Expired - Fee Related CN103023942B (zh) 2011-09-27 2011-09-27 一种服务器负载均衡方法、装置及系统

Country Status (1)

Country Link
CN (1) CN103023942B (zh)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103200120A (zh) * 2013-04-09 2013-07-10 杭州华三通信技术有限公司 一种直接路由方式下的报文转发方法和网络设备
CN103491007A (zh) * 2013-09-13 2014-01-01 新浪网技术(中国)有限公司 一种数据包传输方法及装置
CN103581360A (zh) * 2013-11-15 2014-02-12 广东睿江科技有限公司 一种基于Linux的Nat日志记录方法与装置
CN103618778A (zh) * 2013-11-21 2014-03-05 上海爱数软件有限公司 利用Linux虚拟主机实现数据高并发的系统及方法
CN103647692A (zh) * 2013-11-04 2014-03-19 北京奇虎科技有限公司 网络处理方法、设备及系统
CN103888316A (zh) * 2014-03-28 2014-06-25 宋磊 一种多网段多vlan中计算机网络自动化监控方法
CN104144096A (zh) * 2014-08-25 2014-11-12 深圳市中兴移动通信有限公司 虚拟网络层构建方法、装置及系统
CN104462488A (zh) * 2014-12-19 2015-03-25 北京奇虎科技有限公司 数据库的高可用解决方法和装置
CN104486402A (zh) * 2014-12-11 2015-04-01 江苏爱信诺航天信息科技有限公司 一种基于大型网站组合均衡的方法
CN104811383A (zh) * 2015-03-19 2015-07-29 杭州华三通信技术有限公司 一种报文转发方法和设备
CN105162896A (zh) * 2015-08-31 2015-12-16 上海斐讯数据通信技术有限公司 一种跨网段的设备通信方法及系统
CN105515979A (zh) * 2015-12-29 2016-04-20 新浪网技术(中国)有限公司 开放式最短路径优先ospf跨网均衡转发方法及系统
CN103581360B (zh) * 2013-11-15 2016-11-30 广东睿江云计算股份有限公司 一种基于Linux的Nat日志记录方法与装置
CN106411771A (zh) * 2016-09-09 2017-02-15 北京锐安科技有限公司 一种数据转发方法及系统
CN106572197A (zh) * 2015-10-10 2017-04-19 阿里巴巴集团控股有限公司 一种网络地址转换方法、装置及系统
WO2017133291A1 (zh) * 2016-02-02 2017-08-10 华为技术有限公司 一种基于服务器集群的报文生成方法和负载均衡器
CN108156008A (zh) * 2016-12-05 2018-06-12 北京国双科技有限公司 服务器的配置方法和装置
CN109088878A (zh) * 2018-09-03 2018-12-25 中新网络信息安全股份有限公司 一种抗拒绝云防护系统的报文处理方法
CN109729104A (zh) * 2019-03-19 2019-05-07 北京百度网讯科技有限公司 客户端源地址获取方法、装置、服务器和计算机可读介质
CN110399137A (zh) * 2019-06-18 2019-11-01 平安科技(深圳)有限公司 多活负载均衡应用的端口删除方法、装置、设备及存储介质
CN110708393A (zh) * 2019-10-21 2020-01-17 北京百度网讯科技有限公司 用于传输数据的方法、装置和系统
CN111131439A (zh) * 2019-12-20 2020-05-08 浪潮电子信息产业股份有限公司 基于iSCSI的报文传输方法、装置、设备及存储介质
CN111866064A (zh) * 2016-12-29 2020-10-30 华为技术有限公司 一种负载均衡的方法、装置和系统
CN112039801A (zh) * 2020-07-20 2020-12-04 厦门网宿有限公司 设置ip信息的方法、系统和代理服务器
US10911398B2 (en) 2016-02-02 2021-02-02 Huawei Technologies Co., Ltd. Packet generation method based on server cluster and load balancer
CN114640679A (zh) * 2022-03-14 2022-06-17 京东科技信息技术有限公司 数据包传输方法及装置、存储介质、电子设备

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1545275A (zh) * 2003-11-21 2004-11-10 清华大学深圳研究生院 基于Netfilter架构的流媒体集群服务内容调度方法
CN1992716A (zh) * 2005-12-31 2007-07-04 中兴通讯股份有限公司 一种在Linux协议栈上实现端口触发功能的方法
CN101262425A (zh) * 2008-04-28 2008-09-10 艾诺通信系统(苏州)有限责任公司 基于网络地址转换的多播转发的方法
CN101345711A (zh) * 2008-08-13 2009-01-14 成都市华为赛门铁克科技有限公司 一种报文处理方法、防火墙设备及网络安全系统
CN101442943A (zh) * 2004-11-08 2009-05-27 莫里斯·皮肖塔诺 包括存储治疗方案的治疗装置及相关方法
CN101577731A (zh) * 2009-06-15 2009-11-11 杭州华三通信技术有限公司 Tcp连接主备倒换和h323连接主备倒换的方法及装置
CN101729573A (zh) * 2009-12-18 2010-06-09 四川长虹电器股份有限公司 网络入侵检测的动态负载均衡方法
CN101753315A (zh) * 2008-11-27 2010-06-23 百度在线网络技术(北京)有限公司 DDoS攻击测试方法、装置和系统
CN101795238A (zh) * 2010-04-08 2010-08-04 福建星网锐捷网络有限公司 网络负载平衡的组网方法、设备及系统
CN102075445A (zh) * 2011-02-28 2011-05-25 杭州华三通信技术有限公司 负载均衡方法及装置
CN102255932A (zh) * 2010-05-20 2011-11-23 百度在线网络技术(北京)有限公司 负载均衡方法和负载均衡器

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1545275A (zh) * 2003-11-21 2004-11-10 清华大学深圳研究生院 基于Netfilter架构的流媒体集群服务内容调度方法
CN101442943A (zh) * 2004-11-08 2009-05-27 莫里斯·皮肖塔诺 包括存储治疗方案的治疗装置及相关方法
CN1992716A (zh) * 2005-12-31 2007-07-04 中兴通讯股份有限公司 一种在Linux协议栈上实现端口触发功能的方法
CN101262425A (zh) * 2008-04-28 2008-09-10 艾诺通信系统(苏州)有限责任公司 基于网络地址转换的多播转发的方法
CN101345711A (zh) * 2008-08-13 2009-01-14 成都市华为赛门铁克科技有限公司 一种报文处理方法、防火墙设备及网络安全系统
CN101753315A (zh) * 2008-11-27 2010-06-23 百度在线网络技术(北京)有限公司 DDoS攻击测试方法、装置和系统
CN101577731A (zh) * 2009-06-15 2009-11-11 杭州华三通信技术有限公司 Tcp连接主备倒换和h323连接主备倒换的方法及装置
CN101729573A (zh) * 2009-12-18 2010-06-09 四川长虹电器股份有限公司 网络入侵检测的动态负载均衡方法
CN101795238A (zh) * 2010-04-08 2010-08-04 福建星网锐捷网络有限公司 网络负载平衡的组网方法、设备及系统
CN102255932A (zh) * 2010-05-20 2011-11-23 百度在线网络技术(北京)有限公司 负载均衡方法和负载均衡器
CN102075445A (zh) * 2011-02-28 2011-05-25 杭州华三通信技术有限公司 负载均衡方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
邢小虎: "基于LVS的负载均衡架构的应用研究", 《电脑知识与技术(学术交流)》 *

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103200120A (zh) * 2013-04-09 2013-07-10 杭州华三通信技术有限公司 一种直接路由方式下的报文转发方法和网络设备
CN103200120B (zh) * 2013-04-09 2016-08-03 杭州华三通信技术有限公司 一种直接路由方式下的报文转发方法和网络设备
CN103491007A (zh) * 2013-09-13 2014-01-01 新浪网技术(中国)有限公司 一种数据包传输方法及装置
CN103491007B (zh) * 2013-09-13 2017-01-04 新浪网技术(中国)有限公司 一种数据包传输方法及装置
CN103647692A (zh) * 2013-11-04 2014-03-19 北京奇虎科技有限公司 网络处理方法、设备及系统
CN103581360B (zh) * 2013-11-15 2016-11-30 广东睿江云计算股份有限公司 一种基于Linux的Nat日志记录方法与装置
CN103581360A (zh) * 2013-11-15 2014-02-12 广东睿江科技有限公司 一种基于Linux的Nat日志记录方法与装置
CN103618778A (zh) * 2013-11-21 2014-03-05 上海爱数软件有限公司 利用Linux虚拟主机实现数据高并发的系统及方法
CN103888316A (zh) * 2014-03-28 2014-06-25 宋磊 一种多网段多vlan中计算机网络自动化监控方法
CN103888316B (zh) * 2014-03-28 2017-05-17 宋磊 一种多网段多vlan中计算机网络自动化监控方法
CN104144096A (zh) * 2014-08-25 2014-11-12 深圳市中兴移动通信有限公司 虚拟网络层构建方法、装置及系统
CN104486402A (zh) * 2014-12-11 2015-04-01 江苏爱信诺航天信息科技有限公司 一种基于大型网站组合均衡的方法
CN104486402B (zh) * 2014-12-11 2017-09-12 江苏爱信诺航天信息科技有限公司 一种基于大型网站组合均衡的方法
CN104462488A (zh) * 2014-12-19 2015-03-25 北京奇虎科技有限公司 数据库的高可用解决方法和装置
CN104462488B (zh) * 2014-12-19 2018-05-11 北京奇虎科技有限公司 数据库的高可用解决方法和装置
CN104811383A (zh) * 2015-03-19 2015-07-29 杭州华三通信技术有限公司 一种报文转发方法和设备
CN104811383B (zh) * 2015-03-19 2018-01-09 新华三技术有限公司 一种报文转发方法和设备
CN105162896A (zh) * 2015-08-31 2015-12-16 上海斐讯数据通信技术有限公司 一种跨网段的设备通信方法及系统
CN106572197A (zh) * 2015-10-10 2017-04-19 阿里巴巴集团控股有限公司 一种网络地址转换方法、装置及系统
CN106572197B (zh) * 2015-10-10 2020-01-14 阿里巴巴集团控股有限公司 一种网络地址转换方法、装置及系统
CN105515979A (zh) * 2015-12-29 2016-04-20 新浪网技术(中国)有限公司 开放式最短路径优先ospf跨网均衡转发方法及系统
CN105515979B (zh) * 2015-12-29 2019-05-21 新浪网技术(中国)有限公司 开放式最短路径优先ospf跨网均衡转发方法及系统
WO2017133291A1 (zh) * 2016-02-02 2017-08-10 华为技术有限公司 一种基于服务器集群的报文生成方法和负载均衡器
US10911398B2 (en) 2016-02-02 2021-02-02 Huawei Technologies Co., Ltd. Packet generation method based on server cluster and load balancer
CN106411771A (zh) * 2016-09-09 2017-02-15 北京锐安科技有限公司 一种数据转发方法及系统
CN108156008A (zh) * 2016-12-05 2018-06-12 北京国双科技有限公司 服务器的配置方法和装置
CN108156008B (zh) * 2016-12-05 2021-03-26 北京国双科技有限公司 服务器的配置方法和装置
CN111866064A (zh) * 2016-12-29 2020-10-30 华为技术有限公司 一种负载均衡的方法、装置和系统
US11265368B2 (en) 2016-12-29 2022-03-01 Huawei Technologies Co., Ltd. Load balancing method, apparatus, and system
CN111866064B (zh) * 2016-12-29 2021-12-28 华为技术有限公司 一种负载均衡的方法、装置和系统
CN109088878A (zh) * 2018-09-03 2018-12-25 中新网络信息安全股份有限公司 一种抗拒绝云防护系统的报文处理方法
CN109729104A (zh) * 2019-03-19 2019-05-07 北京百度网讯科技有限公司 客户端源地址获取方法、装置、服务器和计算机可读介质
CN110399137A (zh) * 2019-06-18 2019-11-01 平安科技(深圳)有限公司 多活负载均衡应用的端口删除方法、装置、设备及存储介质
CN110708393A (zh) * 2019-10-21 2020-01-17 北京百度网讯科技有限公司 用于传输数据的方法、装置和系统
US11483382B2 (en) 2019-10-21 2022-10-25 Beijing Baidu Netcom Science And Technology Co., Ltd. Method, apparatus and system for transmitting data
CN110708393B (zh) * 2019-10-21 2023-11-21 北京百度网讯科技有限公司 用于传输数据的方法、装置和系统
CN111131439A (zh) * 2019-12-20 2020-05-08 浪潮电子信息产业股份有限公司 基于iSCSI的报文传输方法、装置、设备及存储介质
CN112039801A (zh) * 2020-07-20 2020-12-04 厦门网宿有限公司 设置ip信息的方法、系统和代理服务器
CN112039801B (zh) * 2020-07-20 2022-12-20 厦门网宿有限公司 设置ip信息的方法、系统和代理服务器
CN114640679A (zh) * 2022-03-14 2022-06-17 京东科技信息技术有限公司 数据包传输方法及装置、存储介质、电子设备

Also Published As

Publication number Publication date
CN103023942B (zh) 2016-08-03

Similar Documents

Publication Publication Date Title
CN103023942B (zh) 一种服务器负载均衡方法、装置及系统
KR102138619B1 (ko) 서버 클러스터에 기초한 메시지 생성 방법 및 부하 균형기
EP3225014B1 (en) Source ip address transparency systems and methods
US5999974A (en) Internet protocol assists for high performance LAN connections
CN105554065B (zh) 处理报文的方法、转换单元和应用单元
CN100521663C (zh) 点对点通信中穿越网络地址转换的方法
EP3213467B1 (en) Multi-tenant networking
CN104246700A (zh) 用于基于胖树路由在不同无限带宽子网间路由流量的系统和方法
CN102577256A (zh) 在虚拟化网络基础设施情况下用于透明云计算的方法和设备
CN101150502A (zh) 一种nat-pt设备及其负荷分担方法
CN104104614A (zh) 命名数据网络中的软件定义网络控制器系统及其方法
CN101707569B (zh) Nat业务报文处理的方法及装置
CN106302225A (zh) 一种服务器负载均衡的方法与装置
US6023734A (en) Establishing direct communications between two hosts without using a high performance LAN connection
CN106506700A (zh) 一种负载均衡器的透明代理方法及负载均衡系统
CN101827039B (zh) 一种负载分担的方法和设备
CN102571947A (zh) 一种代理处理数据的方法、装置和系统
CN107181691B (zh) 一种网络中实现报文路由的方法、设备和系统
CN106936680B (zh) 云计算平台异构网络之间互通的系统及方法
CN110099115A (zh) 一种透明调度转发的负载均衡方法及系统
CN105282191A (zh) 负载均衡系统、控制器和方法
CN110099076A (zh) 一种镜像拉取的方法及其系统
CN106878457A (zh) 分布式网络附属存储方法及系统
CN104618243A (zh) 路由方法、装置及系统、网关调度方法及装置
CN108023736A (zh) 通信方法、服务端设备、客户端设备、装置及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C41 Transfer of patent application or patent right or utility model
TA01 Transfer of patent application right

Effective date of registration: 20160606

Address after: 100088 Beijing city Xicheng District xinjiekouwai Street 28, block D room 112 (Desheng Park)

Applicant after: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Applicant after: Qizhi software (Beijing) Co.,Ltd.

Address before: The 4 layer 100016 unit of Beijing city Chaoyang District Jiuxianqiao Road No. 14 Building C

Applicant before: Qizhi software (Beijing) Co.,Ltd.

C14 Grant of patent or utility model
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20160803

Termination date: 20210927