- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
H3C国产化应用交付安全网关产品
技术白皮书V2.0
|
Copyright ©2024 新华三技术有限公司 版权所有，保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部， 并不得以任何形式传播。本文档中的信息可能变动，恕不另行通知。 |
|
2.4.1 client-密文-SSLo-明文-安全资源池-SSLo-密文-server
2.4.2 client-明文-SSLo-明文-安全资源池-SSLo-明文-server
2.4.3 client-密文-SSLo-明文-安全资源池-SSLo-明文-server
2.4.4 内网用户-SSLo-安全资源池-SSLo-链路负载-公网服务器
LB（Load Balance，负载均衡）是一种集群技术，它将特定的业务（网络服务、网络流量等）分担给多台网络设备（包括服务器、防火墙等）或多条链路，从而提高了业务处理能力，保证了业务的高可靠性。
负载均衡技术可分为以下几种类型：
服务器负载均衡：在数据中心等组网中，通过此技术可将网络服务分担给多台服务器或防火墙进行处理，从而提高服务器或防火墙的处理能力。
链路负载均衡：当存在多条运营商链路时，通过此技术可实现链路的动态选择，从而充分利用多条链路。链路负载均衡支持IPv4与IPv6，但不支持IPv4报文与IPv6报文的互相转换。根据数据的连接请求方向不同，链路负载均衡又分为以下三种：
1. 出方向链路负载均衡：当内网用户访问外部互联网存在多条链路时，可在多条链路上分担内网用户访问外部互联网的流量。
2. DNS透明代理：当内网用户访问外网DNS服务器存在多条链路时，可在多条链路上分担内网用户访问外部DNS服务器的流量。
3. 入方向链路负载均衡：当外网用户访问内网服务器存在多条链路时，可在多条链路上分担外网用户访问内网服务器的流量。
GLB（Global Load Balance，全局负载均衡）：主要应用在多数据中心的场景。通过应用全局负载均衡技术可以使互联网用户接入距离最近的数据中心，提升用户体验；也可以在多个数据中心之间进行远程灾备，当某个数据中心发生故障时，全局负载均衡技术可将流量引流致其他数据中心进行处理，从而提高服务的可靠性。
随着计算机普及和互联网的快速发展，越来越多的人开始使用网络。以往只靠单台服务器就能满足用户的服务需求，随着用户访问人数增多，性能渐渐开始下降，对于用户的直观感受是响应慢、长时间处于等待服务器的过程中、最终完全没有反应，极大的影响了用户体验。
解决上述问题的一种方法是纵向扩展，选择购买一台配置更高的服务器来代替当前服务器。但是这种方法的弊端在于单台高性能的服务器比较昂贵，同样单台高性能服务器也存在性能瓶颈。
另外一种方法是进行横向扩展，提供多台相对价格便宜的服务器，通过某种技术将用户的服务请求分担给这些服务器，并且让用户觉得每次的访问只是对一台服务器进行访问。这种技术就是服务器负载均衡。对比两种方案，横向扩展具有较高的性价比，随着业务发展和用户的增多，只需要增加更多的服务器就能够应对，具有较高的可扩展性。
信息时代，人们的日常工作和生活越来越离不开网络，为了规避运营商出口故障带来的网络可用性风险并解决网络带宽不足带来的网络访问问题，企业和高校往往会租用两个或多个运营商出口（移动、联通、电信等）。如何合理运用多个运营商出口，既不造成资源浪费，又能更好的服务于客户，传统的策略路由可以在一定程度上解决该问题，但是策略路由配置不方便，而且不够灵活，无法动态适应网络结构变化，且策略路由无法根据带宽进行报文分发，造成高吞吐量的链路无法得到充分利用。链路负载均衡技术通过动态算法，能够在多条链路中进行负载均衡，算法配置简单，且具有自适应性，能很好的解决上述问题。
普通DNS服务器算法简单，主要基于轮询方式进行流量分配。例如，地区A的ISP1的用户实际上可能解析出地区B的ISP2的地址，影响用户体验。另外普通DNS服务器没有检测手段，无法感知到灾难的发生。可能出现某数据中心的服务设备故障后，仍然解析到该地址。全局负载均衡技术是基于DNS解析技术实现的。主要解决普通DNS服务器的以上两个问题，GLB（Global Load Balance，全局负载均衡）设备充当DNS服务器对收到的DNS请求报文进行解析。设备根据调度算法对所有数据中心下提供同一服务的虚服务器进行统一调度，将最优的虚服务器地址作为解析结果返回给用户。设备根据健康检测方法，实时检测所有虚服务器的状态，当检测到某虚服务器发生故障时，该虚服务器不再参与调度。
负载均衡具有以下技术优点：
· 高性能：通过将业务较均衡地分配到多台服务器上，提高了系统的整体性能。
· 可扩展性：可以方便地增加集群中服务器的数量，在不降低业务质量的前提下满足不断增长的业务需求。
· 高可靠性：单个甚至多个服务器发生故障也不会导致业务中断，提高了系统的整体可靠性。
· 可管理性：大量的管理工作都集中在应用了负载均衡技术的设备上，集群中的服务器只需要进行普通的配置和维护。
· 透明性：对用户而言，集群等同于一个可靠性高、性能好的服务器，用户感知不到也不必关心具体的网络结构。增减集群中的服务器不会影响正常业务。
服务器负载均衡技术属于负载均衡技术中的一种，其基本原理如图1所示。图1中客户端首先通过网络访问虚服务器，接着服务器负载均衡技术根据用户的配置，将客户端的请求转发给实服务组，最后由实服务组根据用户配置的调度算法选择一台具体的实服务器去响应客户端请求。
根据识别信息的层级不同，服务器负载均衡可以分为四层服务器负载均衡和七层服务器负载均衡。
图1 服务器负载均衡原理图
四层服务器负载均衡主要用于识别网络层和传输层信息。它是基于流的负载均衡，通过对报文进行逐流分发，将同一条流的报文分发给同一台服务器。由于四层服务器负载均衡对七层业务无法按内容分发，从而限制了其适用范围。
七层负载均衡，也称为“内容交换”，也就是主要通过报文中的应用层信息（URL、HTTP头部等信息），再加上负载均衡算法，决定最终选择的内部服务器。
七层负载均衡是基于应用层报文内容的负载均衡，它在四层负载均衡的基础上，再分析应用层的特征，比如一个Web服务器的负载均衡，如图2所示，除了根据地址和端口决定是否需要处理流量，还根据七层的URL、首部、报文体、Cookie等信息决定是否要进行负载均衡，如何进行负载均衡。并根据实际组网的需要，进行报文内容的深度改写，以实现报文跟踪、内容过滤、定向代答等功能。
七层负载均衡具有如下几个重要特点：
七层负载均衡的应用以HTTP协议为主。
七层负载均衡算法需要识别URL、Cookie和HTTP head等信息，算法计算程度更丰富。
可靠性强，包括保证服务器访问的完整性和连续性，以及保证网络的稳定。
提供可靠的网络安全防护。
图2 基于内容的七层服务器负载均衡
内网和外网之间存在多条链路时，通过Outbound链路负载均衡可以实现在多条链路上分担内网用户访问外网服务器的流量。Outbound链路负载均衡的典型组网如图3所示。
图3 Outbound链路负载均衡组网图
Outbound链路负载均衡包括以下几个基本元素：
· LB device：负责将内网到外网流量分发到多条物理链路的设备。
· 物理链路：运营商提供的实际链路（图中ISP1、ISP2、ISP3所属链路）。
· VSIP：对内提供的虚服务IP，因为外网地址不确定，该ip通常为0。
Outbound链路负载均衡中VSIP为内网用户发送报文的目的网段。用户将访问VSIP的报文发送到负载均衡设备后，负载均衡设备依次根据持续性功能、ACL策略、就近性算法、调度算法选择最佳的物理链路，并将内网访问外网的业务流量分发到该链路。Outbound链路负载均衡工作流程见图4。
图4 Outbound链路负载均衡流程图
表1 Outbound 链路负载均衡流程描述
|
步骤 |
描述 |
|
(1) |
负载均衡设备接收来自内网服务器的流量 |
|
(2) |
负载均衡设备依次根据负载均衡策略、持续性方法、就近性算法、调度算法（通常使用带宽算法或最大带宽算法）来选择最佳链路 |
|
(3) |
负载均衡设备通过选定的最佳链路将流量转发给外网服务器 |
|
(4) |
负载均衡设备接收来自外网服务器的流量 |
|
(5) |
负载均衡设备将流量转发给内网服务器 |
Outbound链路负载均衡技术特点
· 可以和 NAT 应用网关共同组网，不同的链路使用不同的源地址，从而保证往返报文穿过同一条链路。
· 通过健康性检测，可以检查链路内任意节点的连通性，从而有效保证整条路径的可达性。
· 通过调度算法，在多条链路间均衡流量，并支持按照带宽进行负载均衡。
· 利用就近性算法动态计算链路的质量，将流量分发到当前最优链路上。
· 通过带宽繁忙保护功能，当流量超过某条链路的带宽繁忙比后，新建流量（非匹配持续性流量）将不再向该链路分发，而原有的流量则仍由该链路继续分发。
内网和外网之间存在多条链路时，通过Inbound链路负载均衡可以实现在多条链路上分担外网用户访问内网服务器的流量。Inbound链路负载均衡的典型组网如图5所示。
图5 Inbound链路负载均衡组网图
Inbound链路负载均衡包括以下几个基本元素：
· LB device：负责引导外网流量通过不同物理链路转发到内网，从而实现流量在多条物理链路上分担的设备。同时，LB device 还需要作为待解析域名的权威名称服务器。
· 物理链路：运营商提供的实际链路（图中ISP1、ISP2、ISP3所属链路）。
· 本地 DNS 服务器：负责解析外网用户发送的DNS 请求、并将该请求转发给权威名称服务器——LB device。
Inbound链路负载均衡中，负载均衡设备作为权威名称服务器记录域名与内网服务器IP地址的映射关系。一个域名可以映射为多个IP地址，其中每个IP地址对应一条物理链路。
外网用户通过域名方式访问内网服务器时，本地DNS服务器将域名解析请求转发给权威名称服务器——负载均衡设备，负载均衡设备依次根据持续性功能、ACL策略、就近性算法选择最佳的物理链路，并将通过该链路与外网连接的接口IP地址作为DNS域名解析结果反馈给外网用户，外网用户通过该链路访问内网服务器。
负载均衡设备作为权威域名解析服务器支持解析的记录类型为：A、MX、SOA、NS、CNAME、PTR、TXT、SRV等解析类型。
Inbound链路负载均衡工作流程见图6。
图6 Inbound链路负载均衡流程图
表2 Inbound 链路负载均衡流程描述
|
步骤 |
描述 |
|
(1) |
Client host向本地DNS服务器发起DNS请求 |
|
(2) |
本地DNS服务器向负载均衡设备发起DNS请求 |
|
(3) |
链路负载均衡设备根据调度算法、带宽限制、健康性检测等负载均衡调度方式来选择最佳链路对应的虚服务器 |
|
(4) |
负载均衡设备将选定的虚服务器地址通过DNS响应报文发送给发起请求的本地DNS服务器 |
|
(5) |
本地DNS服务器把获取的虚服务器地址发送给Client host |
|
(6) |
Client host向虚服务器地址发起连接请求（请求进入负载均衡设备） |
|
(7) |
负载均衡设备向内网服务器发起连接请求 |
|
(8) |
内网服务器应答负载均衡设备 |
|
(9) |
负载均衡设备应答Client host |
Inbound链路负载均衡技术特点
· 可以和服务器负载均衡配合适用，实现外网用户访问内网服务器流量在多条链路间均衡的同时，也实现了流量在多台服务器间均衡。
· 通过健康性检测，可以检查链路内任意节点的连通性，从而有效保证整条路径的可达性。
· 利用就近性算法动态计算链路的质量，保证转发流量的链路是当前最优的链路。
全局负载均衡技术是基于DNS解析技术实现的。主要解决普通DNS服务器的两个问题：
普通DNS服务器算法简单，主要基于轮询方式进行流量分配。例如，地区A的ISP1的用户实际上可能解析出地区B的ISP2的地址，影响用户体验。
普通DNS服务器没有检测手段，无法感知到灾难的发生。可能出现某数据中心的服务设备故障后，仍然解析到该地址。
GLB（Global Load Balance，全局负载均衡）设备充当DNS服务器对收到的DNS请求报文进行解析。设备根据调度算法对所有数据中心下提供同一服务的虚服务器进行统一调度，将最优的虚服务器地址作为解析结果返回给用户。设备根据健康检测方法，实时检测所有虚服务器的状态，当检测到某虚服务器发生故障时，该虚服务器不再参与调度。
在实际应用中，全局负载均衡需要配合服务器负载均衡实现。全局负载均衡在多个数据中心之间进行全局调度，选出最优的数据中心。服务器负载均衡则在各个数据中心内部进行本地调度，选择最优的实服务器。
GLB设备和本地SLB（Server Load Balance，服务器负载均衡）设备支持集中部署和分布部署两种部署模式，根据实际需求选择合适的部署方式即可。
集中部署是指全局负载均衡功能与服务器负载均衡功能在同一台设备上进行配置。GLB设备既提供全局负载均衡服务，又提供服务器负载均衡服务。
分布部署是指全局负载均衡功能与服务器负载均衡功能分别配置在GLB设备和本地SLB设备上。由GLB设备提供全局负载均衡服务，本地SLB设备提供服务器负载均衡服务。全局负载均衡工作流程见图7。
图7 全局负载均衡流程图
|
步骤 |
描述 |
源IP地址 |
目的IP地址 |
|
① |
Host向Local DNS服务器发送DNS请求 |
Host IP |
Local DNS |
|
② |
Local DNS服务器向查询到的GLB设备发起DNS请求 |
Local DNS |
GLB |
|
③ |
GLB设备收到DNS请求后，根据调度算法在所有全局虚服务器池中选取最优的全局虚服务器池，再根据全局虚服务器池中指定的调度算法从该虚服务器池下的所有可用虚服务器中选取出最优的虚服务器 |
-- |
-- |
|
④ |
GLB设备将选定的最优虚服务器地址通过DNS响应报文发送给发起请求的Local DNS服务器 |
GLB |
Local DNS |
|
⑤ |
Local DNS服务器把获取的虚服务器地址发送给Host |
Local DNS |
Host IP |
|
⑥ |
Host向选定的虚服务器地址发起连接请求 |
Host IP |
VSIP |
若部署模式为分布部署，则步骤⑥中Host发送的请求不再经过GLB设备，而是直接到达SLB设备进行后续处理。
随着网络的发展，现代互联网已经步入全网加密时代(HTTPS)。 在数据中心互联网接入区中，通常部署有FW、IPS、WAF等安全设备，这些安全设备在互联网业务时代，通常存在如下痛点：
l 主备模式部署的安全设备，始终有一台设备处于备份状态，导致安全设备资源利用率低。
l 传统安全设备在处理SSL流量的时候存在无法进行SSL加解密或SSL加解密性能差等问题，导致业务存在安全盲点。
l 传统网络架构中的众多安全设备仍旧采用糖葫芦串部署模式，扩展性不强，存在整体稳定性低和故障点多等问题。
为了解决这些痛点问题， H3C提出了流量编排技术方案，该方案可以有效解决互联网业务时代，传统网络架构中，由于安全设备而产生的这些痛点问题。
此外在互联网收敛场景下，出口建设随着收敛进度带宽不断增加，流量编排技术亦可建成可按需扩展的互联网接入出口，实现以下特性：
l 安全设备资源池化，提升资源利用率，实现弹性伸缩。
l 提供健康监测功能， 流量编排设备识别到安全设备资源池中的安全设备宕机时，自动切换到正常运行的安全设备上面；在安全设备资源池中安全设备整体故障时， 流量编排设备可实现流量bypass，提升整体架构高可用性。
l 针对安全设备，提供流量编排能力，自定义安全服务链，编排不同的业务流量经过不同的安全服务链，实现业务流量的针对性防护，提升安全设备的利用率。
l 满足溯源需求，流量通过设备时，具有不改变端源地址或者通过插入XFF透传源IP地址的技术能力。
l 提供整体数据流的SSL加解密能力，实现SSL数据流可视化。
图8 流量编排组网图
客户端和后台服务器采用https协议，能够进行SSL加解密，但是对于ssl安全性和灵活性不足，需要依靠负载和公网客户端进行ssl握手，然后将解密的明文http流量调度到安全资源池进行安全检测和审计，最后再将明文的http流量进行加密转发给后端真实服务器。
流量示意图场景一：Client-密文-SSLo-明文-安全资源池-SSLo-密文-Server
客户业务系统自身提供的HTTP协议的服务，从客户端到SSLo再到安全资源池再到服务端，全程都是明文流量，所以，SSLo只需要进行流量编排即可。
流量示意图场景二：Client-明文-SSLo-明文-安全资源池-SSLo-明文-Server
客户业务系统采用HTTP协议，明文流量传输，其受到安全合规等要求，但又无法及时方便的再服务端进行HTTP到HTTPS的改造，此时可以利用SSLo设备进行证书加解密，保证公网访问过来的流量是HTTPS加密的，SSLo设备进行解密后调度到对应的安全资源池进行检测和审计，最后再转发给后端真实服务器。
流量示意图场景三：Client-密文-SSLo-明文-安全资源池-SSLo-明文-Server
对于企业办公网来说，常常在链路上串接各种安全设备，这样部署，设备利用率低，故障风险高，所以可以利用SSLo设备对用户上网流量进行编排，调度到对应的安全资源池内进行上网安全防护，更加灵活高效。
流量示意图场景四：内网用户-SSLo-安全资源池-SSLo-链路负载 –公网服务器
H3C LB产品基于业界领先的Uniware 网络操作系统，该系统基于Linux内核，采用模块化的设计，支持多核SMP(Symmetrical Multi-Processing对称多处理)模型的非对称应用。其架构在多核，多进程、一体化管理、高可用性等关键技术上有很好的支持。
控制核上可以接收和处理达到本设备的控制报文，运行各种控制协议。数据核支持报文转发和安全业务处理。
数据核支持报文转发和安全业务处理。由于数据核能并行支持报文转发和处理，从而实现了转发和业务处理性能的最大化。
整个系统无论是控制平面还是数据平面，都采用了对称多处理的模型，因此能很好的实现性能的扩展。
采用先进的多核多线程硬件平台，能够并行处理健康检测，负载均衡调度以及安全、路由等功能，并利用快转技术，做到一次运算多次转发，实现了高性能的负载均衡及安全防护功能。本身自带有丰富的接口以及扩展槽位，可适应用户针对现网部署设备硬件端口的所有要求。
支持N:1,1:N,N:1:M虚拟化，实现多台设备虚拟成一台N:1，之后再将整体虚成多台虚拟单元，“一虚多再多虚一”，在业务部署中满足了用户丰富的虚拟化使用要求。
支持丰富的健康检测算法，可从网络层、应用层全方位的探测、检查服务器及应用的运行状态。在进行健康检测时，采用H3C公司NQA（Network Quality Analyzer，网络质量分析）技术，确保健康检测占用最小的系统资源开销，从而保证应用交付业务的性能。健康检测算法适用于4～7层服务器负载均衡。
支持出站、入站链路负载均衡，结合内置的全球ISP IP地址库进行出、入站流量的智能调度，实现基于不同运营商、链路健康度、链路带宽大小等多要素的链路负载均衡。最终达成内、外网访问用户整体访问体验的提升以及多链路带宽资源的互为备份与合理利用。
支持L4和L7的服务器负载均衡。4层服务器负载均衡：基于TCP、UDP、IP的各种业务应用，依据报文的L4层特征（IP、端口）进行负载均衡。7层服务器负载均衡：基于L7内容的负载均衡，通过对报文承载的内容进行深度解析，根据应用层的分析结果对报文进行处理或者分发。支持基于HTTP header、HTTP URL、HTTP cookie以及HTTP content的解析，并在此基础上，配置所需要的L7策略，对HTTP报文进行分发和会话的持续性保持。
支持SSL卸载功能，将访问内网服务器中的SSL加解密过程由应用交付设备承担，LB产品与服务器之间可采用非加密或者弱加密的SSL进行通讯，极大的减小了服务器端对SSL处理的压力，从而将服务器的CPU处理能力释放出来。
支持47种SSL加密算法套件，其中国密加密算法套件10种，国际加密算法37种。
支持的国密加密算法套件包括：
dhe_rsa_aes_128_cbc_sha ，dhe_rsa_aes_128_cbc_sha256 ，dhe_rsa_aes_128_gcm_sha256 ，dhe_rsa_aes_256_cbc_sha ，dhe_rsa_aes_256_cbc_sha256，dhe_rsa_aes_256_gcm_sha384,dhe_rsa_camellia_128_cbc_sha,dhe_rsa_camellia_256_cbc_sha, ecdhe_ecdsa_aes_128_cbc_sha ,ecdhe_ecdsa_aes_128_cbc_sha256 ,ecdhe_ecdsa_aes_128_gcm_sha256,ecdhe_ecdsa_aes_256_cbc_sha ,ecdhe_ecdsa_aes_256_cbc_sha384 ,ecdhe_ecdsa_aes_256_gcm_sha384,ecdhe_rsa_aes_128_cbc_sha ,ecdhe_rsa_aes_128_cbc_sha256 ,ecdhe_rsa_aes_128_gcm_sha256,ecdhe_rsa_aes_256_cbc_sha,ecdhe_rsa_aes_256_cbc_sha384,ecdhe_rsa_aes_256_gcm_sha384 ,rsa_3des_ede_cbc_sha ,rsa_aes_128_cbc_sha, rsa_aes_128_cbc_sha256,
rsa_aes_128_gcm_sha256 ,rsa_aes_256_cbc_sha ,rsa_aes_256_cbc_sha256
rsa_aes_256_gcm_sha384,rsa_camellia_128_cbc_sha, rsa_camellia_256_cbc_sha
rsa_des_cbc_sha ,rsa_rc4_128_md5 ,rsa_rc4_128_sha,tls_aes_128_ccm_sha256
tls_aes_128_ccm_8_sha256 ,tls_aes_128_gcm_sha256 , tls_aes_256_gcm_sha384
tls_chacha20_poly1305_sha256
支持的国际加密算法套件包括：
ecc_sm2_sm1_sm3 , ecc_sm2_sm4_gcm_sm3, ecc_sm2_sm4_sm3, ecdhe_sm2_sm1_sm3 ,ecdhe_sm2_sm4_gcm_sm3 ,ecdhe_sm2_sm4_sm3 , ,rsa_sm1_sha,
rsa_sm1_sm3 ,rsa_sm4_sha ,rsa_sm4_sm3
支持丰富的负载均衡调度算法，可根据具体的应用场景，采用不同的算法。支持的算法包括：轮询、加权轮询、最小连接、加权最小连接、基于成员的最小连接、基于成员的最小时间、随机、源地址哈希、目的地址哈希、源地址端口哈希、源IP地址CARP哈希、目的IP地址CARP哈希、源IP地址和端口CARP哈希、HTTP哈希、HTTP CARP哈希、动态反馈等算法。以上负载均衡算法适用于4～7层服务器负载均衡，同时，对于7层服务器负载均衡还支持基于应用特征的分发，例如基于HTTP头域、内容等。
根据服务器的不同处理能力，给配置高、负载低的机器配置较高权值，让其处理更多的请求，而给配置低、负载高的机器分配较低的权值，降低服务器负载。具体调度过程如图7所示，黄色带数字的圆圈代表客户端请求。从图7中可以看出，高性能服务器处理更多的客户端请求，低性能服务器处理少量的客户端请求。
加权轮转算法能确保高性能服务器得到更多的使用率，避免低性能的服务器负载过重。
图7 加权轮转算法调度过程
通过系统的随机算法，根据后端服务器的列表大小值随机选取其中一台服务器进行访问，根据概率统计理论可以得知其实际效果越来越接近于平均分配调用量至后端的每一台服务器。具体调度如图8所示，黄色带数字的圆圈代表客户端请求。从图8中可以看出，客户端请求被随机的分配给后端的服务器去处理。
随机算法适用于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
图8随机算法调度过程
客户端的每一次请求服务在服务器停留的时间可能有较大的差异，随着工作时间的加长，如果采用简单的轮转或随机算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。
最少连接算法对内部中需要进行负载均衡处理的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，把当前请求分配给连接数最少的服务器。具体调度如图9所示，黄色带数字的圆圈代表客户端请求。从图9中可以看出，连接数最少的服务器处理的客户端请求最多。
最少连接算法使负载均衡更加符合实际情况，负载更加均衡，此种算法适合长时处理的服务请求，如FTP。
图9 最少连接算法调度过程
源IP哈希算法就是将客户端发起请求的源IP地址做哈希散列，并依据哈希的结果将请求映射到一台真实服务器上。源IP哈希算法的思想就是根据客户端的源IP地址进行哈希，通过哈希函数计算得到一个数值，用该数值对服务器节点数进行取模映射，得到的结果便是用户要访问的服务器。采用源IP哈希算法进行负载均衡，同一源IP地址的客户端，当后端的服务器不变时，它每次都会映射到同一台后端服务器进行访问。
适用场景：
源IP哈希算法适用于同一源IP地址发起的请求必须要调度到相同真实服务器的情况，多用于应用本身对请求的源IP地址有要求的环境。
源IP加端口哈希算法就是将客户端发起请求的源IP地址加端口做哈希散列，并依据哈希的结果将请求映射到一台真实服务器上。源IP和端口哈希算法的思想就是根据客户端的源IP地址和端口进行哈希，通过哈希函数计算得到一个数值，用该数值对服务器节点数进行取模映射，得到的结果便是用户要访问的服务器。采用源IP和端口哈希算法进行负载均衡，同一源IP地址和端口的客户端，当后端的服务器不变时，它每次都会映射到同一台后端服务器进行访问。
适用场景：
源IP和端口哈希算法适用于同一源IP地址和端口发起的请求必须要调度到相同真实服务器的情况，多用于应用本身对请求的源IP地址和端口有要求的环境。
CARP（Cache Array Routing Protocol，缓存阵列路由协议）哈希算法是在哈希算法的基础上进行了改进。当可用的实服务器数量发生变化时，采用CARP哈希算法，可使当前所有可用实服务器负载分担变动最小。设备支持配置基于源IP地址、源IP地址及端口、目的IP地址和HTTP载荷进行的CARP哈希算法。
源IP CARP哈希算法就是基于源IP地址进行的CARP哈希算法，通常由于各种外在的因素，后台的服务器都有可能失效，并且新的服务器很可能动态的增加进来，如何保证当后台服务器的数目发生变化时仍然能够对外提供良好的服务，即同一源IP地址的客户端发起的请求仍被调度到相同后台真实服务器或者负载分担变动最小，此时基于源IP地址进行的CARP哈希算法显得至关重要。基于源IP地址进行的CARP哈希算法就是客户端在请求某一服务时，将客户端发起请求的源IP地址做一致性哈希散列，这样就可以保证每次哈希出来的结果变动最小，即负载分担到后台的服务器结果变动最小。
采用源IP CARP哈希算法进行负载均衡，同一源IP地址的客户端，当后端的服务器不变时，它每次都会映射到同一台后端服务器进行访问，当后端的服务器变化时，每次哈希到后台的服务器结果也会变动的最小。
适用场景：
源IP CARP哈希算法适用于应用本身对请求的源IP地址有要求的环境，同一源IP地址的客户端发起的请求访问，当可用的实服务器数量发生变化时，采用源IP CARP哈希算法，可使当前所有可用实服务器负载分担变动最小。
CARP（Cache Array Routing Protocol，缓存阵列路由协议）哈希算法是在哈希算法的基础上进行了改进。当可用的实服务器数量发生变化时，采用CARP哈希算法，可使当前所有可用实服务器负载分担变动最小。设备支持配置基于源IP地址、源IP地址及端口、目的IP地址和HTTP载荷进行的CARP哈希算法。
源IP和端口CARP哈希算法就是基于源IP地址和端口进行的CARP哈希算法，通常由于各种外在的因素，后台的服务器都有可能失效，并且新的服务器很可能动态的增加进来，如何保证当后台服务器的数目发生变化时仍然能够对外提供良好的服务，即同一源IP地址和端口的客户端发起的请求仍被调度到相同后台真实服务器或者负载分担变动最小，此时基于源IP地址和端口进行的CARP哈希算法显得至关重要。基于源IP地址和端口进行的CARP哈希算法就是客户端在请求某一服务时，将客户端发起请求的源IP地址和端口做一致性哈希散列，这样就可以保证每次哈希出来的结果变动最小，即负载分担到后台的服务器结果变动最小。
采用源IP和端口CARP哈希算法进行负载均衡，同一源IP地址和端口的客户端，当后端的服务器不变时，它每次都会映射到同一台后端服务器进行访问，当后端的服务器变化时，每次哈希到后台的服务器结果也会变动的最小。
适用场景：
源IP和端口 CARP哈希算法适用于应用本身对请求的源IP地址和端口有要求的环境，同一源IP地址和端口的客户端发起的请求访问，当可用的实服务器数量发生变化时，采用源IP和端口CARP哈希算法，可使当前所有可用实服务器负载分担变动最小。
H3C的LB设备在处理具有一定相关性的会话时，会使用持续性组根据某持续性方法将具有一定相关性的会话都分配给同一个实服务器处理，保证业务的连续性，这个分配规则就称为持续性表项。如图6所示。常见的持续性方法有以下几种：
· 根据源IP和端口信息进行持续性处理，这种持续性方法可以将同一个网段的地址访问流量统一分给同一台服务器处理。适合于分-总式的网络布局，对于同一分地的客户提供同样的服务。
· 根据报文的Cookie进行持续性处理，这种方法适于对同一用户的不同时间内的业务分发到同一台服务器。Cookie的作用是用来区分用户以及跟踪用户的访问特征，以Cookie做为持续性可以提高用户的访问体验。
· 根据报文的某些特定内容，比如HTTP报文的首部，或者HTTP报文的报文体，进行持续性处理，这种方法适于用具有相同访问特征的用户，提供同一台服务器进行响应，保证不同用户得到的反馈相同。
图10 持续性示意图及持续性方法简介
连接复用的功能通过使用连接池缓存技术，对于暂时没有数据传输的服务器一侧连接放入缓存池中，允许公用。这样可以将前端大量的客户HTTP请求复用到后端与服务器建立的少量的TCP长连接上，大大减小服务器的性能负载，减小与服务器之间新建TCP连接所带来的延时，并最大限度减少后端服务器的并发连接数，降低服务器资源的占用。
图11中客户端端发送的Req1、Req2、Req3三个HTTP请求，经过LB处理后，复用了LB与已建立好的TCP连接，3个请求通过2个TCP请求发送给了Server端。
图11 连接复用示意图
H3C 的LB设备通过开启负载均衡设备与服务器的连接复用功能，可在负载均衡设备与服务器之间建立一条长时间不会老化的连接，使多个客户端复用同一条与服务器的TCP连接，可以通过设置空闲超时时间、最大复用次数以及IPv4网络掩码/IPv6前缀配置对应的连接复用功能。
支持IP/TCP/HTTP等多个参数模板设置，通过对应用参数模板的设置，可以优化应用交付的功能，提升应用交付的性能。
IP参数模板，提供了Set IP ToS功能。通过设置IP ToS来对各种类型的传输协议优化处理，从而提高关键应用传输的性能。
TCP参数模板提供了设置发送和接收缓冲区的大小等选项。通过设置TCP缓冲区的大小来调节链路传输的质量,达到优化TCP数据传输的目的。
HTTP参数模板提供了rebalance per-request（每请求分发）、head modify per-transaction（每业务请求修改）、head maxparse-length（最大解析头长度）、secondary-cookie（secondary-cookie设置）、content maxparse-length（最大content解析长度）等选项或参数设置，根据用户需求，满足对HTTP应用交付的优化需求和性能提升。
H3C的LB设备可通过配置负载均衡动作中的修改类动作完成报文的改写，以达到内容过滤、添加信息等作用，一方面可以屏蔽客户侧的不信任信息，也可以屏蔽内网服务器的敏感信息，同时可以根据组网需求，在报文中插入需要用户了解的信息。具体的修改内容包括以下几类：
· 完成对HTTP报文中特定首部的删除、插入和重写操作。
· 修改HTTP应答报文体中指定内容。
· HTTP与HTTPS重定向转换，重写服务器发送的HTTP应答报文Location首部的HTTP URL，将其改写为配置的HTTPS URL。
H3C的LB设备可配置负载均衡类用于将报文分类，即通过匹配规则将报文按照一定条件进行匹配，以便将不同类型的报文在不同的负载均衡动作流程中处理，其中七层负载均衡共支持如下几种匹配规则：
· 嵌套类的匹配规则。
· 源IP地址类型的匹配规则。
· ACL类型的匹配规则。
· 基于入接口的匹配规则。
· 基于用户的匹配规则。
· 基于用户组的匹配规则。
· HTTP实体类型的匹配规则。
· HTTP Cookie类型的匹配规则。
· HTTP首部类型的匹配规则。
· HTTP URL类型的匹配规则。
· HTTP方法类型的匹配规则。
H3C的LB设备支持重定向功能，由LB做为代理服务器，将所有匹配该虚服务器的HTTP请求报文重定向到指定URL上。此功能用于：
· 流量引流，将某一个虚服务的流量引流到另一个虚服务。
· 简化用户输入。对于某些特定业务，用户可能需要输入完整的URL才可能访问，通过重定向功能可以只输入目的IP地址就可以进行自动变换URL，方便用户使用。
对于七层负载均衡，LB设备可以做为模拟服务器，拦截用户请求，代替真实服务器回应报文，可用于引导用户选择对应的业务。对于真实的业务报文，再根据配置选择服务器进行分发。此功能需要提前将应答内容导入到LB设备中。
· 单文件代答，主要用于代答内容比较简单，只有一个文件的情况。所有的资源都在一个文件中存储。
· 多文件代答，主要用于复杂的代答内容，比如包含各种图片、音频、视频的PHP、HTML、JS文件。可以将这些文件放在同一个.zip压缩文件中。当用户访问的URL具有相同的前缀时，可以把相关联的文件返回，在客户端展示出复杂的展示效果。
· 代答文件更新，当引导内容发生变化时，比如添加或删除了某些应用，此时需要将变化后的应答内容重新导入LB设备，LB设备需通过配置重载代答文件，更新当前生效的代答文件，用户刷新页面之后就可以看到最新的引导界面。
代答功能的典型应用场景是WEB服务导航。在LB设备上预先导入导航页面所对应的代答文件，导航页面中包含了各服务对应的URL链接；配置导航页面URL的匹配动作为代答，代答内容为之前导入的导航页面文件；配置其他真实服务URL的匹配动作为负载均衡。当用户访问导航页面URL时，LB设备将导航页面返回，用户在导航页面点击服务URL后，流量经LB设备转发至各真实服务器。
智能DNS可以为外网用户提供内部服务器智能解析服务功能，可以解决由外网访问内网服务器链路选择的问题，在没有负载均衡设备的网络中，外网用户访问内部服务器时只能选择单一链路或者随机选择链路，未经优化的随机链路选择无法保障外网用户的访问体验效果。H3C的负载均衡设备通过内置的智能DNS模块，可以配合客户的解析服务器引导内部服务器的域名解析，当外网用户通过域名访问客户的内部服务器时，负载均衡设备就会通过静态列表或者动态判断算法，选择最优的线路，然后将域名解析成相应线路的IP地址。
对于SMB用户来说，出于成本考虑，出口链路可能使用的是PPPOE动态获取的IP地址，其IP地址及下一跳IP地址都是动态的。该特性可以在outbound链路负载、DNS透明代理的时候支持调用PPPOE拨号链路，在此基础上运行LLB业务。
基于PPPoE链路运行LLB特性功能，主要包括以下功能：
支持链路指定Dialer出接口；
支持DNS服务器自动获取动态DNS Server IP地址；
支持指定出接口进行健康检测及就近性探测
支持响应动态DNS Server IP变化
支持响应链路地址状态变化
提供丰富的端口，并支持电口、光口、万兆光口，有效降低用户的投入成本。
采用H3C公司拥有自主知识产权的软、硬件平台。产品应用从电信运营商到企业用户，经历了多年的市场考验。
具备全面的安全防护能力，可以防止大流量的DOS/DDOS攻击防护，ARP欺骗攻击、超大ICMP报文攻击、地址/端口扫描等各种攻击的防范，是业界安全功能极为强大的负载均衡产品。支持的泛洪攻击类型包括：
ACK：ACK flood攻击。ACK报文为只有ACK标志位置位的TCP报文，服务器收到ACK报文时，需要查找对应的连接。若攻击者发送大量这样的报文，服务器需要进行大量的查询工作，消耗正常处理的系统资源，影响正常的报文处理
DNS：DNS flood攻击。DNS服务器收到任何DNS Query报文时都会试图进行域名解析并且回复该DNS报文。攻击者通过构造并向DNS服务器发送大量虚假DNS Query报文，占用DNS服务器的带宽或计算资源，使得正常的DNS Query得不到处理
DNS reply：DNS reply flood攻击。DNS客户端收到任何DNS reply报文时都会进行处理。攻击者在一定条件下将大量伪造的DNS reply报文发送给某个DNS客户端，消耗大量DNS客户端的资源，使得正常的DNS reply报文得不到处理
FIN：FIN flood攻击。FIN报文用于关闭TCP连接。若攻击者向服务器发送大量的伪造的FIN报文，可能会使服务器关闭掉正常的连接。同时，服务器收到FIN报文时，需要查找对应的连接，大量的无效查询操作会消耗系统资源，影响正常的报文处理
HTTP：HTTP flood攻击。HTTP服务器收到HTTP GET命令时可能进行一系列复杂的操作，包括字符串搜索、数据库遍历、数据组装、格式化转换等等，这些操作会消耗大量系统资源，因此当HTTP请求的速率超过了服务器的处理能力时，服务器就无法正常提供服务。攻击者通过构造并发送大量虚假HTTP GET请求，使服务器崩溃，无法响应正常的用户请求
HTTP slow：HTTP 慢速攻击。攻击者在建立了与HTTP服务器的连接后，长时间保持该连接不释放，大量这种连接将消耗服务器系统资源，影响正常报文的处理
HTTPS：HTTPS flood攻击。HTTP服务器收到HTTPS请求时会进行一系列复杂的操作，这些操作会消耗大量系统资源。攻击者利用这一特点，向HTTP服务器发送大量伪造的HTTPS请求，造成HTTP服务器崩溃，使其无法响应HTTPS请求
ICMP：ICMP flood攻击。攻击者在短时间内向特定目标发送大量的ICMP请求报文（例如ping报文），使其忙于回复这些请求，致使目标系统负担过重而不能处理正常的业务
ICMPv6：ICMPv6 flood攻击。攻击者在短时间内向特定目标发送大量的ICMPv6请求报文（例如ping报文），使其忙于回复这些请求，致使目标系统负担过重而不能处理正常的业务
RST：RST flood攻击。RST报文为TCP连接的复位报文，用于在异常情况下关闭TCP连接。如果攻击者向服务器发送大量伪造的RST报文，可能会使服务器关闭正常的TCP连接。另外，服务器收到RST报文时，需要查找对应的连接，大量的无效查询操作会消耗系统资源，影响正常的报文处理
SIP：SIP flood攻击。SIP服务器收到SIP INVITE连接请求时，服务器需要分配一定的资源用于跟踪和建立会话，因此当SIP请求的速率超过了服务器的处理能力时，服务器就无法正常提供服务。攻击者通过构造并发送大量虚假的SIP INVITE请求报文，导致服务器崩溃，无法响应正常的用户请求
SYN：SYN flood攻击。根据TCP协议工作原理，服务器收到SYN报文后需要建立半连接并回应SYN ACK报文，然后等待客户端的ACK报文来建立正式连接。由于资源的限制，操作系统的TCP/IP协议栈只能允许有限个TCP连接。攻击者向服务器发送大量伪造源地址的SYN报文后，由于攻击报文是伪造的，服务器不会收到客户端的ACK报文，从而导致服务器上遗留了大量无效的半连接，耗尽其系统资源，使正常的用户无法访问，直到半连接超时
SYN-ACK：SYN-ACK flood攻击。由于SYN ACK报文为SYN报文的后续报文，服务器收到SYN ACK报文时，需要查找对应的SYN报文。若攻击者发送大量这样的报文，服务器需要进行大量的查询工作，消耗正常处理的系统资源，影响正常的报文处理
UDP：UDP flood攻击。攻击者在短时间内向特定目标发送大量的UDP报文，占用目标主机的带宽，致使目标主机不能处理正常的业务
支持基于HTTP头的内容策略过滤并作相应配置。可配置负载均衡类用于将报文分类，即通过匹配规则将报文按照一定条件进行匹配，以便将不同类型的报文在不同的负载均衡动作流程中过滤处理，其中七层负载均衡共支持如下几种匹配规则：
HTTP实体类型的匹配规则。
HTTP Cookie类型的匹配规则。
HTTP首部类型的匹配规则。
HTTP URL类型的匹配规则。
HTTP方法类型的匹配规则。
产品命令行页面（OS命令行）可运行ping、telnet、抓包等排错命令
H3C系列产品采用安全集群框架，实现多台设备虚拟成一台N:1，之后再将整体虚成多台虚拟单元，“一虚多再多虚一”，在业务部署中满足了用户丰富的虚拟化使用要求。
H3C系列产品支持LB SDN服务链，基于网络的核心控制部件SDN控制器——VCFC （Virtual Converged Framework Controller）进行部署。VCFC根据租户需求，定义、创建服务链，并部署服务链上每个节点的业务逻辑。VCFC将需要进入服务链处理的用户报文特征，下发到接入软件/硬件VTEP，从而将数据报文引入服务链。
组织在应对网络安全威胁时，一大挑战便是如何应对越来越多的加密流量。大部分网络安全设备无法有效地对网络流量进行解密，即使具备相应的能力，其处理性能也偏低，这是因为解密工作往往消耗大量的计算资源。传统的网络安全架构倾向于将各种网络安全设备，如防火墙、入侵防御、Web防火墙等设备按照链条的方式进行部署。因为不同设备的处理机制和处理性能的不同，导致检测效率往往比较低，且组网不够灵活，无法应对网络架构的变动。
H3C流量编排方案，以应用交付产品为核心，采用了以专用加解密芯片为基础的高性能动态证书解密方案，能够对双向SSL/TLS流量进行解密处理，从而实现针对加密流量中的网络威胁作出检查、判断和响应的处置。
H3C流量编排方案中的应用交付产品以安全服务链为技术基础，通过集成透明代理和关联LB虚服务实现SSL卸载和引。通过随即、哈西、轮询、加权轮询、最小连接、最快响应、带宽等调度算法和会话保持技术实现安全设备资源池化，并解决多链路网络环境中流量分担的问题，并为用户分配最佳的通信线路，使用户获得绝佳的访问体验。通过使用设备健康检查，实现了在部分安全设备故障的情况下任然可以提供访问网络的能力，充分保障网络可靠性。
l SSL可视：一次加解密，实现SSL流量安全防护及审计，减少安全网元负载（避免重复卸载），降低访问时延，提升业务访问体验。
l 流量编排：按需进行流量编排，避免安全网元不必要业务处理。
l 流量可靠：通过主动探测网元健康度，自动实现故障网元Bypass，保障业务可靠性。
l 安全池化：丰富负载分担调度算法，实现对同类安全资源池调度，达到安全网元横向扩展、灰度上线，实现敏态IT。
l 安全异构：安全设备池化、流量编排，实现安全设备异构、解耦。
l 透明代理：支持明文代理和SSL卸载，其中SSL卸载的证书在网络出方向支持支持保护客户段模式，网络入方向一般采用保护服务器模式。
l 关联LB虚服务：支持4层和7层的LB虚服务引用安全服务链，并根据编排策略将报文引流到不同的服务链中。
l 安全设备二层接入
二层方式接入类似于网线模式，但流量编排服务方案以整个数据流的处理是三层IP模式为基础，因此，需要将二层设备模拟成三层模式，流量编排设备区分数据发往安全设备的接口和从安全设备接收流量的接口，为有效区分不同的二层安全设备，需要每个二层安全设备均独占两个不同的链路(或者VLAN)。
二层安全设备本身没有业务地址，对二层安全设备的健康检测，需要健康检测的流量再穿越二层安全设备，回到流量编排设备的流量接收接口。比较常见的健康检查方式是通过icmp协议来进行网络探测，健康检测的ping过程需要指定源IP为流量编排设备得出接口IP并指定出接口，目的IP为流量编排设备的入接口的IP。
l 安全设备三层接入
三层设备接入本身提供了IP地址，只需要指定三层安全设备的接口IP为下一跳IP即可将报文转发到安全设备对应的接口上。 需要在三层安全设备相应的接口配置路由或者默认网关，使流量转发回流量编排设备。
三层安全网元的健康检测和LB实服务的健康检测一致。
l 安全设备的TAP旁路接入
安全设备TAP旁路接入时只接收报文，不回应报文。
旁路部署的安全网元一般不需要做健康检测，如果需要，可以通过管理口IP来实现健康检测。需要确保旁路设备的管理口IP和流量编排设备是通的。
三台物理服务器Server A、Server B和Server C均可提供FTP服务，且这三台服务器的硬件配置顺次降低。通过配置服务器负载均衡，在考虑硬件性能的前提下让这三台服务器联合提供FTP服务，并通过健康检测来监控这些服务器是否可达。
图13 四层负载均衡组网图
用户需要对应用层报文内容进行分析，根据分析的结果进行负载均衡，此时可以选择七层负载均衡组网。三台物理服务器Server A、Server B和Server C均可提供HTTP服务，且这三台服务器的硬件配置顺次降低。通过配置服务器负载均衡，在考虑硬件性能的前提下让这三台服务器联合提供HTTP服务，并通过健康检测来监控这些服务器是否可达。
图14 七层负载均衡组网图
随着网络需求的不断增加和技术的不断进步，校园网无论是规模还是容量都发生了巨大的变化，单一Internet连接链路存在单点失效性，一旦该链路出现故障将造成整个网络的瘫痪。网络有多个链路与Internet相接，虽然路由协议知道一些就近性和可达性，但真正意义上的流量负载均衡还是做不到。如有对外提供服务的Server，普通的链路负载均衡设备无法结合DNS，链路状态，链路负载，判断出哪一条链路可以为外部用户提供最优的服务。并且高校带宽紧张， 如何合理规划各条链路带宽资源，使接入学生和教职工用户拥有更好的上网体验，也是目前各高校存在的重要问题。
通过H3C链路负载均衡设备，采用基于应用的策略路由 :在园区网出口场景下，不同链路的质量不同，成本不同，通过基于应用的链路负载均衡策略，可以将高价值流量分流到高成本链路，低价值流量通过低成本链路发送。配合带宽阈值保护在高价值流量带宽拥塞后可以继续分发到其他链路最大程度保证高价值流量。
图15 校园多出口链路负载均衡组网图
支持
