慧敏应用交付网关负载均衡工作模式分析

应用交付网关就是将关键应用、数据和服务更加高效、便捷和安全地交付给用户来使用，业界早已为它定义了专业术语 -应用交付控制器（Application Delivery Controller）。而应用交付控制器，实际上就是传统网络负载均衡的扩展和升级，它是一种综合性交付平台设备。

慧敏应用交付网关产品在设计初始就立足于实现全面综合的应用交付平台。因此，它必须能够在深度理解用户、会话和业务内容上下文的情况下，灵活管理和调度应用数据。慧敏应用交付网关通过智能流量管理引擎、策略控制引擎、安全防护引擎和弹性计算引擎，将全面的4-7层服务器负载均衡、链路负载均衡、全局负载均衡、智能内容交换、应用健康检查、会话保持、TCP连接复用/单边加速、数据压缩与缓存、SSL加速、国密算法支持、智能应用控制、网络ACL、DDos防护、Http协议清洗、Httpflood防护、Web应用防火墙、弹性计算等众多应用交付技术集成在一个统一的平台，在确保应用系统可靠性和灵活性的基础上，还能将Web应用系统的性能提升5－10倍，并增强应用系统的安全防护等级。

慧敏应用交付网关集成了负载均衡功能，并支持三种负载均衡工作模式：

NAT快速转发模式

三角传输模式（Direct Server Return）

HTTP反向代理模式

NAT快速转发模式

这是最简单也是最常用的负载均衡工作模式，特点是转发效率较强，能够支撑比较大的应用流量。在NAT模式下，应用交付网关设备接收到会话请求后，根据负载均衡的调度算法，选择最佳的目标真实服务器，然后将报文的目标IP地址转换成真实服务器的IP地址，即可完成数据定向转发。

实际上，应用交付网关就是针对原始数据报文中的目标地址进行NAT转换，完成应用请求转发至预期的目标服务器。而真实服务器接收并处理完该报文，再将响应报文返回给应用交付网关。应用交付网关根据系统NAT会话记录，将响应报文中的源IP地址（即真实服务器IP）恢复成虚拟服务器的IP地址，返回给请求客户端。整个过程对于客户端来说完全透明。而且应用交付网关并没有中断原始TCP会话，仅仅做了目标IP地址转换，处理逻辑非常简单，因此可以实现非常高转发速率。

图：客户端地址透传NAT模式

以上的例子，我们仅仅针对原始请求报文的目标IP地址进行转换，而标识客户端的源IP地址仍然保留。在这种场景下，后端真实服务器的网关必须指向应用交付网关，否则在较为复杂的网络环境中，服务器的响应报文有可能无法返回到应用交付网关，会导致会话中断。

在NAT快速转发模式下，为了能够确保服务器的响应报文能够正确返回给慧敏设备，其实系统设计了两种细分的NAT工作模式：

仅做目的IP地址转换的NAT模式（Half NAT），我们称之为客户端地址透传

目的IP地址和源IP地址全部做转换的NAT模式（Full NAT）

我们已经知道在Half NAT模式下，真实服务器的网关必须是应用交付网关设备的内网IP。那么如果数据中心内网拓扑比较复杂，我们无法实现这样的前提该怎么办？Full NAT工作模式将会完美解决这个问题。

Full NAT的机制是将原始请求报文中的源和目的IP地址都进行NAT转换。目的IP转换成真实服务器的IP地址，源IP地址转换成应用交付网关的设备内网IP地址。这样，真实服务器的响应报文目标地址一定是应用交付网关设备的内网IP。那么，即使是复杂的网络环境，响应报文也一定会通过路由设备返回到应用交付网关。应用交付网关根据系统NAT会话记录，再将响应报文的源和目的IP地址分别恢复成虚拟服务器IP地址和客户端IP地址即可。

图：Full NAT模式

三角传输模式（Direct Server Return）

三角传输模式也称为服务器直接返回（Direct Server Return）。这种工作模式下，慧敏应用交付网关实际上仅仅针对会话请求的报文实现负载均衡。真实服务器的响应报文直接跨越应用交付网关，从另外的路径返回给客户端。客户端、应用交付网关和真实服务器之间的数据交互形成一个单向的三角型数据传输路径，因而称之为三角传输模式。

