本文主要是介绍SLB的三种模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、 SLB产生背景:
SLB(服务器负载均衡)：在多个提供相同服务的服务器的情况下，APV设备上存在VIP，当大量客户端从外部访问VIP地址时，负载均衡设备将这些报文请求根据负载均衡算法，将流量均衡的分配给后台服务器以平衡各个服务器的负载压力，避免在还有服务器压力较小情况下其他服务达到性能临界点出现运行缓慢甚至宕机情况，从而提高服务效率和质量，因此对客户端而言，RS的IP地址即是负载均衡设备VIP地址，真正的RS服务器IP地址对于客户端是不可见的。
二、 SLB的三种传输模式：
七层SLB和四层SLB的区别：
四层SLB：配置APV设备上服务类型为tcp/udp，APV设备将只解析到4层，APV与client三次握手之后就会和RS建立连接；
七层SLB：配置APV设备服务类型为http/ftp/https等，APV设备将解析报文到7层，在APV设备与client三次握手之后，只有收到对应七层报文，才会跟RS建立连接。
在APV设备中，SLB主要工作在以下的三种传输模式中：
反向代理模式
透传模式
三角模式
根据不同的模式，APV的工作方式也不尽相同，但无论在哪种模式下，客户端发起的请求报文总是需要先到达APV设备进行处理，这是负载均衡设备正常工作的前提。网络拓扑环境：
Client：10.8.21.40
APV：172.16.75.83
VIP：172.16.75.84
RS1IP：172.16.75.82
RS2IP：172.16.75.85
在整个报文交互过程中，采用Tcpdump和Wireshark分别在RS和Client处抓包，然后使用Wireshark进行报文解析。
三、 反向代理模式
：
反向代理：普通的代理设备是内网用户通过代理设备出外网进行访问，而工作在这种模式下的APV设备，则是外网用户通过代理设备访问内网，因此称之为反向代理。
在反向代理模式下：
当APV设备收到客户端请求后，会记录下此报文（ 源IP地址、目的IP地址、协议号、源端口、目的端口，服务类型以及接口索引），将报文目的地址更改为优选后的RS设备的IP地址，目的端口号不变，源地址修改为APV设备下行与对应RS设备接口的IP地址，源端口号随机发送给RS；
当RS收到报文后，会以源为RS接口IP地址，目的APV设备地址回复给APV设备，APV设备将源修改为VIP，目的端口号修改为客户端的源端口号，目的IP修改为Client的源IP回复报文。
1 APV设备主要配置：
System mode reverseslb real http"service1http" 172.16.75.82 80 1000 tcp 3 3
slb real http"service2http" 172.16.75.85 80 1000 http 3 3
slb group method"rrgroup" rr
slb group member"rrgroup" "service1http" 1 0
slb group member"rrgroup" "service2http" 1 0
slb virtual http"virtual1http" 172.16.75.84 80 arp 0
slb policy default"virtual1http" "rrgroup"2 结果分析
分析整个报文交互过程：
TCP握手过程：
首先Client向APV设备发送TCP syn报文请求建立连接，源IP为Client的IP 10.8.21.40，源端口号50894，目的IP为VIP地址172.16.75.84，目的端口号80；
收到请求报文后，APV设备会以源IP为VIP地址172.16.75.84，端口号80，目的IP 10.8.21.40，目的端口号50894回应syn ack报文；
Client收到报文后回复ack报文，TCP三次握手成功。
HTTP报文交互过程：
当APV设备与client完成三次握手后，因为配置的七层SLB，如果收到HTTP请求，就会根据负载均衡算法和服务器健康状态优选出对应的RS（在这次过程中选择的RS设备为172.16.75.82），然后与RS建立TCP连接：
APV设备发送tcp syn报文请求连接，源IP为APV设备与RS相连接口IP 172.16.75.83，源端口号随机4574，目的IP为RS的IP 172.16.75.82，目的端口号80；
RS收到报文后，以源IP 172.16.75.82，端口号80，目的IP 172.16.75.83，目的端口号4574回复syn ack报文，APV设备回复ack报文建立三次握手；
之后，APV再将收到的HTTP报文源IP修改为与RS相连下行接口IP地址172.16.75.83，源端口号为随机端口号，将报文发送给RS；
当RS收到报文后，使用源为本地IP 172.16.75.82，目的IP为172.16.75.83进行回复，所以报文直接回复给APV设备；
当APV设备收到RS的回应报文后，将报文的源修改为VIP地址172.16.75.84，目的IP为10.8.21.40发送回Client，再将目的端口号修改为HTTP请求报文中的源端口号，服务器访问成功。
经过APV设备前 经过APV设备后
源IP和端口号 目的IP和端口号 源IP和端口号 目的IP和端口号
请求报文 10.8.21.40:50894 172.16.75.84:80 172.16.75.83:4574 172.16.75.82:80
回应报文 172.16.75.82:80 172.16.75.83:4574 172.16.75.84:80 10.8.21.40:50894
由上述的过程可以看出，在RS端上，client的真实IP地址被APV修改成与RS相连接口的IP地址，所以RS无法记录到Client的访问记录，为了解决这个问题，我们可以采用在HTTP报文头中添加X-Forwarded-For字段，本文不做赘述，后续将会深入研究这个问题。
四、 透传模式：
当APV工作在透传模式中时，RS无法感知到APV设备的存在，对于Client来说，RS的IP地址就是APV设备的VIP地址。
在这种模式下，当APV设备收到源为Client的IP，目的IP为本地VIP地址的报文时，会将报文根据负载均衡策略和健康状况发送给最优的RS设备上，继而RS设备会收到目的为本地IP，源为Client实际IP的请求报文；
然后RS将会直接回应此请求，报文的目的IP地址为Client的IP地址，当APV设备收到此报文后，将源IP地址修改为VIP地址，然后将报文发送给Client。
1 APV设备主要配置：
System mode transparentslb real http"service1http" 172.16.75.82 80 1000 tcp 3 3
slb real http"service2http" 172.16.75.85 80 1000 http 3 3
slb group method"rrgroup" rr
slb group member"rrgroup" "service1http" 1 0
slb group member"rrgroup" "service2http" 1 0
slb virtual http"virtual1http" 172.16.75.84 80 arp 0
slb policy default"virtual1http" "rrgroup"2 结果分析：
TCP握手过程：
同反向代理模式交互过程
HTTP报文交互过程：
Client向APV设备的VIP地址172.16.75.84以源IP 10.8.21.40发送HTTP请求，当APV设备收到报文后，与优选后的RS进行TCP三次握手，过程同反向代理模式，然后将收到的HTTP报文，不改变报文的源IP地址和源/目的端口号，只修改目的IP修改为优选后的RS地址172.16.75.82；
当RS收到源来自IP 10.8.21.40的报文后，回复报文给IP地址10.8.21.40，此时要注意，必须在RS上配置回复报文经过APV设备，APV设备会将源IP修改为VIP地址172.16.75.84，然后转发给Client，否则Client将会收到源IP为172.16.75.82的HTTP报文，服务器访问失败。
经过APV设备前 经过APV设备后
源IP和端口号 目的IP和端口号 源IP和端口号 目的IP和端口号
请求报文 10.8.21.40:54266 172.16.75.84:80 10.8.21.40:54266 172.16.75.82:80
回应报文 172.16.75.82:80 10.8.21.40:54266 172.16.75.84:80 10.8.21.40:54266
五、 三角模式：
在三角模式下，当客户端发送请求到APV设备上时，APV设备会计算出最优RS，然后直接根据MAC地址将报文转发给RS，在RS上配置报文的源IP为VIP地址（一般配置在loopback口上），因此在这种情况下，RS会直接将报文发送给Client，即使回复报文经过APV，APV也不做任何处理。由于报文在整个过程中传输途径类似于三角形，因此称之为三角模式。
1 APV设备主要配置：
system mode triangleslb real tcp"service1http" 172.16.75.82 80 1000 tcp 3 3
slb real tcp"service2http" 172.16.75.85 80 1000 tcp 3 3
slb group method"rrgroup" rr
slb group member"rrgroup" "service1http" 1 0
slb virtual tcp"virtual1http" 172.16.75.84 80 arp 0
slb policy default"virtual1http" "rrgroup"2 结果分析：
TCP握手过程：
由于采用了4层SLB，所以在TCP握手过程中与上述的7层SLB有些不同，当Client和RS完成三次握手之后，此时APV设备会直接选择RS，然后跟RS建立TCP三次握手；
在三角模式环境中，由于RS的Loopback口和APV上都存在着VIP地址172.16.75.84，当APV经过负载均衡算法选择出对应的RS后，会根据实际配置的RS的IP地址对应的mac地址，将报文以目的mac为RS，目的IP为VIP的方式建立TCP连接。
HTTP报文交互过程：
经过APV设备前 经过APV设备后
源IP和端口号 目的IP和端口号 源IP和端口号 目的IP和端口号
请求报文 10.8.21.40:53210 172.16.75.84:80 10.8.21.40:53210 172.16.75.84:80
回应报文 172.16.75.84:80 10.8.21.40:53210 172.16.75.84:80 10.8.21.40:53210
首先Client向APV设备的VIP发送HTTP请求，源为10.8.21.40，当APV设备收到报文后，将报文直接转发给RS，当RS收到源IP为10.8.21.40，目的IP为本地Loopback口IP地址172.16.75.84的报文后，直接将报文回复给10.8.21.40，同样源为IP地址172.16.75.84，由此访问服务器成功。
在三角模式中，由于回复报文APV设备不做任何处理，所以非常适合于RS到Client方向流量较大或者连接数目较多的组网环境。
采用三角模式时，必须注意RS有路由可以到达Client，并且在RS的Loopback接口上必须有APV设备的VIP地址，否则即使RS设备收到Client的请求报文也会直接丢弃报文，不作回应。
六、 总结
通过上述的探究以及实际操作，可以发现APV在SLB的这三种工作模式中总体的实现方法，而且通过不同的报文交互过程，也可以发现不同传输模式的差异：
由于反向代理模式中在RS侧只能收到源为APV设备IP的报文，因此可以使用防火墙增加安全性，只允许源IP为APV的IP地址的报文通过，同时增加X-Forwarded-For字段也可以让RS只允许有此字段的报文进行访问，因此安全性相对较高。
网关 是否更改源IP 优点 缺点 适用场景
反向代理模式 无要求（建议指向APV） 是 Client和RS之间完全由APV隔离，安全性提高 不做其他配置情况下RS无法记录客户端信息会出现端口耗尽情况 根据用户要求，适用于大部分场景
透明模式 必须指向APV 否 RS可以直接记录访问信息，不容易出现端口耗尽 当RS和Client位于同一网段时不能采用透明模式 根据用户要求，同样适用于大部分场景
三角模式 无要求（建议指向路由器） 否 APV设备压力最小，网络响应速度最快 只支持IP，TCP，UDP类型的虚拟服务 适用于RS侧流量连接大的网络
这篇关于SLB的三种模式的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