三角传输模式下，应用交付网关的的数据转发处理机制不同于NAT模式。它是通过转换原始请求报文的目的MAC地址实现数据定向转发。首先，当应用交付网关接收到会话请求的报文后，根据负载均衡算法决策出目标真实服务器。然后通过ARP查询，获得真实服务器的MAC地址，再将原始报文的目的MAC替换成真实服务器的MAC。最终应用交付网关将修改后的报文在真实服务器所在的VLAN中进行发送。因为报文的MAC地址是决策出来的真实服务器MAC，所以真实服务器可以收到请求报文。真实服务器的响应报文发送到网络后，网络设备通过路由选路最终将数据直接返回给客户端，而不再需要将响应数据必须返回应用交付网关。

但是，三角传输工作模式的实现相对复杂一些，同时也有一些前提条件。第一个前提就是应用交付网关一定要与真实服务器处于相同VLAN，才能完成上述的MAC地址转换和数据转发，否则没有MAC地址转换的技术基础。另外，数据报文在进出应用交付网关的整个流程中，报文源/目的IP一直没有发生任何变化。所以当真实服务器接收到该报文时，报文的目的IP是虚拟服务器的IP地址而不是真实服务器的IP地址，那么如何保障真实服务器会处理该报文呢？这就需要真实服务器做一些配合，才能实现三角传输，这也是三角传输模式的另外一个前提条件。我们必须事先在所有真实服务器上绑定虚拟服务器的IP地址，而且这个IP地址只能作为系统的环回地址（lookback）。从而使得真实服务器可以处理该报文，但又不会影响虚拟服务器IP地址在网络中的ARP记录。

图：三角传输模式

三角传输方式在互联网初期是大型网站使用最广泛的一种负载均衡模式，因为当时的负载均衡设备处理性能存在严重瓶颈。而现在随着数据高速转发技术的成熟，以及硬件处理性能的提升，专业的负载均衡设备处理性能已经基本满足大规模应用流量的要求。因此这种部署模式已不太常见，有一些软件负载均衡解决方案仍在使用这种工作模式。

HTTP反向代理模式

HTTP反向代理模式（Web Reverse Proxy）是目前应用最为广泛的部署方式。它与NAT和DR模式最本质的区别就是必须终结TCP连接。也就是说，客户端的请求会话必须在应用交付网关进行终结，然后应用交付网关解析HTTP应用层请求信息，并且以代理人的角色将应用请求重新封装到与服务器之间建立的另外一个TCP连接上。此时，应用交付网关就是一个反向代理服务器，真实服务器只看到应用交付网关作为“唯一的”应用客户端与它通信。

站在应用交付网关的角度来看，这种工作机制将客户端与服务器之间的业务数据交互隔离在两个独立的TCP连接会话上，即客户端TCP连接和服务器端TCP连接。两端所有TCP连接均由慧敏设备进行管理和维护，应用交付网关对外完全屏蔽了真实服务器。系统内部，七层流量调度引擎通过HTTP协议解析，获取到应用层的Web请求信息，并依据调度算法或内容转发规则确定转发目标服务器，再重新将Web请求封装至对应的服务器端TCP连接上传递出去。甚至还可以按照安全防护引擎的审查结果或者SamrtRule策略规则，确定是否向后端真实服务器转发该Web请求。而真实服务器的响应内容也同样会被提取出来，再重新封装到相应的客户端会话上予以返回。

在上述过程中，慧敏应用交付网关还可以将不同客户端连接的HTTP请求，复用到少量的服务器端TCP长连接中，有效降低真实服务器用于维护会话的系统资源开销，提升Web处理效能。

图：HTTP反向代理模式

HTTP反向代理模式最大的好处就是可以利用终结会话的机制，深度解析应用层信息，并依此可以提供Web优化、安全防护以及应用控制的能力。例如：TCP连接复用、TCP单边加速、HTTP数据压缩、内容缓存、SSL加速、HTTP Flood防护、WAF安全，以及利用SmartRule规则脚本定制内容转发、请求过滤、内容改写等应用控制策略。而且针对HTTPS应用的大量普及，反向代理机制可以实现对加密数据的安全审核和策略控制，这是传统NAT负载均衡机制无法做到的。

可以说，HTTP反向代理模式的诞生，才是传统负载均衡设备升级为应用交付设备最核心的基础。