——————————————————————————————————————————————
三大主流软件负载均衡器对比(LVS、Nginx、HAproxy)
——————————————————————————————————————————————
LVS:
1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低
2. 工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。
3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)
4. 不支持正则处理，不能做动静分离。
5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)
6. 配置相对复杂，对网络依赖比较大，稳定性很高。
7. LVS工作模式有4种：
(1) nat 地址转换
(2) dr 直接路由
(3) tun 隧道
(4) full-nat
Nginx:
1. 工作在网络7层，可以针对http应用做一些分流的策略，比如针对域名，目录结构
2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能
3. Nginx安装配置比较简单，测试起来很方便
4. 也可以承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的
5. 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测
6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力
7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。
8. 不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。
9. Nginx还能做Web服务器即Cache功能。
第6点补充：
什么是nginx的异步处理：
squid同步处理：浏览器发起请求，而后请求会立刻被转到后端，于是在浏览器和后台之间就建立了一个通道。从请求发起直到请求完成，这条通道都是一直存在的。
nginx异步处理：浏览器发起请求，请求不会立刻转到后端，而是请求数据(header)先收到nignx上，然后nginx再把这个请求发到后端，后端处理完成后把数据返回到nginx上，nginx将数据流发到浏览器。
使用异步处理的好处：
1. 假设用户执行一个上传文件操作，因为用户网速又比较慢，因此需要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台建立了连接，半小时后文件上传结束，由此可见，后台服务器连接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，因此仅仅是nginx和用户保持了半小时连接，后台服务器在这半小时内没有为这个请求开启连接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，所以只花了一秒钟就将请求发送到了后台，由此可见，后台服务器连接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化 程度很大。
2. 在上面这个例子中，假如后台服务器因为种种原因重启了，上传文件就自然中断了，这对用户来说是非常恼火的一件事情，想必各位也有上传文件传到一半被中断的 经历。用nginx代理之后，后台服务器的重启对用户上传的影响减少到了极点，而nginx是非常稳定的并不需要常去重启它，即使需要重启，利用kill -HUP就可以做到不间断重启nginx。
3. 异步传输可以令负载均衡器更有保障，为什么这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每个请求都是只有一次机会的，假如用 户发起一个请求，结果该请求分到的后台服务器刚好挂掉了，那么这个请求就失败了；而nginx因为是异步的，所以这个请求可以重新发往下一个后台，下一个 后台返回了正常的数据，于是这个请求就能成功了。还是用用户上传文件这个例子，假如不但用了nginx代理，而且用了负载均衡，nginx把上传文件发往 其中一台后台，但这台服务器突然重启了，nginx收到错误后，会将这个上传文件发到另一台后台，于是用户就不用再花半小时上传一遍。
4. 假如用户上传一个10GB大小的文件，而后台服务器没有考虑到这个情况，那么后台服务器岂不要崩溃了。用nginx就可以把这些东西都拦在nginx上，通过nginx的上传文件大小限制功能来限制，另外nginx性能非常有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。
用异步传输会造成问题：
后台服务器有提供上传进度的功能的话，用了nginx代理就无法取得进度，这个需要使用nginx的一个第三方模块来实现。
第8点补充：
Nginx upstream支持的分配策略及原理：
1. 轮询(默认)：每个请求按照顺序逐一分配到不同的后端服务器。如后端服务器down掉，就切换到另一台并剔除down的后端主机
2. weight：指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
3. ip_hash：每个请求按照访问ip的hash结果分配，不同ip的请求被分配到后端不同的服务器上，可以解决session的问题。
HAProxy:
1. 支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
2. 能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3. 支持url检测后端的服务器出问题的检测会有很好的帮助。
4. 更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5. 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6. HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
7. 支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）
8. 不能做Web服务器即Cache。
三大主流软件负载均衡器适用业务场景：
1. 网站建设初期，可以选用Nginx、HAProxy作为反向代理负载均衡(流量不大时，可以不选用负载均衡)，因为其配置简单，性能也能满足一般业务场景。如果考虑到负载均衡器是有单点问题，可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。
2. 网站并发到达一定程度后，为了提高稳定性和转发效率，可以使用lvs，毕竟lvs比Nginx/HAProxy要更稳定，转发效率也更高。
注：nginx与HAProxy比较：nginx只支持七层，用户量最大，稳定性比较可靠。Haproxy支持四层和七层，支持更多的负载均衡算法，支持session等。
衡量负载均衡器好坏的几个重要的因素：
1. 会话率 ：单位时间内的处理的请求数
2. 会话并发能力：并发处理能力
3. 数据率：处理数据能力
——————————————————————————————————————————————
F5, Radware， Array的对比
——————————————————————————————————————————————
一、F5
F5的BIG-IP家族号称是ALL-IN-ONE的设备。“BIG-IP is the only device in the industry that can do everything”.这是F5官网的原文，从中不能看出，F5对自己产品的自信。
当然，do everything不动于do anything，你叫它做黑洞探测，它能做吗，不可能。呵呵，有些抬杠了，言归正传，今天就来说说F5的BIG-IP到底能做什么。
还是引用F5官网的话，“It delivers high availability, improved performance, application security, and access control, all in one unit.”它可以提供高可用性，提高性能，保障应用安全，提供访问控制。其实高可用性就可以简单地理解为负载均衡。而对于性能的提升无外乎于SSL加速，压缩和缓存等。应用安全就是指对于蠕虫，DoS和DDoS攻击等的防护。访问控制就很容易理解了，和防火墙的访问控制的基本一致。从中不难看出，负载均衡已经由最初的4层交换发展为集多种功能为一身的应用交换机。
F5的BIG-IP家族包括6个模块：
Local Traffic Manager(LTM)
Global Traffic Manager(GTM)
Link Controller(LC)
Application Security Manager(ASM)
Secure Access Manager(SAM) standalone version
WebAccelerator(WA)
· LTM就是本地流量管理，也就是通常所说的服务器负载均衡。可以将多个提供相同服务的设备（pool）虚拟成一个逻辑设备，供用户访问。也就是说，对于用户来讲，看到的只有一个设备，而实际上用户是服务请求是在多个设备之间，通过负载均衡算法分担的。通常可以理解为是一种代理的模式。
· GTM是全局流量管理，也可以称为全局负载均衡。这个模块可以满足用户更高的负载均衡要求，提供不同站点间全局资源的调配。比如说，用户在北京和上海分别 有一个web服务器群（pool），都是提供同样的页面，那么当上海的web服务器负担过重或者宕机时，就可以将流量重定向到北京。
· LC是链路的负载均衡。应用于多链路，多出口的网络环境中。可以实现链路的负载分担，容错，和基于DNS的入站流量负载均衡。
· ASM主要是web应用防火墙。可以提供端到端的应用防护，监视和报告。
· SAM主要是提供基于SSL应用的安全防护。
· WA简单理解，就是web应用加速。
其实了解清楚了，F5也就不再那么神秘了。当然以上都是个人的理解，没有实际用过这些设备，有偏差支持恳请指正！
二、Radware Application Delivery
Radware在负载均衡方面的产品线主要分为：
AppDirector（AD）
LinkProof（LP）
AppWall
AppXML
AppXcel
1、 AppDirector
一般简称为AD，Radware将其称为intelligent application delivery controller (ADC)，即智能应用交付控制器，并将其解决方案成为ADC Solution。说白了，和F5 LTM是同一类产品，就是服务器负载均衡。工作原理基本相同，主要区别应该是在硬件的架构上。
2、LinkProof
一般简称为LP，和F5 BIG-IP LC相对应，是链路负载均衡产品。不过，与F5不同的是，AD和LP是两个独立的产品，不像F5，服务器负载均衡和链路负载均衡可以在同一硬件盒子的不同模块上实现。
3、AppWall
AppWall是WEB应用防火墙，和F5的ASM模块相对应，是一个独立的产品。
4、AppXML
AppXML是一款XML加速产品，主要是可以处理本来应该由服务器处理的XML类型文档的传输，减轻服务器负担。因为用专门的设备来处理XML文档，同时起到了加速的作用。
5、AppXcel
AppXcel是一款SSL加速产品，和AppXML类似，功能比较单一，主要是用专门的硬件设备来处理SSL的加密和解密，减轻服务器负担，加速SSL应用。
6、Alton
Alton原本是负载均衡领域响当当的品牌，被北电收购后，就有点没落了。现在Radware收购北电之后保留了这个产品线，继承了Alton原本的一些特色，主要是4-7层的应用交换机。不知道Alton在Radware手里会有这样的改变！
可以看出，Radware的产品线和F5区别蛮大的，F5是模块化，ALL-IN-ONE模式，而Radware是走“专”的路线，不同的应用用不同的硬 件平台来做。不过，值得一提的是，Radware的新平台，ODS-OnDemand Switch，同样集成了IPS，SSL加速，QoS等功能。通过升级license来增加功能和设备吞吐量同样是Radware区别于F5的一个特色。 当然，两个厂商的产品各有优劣，在此不再评述。
三、Array Networks
Array原本是SSL VPN领域的领导厂商之一，近几年在负载均衡领域也算是小有成就。
Array的负载均衡产品线也比较简单，分为APV系列和TMX系列。
APV系类主要功能是服务器负载均衡和链路负载均衡，同时提供了SSL加速，HTTP压缩和缓存，应用安全防护等功能。
TMX在功能上和APV基本没有区别，不过奇怪的是，不知道为什么Array的官网关于TMX的参数很简略，甚至连吞吐量这样的参数都没有表明。
备注：F5和array的负载均衡的产品有什么区别和优劣势
二者都属于专门做负载均衡的厂商，都有链路负载均衡、服务器负载均衡和广域网负载均衡。F5偏重于四层负载；Array偏重于七层负载。F5的产品是独立卖的，高端产品可以通过License开启多个功能；Array倡导的是all in one，所有功能都在一个产品上，通过License控制。F5是CPU+ASIC架构；Array是X86架构。F5有iRules，除了使用预定义算法外还可以定制算法，Array只能使用预定义好的算法。F5是一家上市大公司，Array是一家未上市小公司，F5提供二次开发接口；Array不提供二次开发。F5比较贵，Array比较便宜。
——————————————————————————————————————————————
负载均衡产品F5和Array的产品性能对比
——————————————————————————————————————————————
1.数据包处理机制：
Array APV是属于应用前端加速产品的设计方向，当数据包到达array时，通过使用SpeedStack技术，即一次处理数据所有功能，使数据处理效率与速度大大提高。
F5 BIG-IP是属于L4-L7层负载均衡交换机的设计方向，当数据包到达F5设备时，如果是二、三层流量，经由Broadcom芯片快速处理，如果是四层数据，将由基于统一的ASIC芯片进行快速处理。如果是四层以上的数据，就只能通过交换板与主板互连的两条千兆网线传到CPU，进行健康检查，irules，流量重定向，防DOS攻击，带宽管理等实施复杂的第 7 层交换算法以及从事管理任务。分层处理导致数据延迟。
2. 产品软件体系架构
Array 操作系统是ArrayOS，使用的自己编制的硬件操作系统，从稳定性来说系统不依赖于底层操作系统的稳定性，所以要相应的稳定。我们没有公开的安全漏洞隐患。从性能来说由于使用了SpeedStack技术，相应的速度要高。
F5的操作系统是Linux操作系统上起的应用服务（TMOS） ，从稳定性来说系统依赖于linux的稳定性。在实际应用中，相应的稳定性会差，另外linux是开放源操作系统，有严重的安全隐患，从性能来说，采用了分层的处理，降低了数据包处理的速度。
3.产品硬件架构
Array APV ALL-IN-ONE可行性高，服务器负载均衡、链路负载均衡、广域网负载均衡、Cache、Http 压缩、SSL 加速、Webwall、Cluster模块，以上所有的功能可以同时集中在一台设备上，而且价格比单独购买便宜。
F5 BIG-IP ALL-IN-ONE可行性差，服务器负载均衡、链路负载均衡（单独设备）、广域网负载均衡（单独设备）、Cache、Http 压缩、SSL 加速….. 以上所有的功能可以全部在一台设备中使用，但是价格与单独购买差不多，与其这样还不如单独购买，稳定性更强，所以对于F5 ALL-IN-ONE 只是一个概念，没有真正的可行性。
4.服务器负载均衡功能
负载均衡范围：Array是基于L2-L7的负载均衡，而F5是L3-L7的负载均衡。
负载均衡算法：Array负载均衡算法多达20多种，特别是七层的负载均衡算法多达15种， F5只有基于4层的负载均衡算法，例如最少连接数，最快响应等。要实现七层负载均衡，必须用Irules。
会话保持算法：Array具备丰富的七层会话保持算法，例如：基于cookie、IP、Qos、ssl id、Url ,Header、Hostname， F5只有基于ip、网段等四层算法， 七层的只有基于cookie的。
健康检查方法：Array具备12种健康检查方法，还可以自定义健康检查方法，特别是一些非标准TCP应用，需要检查到应用级健康状态，就需要自定义健康检查方法。 而F5是无法实现非标准TCP应用的应用级健康检查的。
irules是F5拿出去掩盖自己功能缺陷的东西，irules就是TCL，一种编程语言，由于自身功能做的不够完善，特别是七层功能，就需要通过临时编写程序来解决问题，说的通俗点这叫临时打补丁，而且这个补丁是没有通过专业测试人员反复测试过的。稳定性、性能、对系统现有功能的影响等等都是一个未知数，就直接运行在用户的生产环境下，这是不负责任的表现。而F5却把它当成自己的”优势”。
——————————————————————————————————————————————
反向代理和负载均衡有何区别？
——————————————————————————————————————————————
链接：https://www.zhihu.com/question/20553431/answer/130698230
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
SLB(服务器负载均衡)：在多个提供相同服务的服务器的情况下，负载均衡设备存在虚拟服务地址，当大量客户端从外部访问虚拟服务IP地址时，负载均衡设备将这些报文请求根据负载均衡算法，将流量均衡的分配给后台服务器以平衡各个服务器的负载压力，避免在还有服务器压力较小情况下其他服务达到性能临界点出现运行缓慢甚至宕机情况，从而提高服务效率和质量，因此对客户端而言，RS（real server 实际服务器）的IP地址即是负载均衡设备VIP（虚拟服务地址IP）地址，真正的RS服务器IP地址对于客户端是不可见的。
二、SLB的三种传输模式：七层SLB和四层SLB的区别：
四层SLB：配置负载均衡设备上服务类型为tcp/udp，负载均衡设备将只解析到4层，负载均衡设备与client三次握手之后就会和RS建立连接；
七层SLB：配置负载均衡设备服务类型为http/ftp/https等，负载均衡设备将解析报文到7层，在负载均衡设备与client三次握手之后，只有收到对应七层报文，才会跟RS建立连接。
在负载均衡设备中，SLB主要工作在以下的三种传输模式中：
反向代理模式
透传模式
三角模式
根据不同的模式，负载均衡设备的工作方式也不尽相同，但无论在哪种模式下，客户端发起的请求报文总是需要先到达负载均衡设备进行处理，这是负载均衡设备正常工作的前提。模拟网络拓扑环境：
Client：10.8.21.40
负载均衡设备：172.16.75.83
VIP：172.16.75.84
RS1IP：172.16.75.82
RS2IP：172.16.75.85
在整个报文交互过程中，采用Tcpdump和Wireshark分别在RS和Client处抓包，然后使用Wireshark进行报文解析。
三、 反向代理模式：反向代理：普通的代理设备是内网用户通过代理设备出外网进行访问，而工作在这种模式下的负载均衡设备，则是外网用户通过代理设备访问内网，因此称之为反向代理。
在反向代理模式下：
当负载均衡设备收到客户端请求后，会记录下此报文（ 源IP地址、目的IP地址、协议号、源端口、目的端口，服务类型以及接口索引），将报文目的地址更改为优选后的RS设备的IP地址，目的端口号不变，源地址修改为负载均衡设备下行与对应RS设备接口的IP地址，源端口号随机发送给RS；
当RS收到报文后，会以源为RS接口IP地址，目的IP设备地址回复给负载均衡设备，负载均衡设备将源修改为VIP，目的端口号修改为客户端的源端口号，目的IP修改为Client的源IP回复报文。
- 查看报文解析结果：
配置完成后，Client访问RS服务器，返回成功，整个报文交互过程如下 ：
<img src="https://pic2.zhimg.com/50/v2-c10a0ba07129662dd4ad7c8c8a696695_hd.png" data-rawwidth="610" data-rawheight="191" class="origin_image zh-lightbox-thumb" width="610" data-original="https://pic2.zhimg.com/v2-c10a0ba07129662dd4ad7c8c8a696695_r.png">
Client和负载均衡设备之间的报文交互过程
<img src="https://pic1.zhimg.com/50/v2-3ea4b99cad578b6b3cfd29d1890a60e0_hd.png" data-rawwidth="620" data-rawheight="113" class="origin_image zh-lightbox-thumb" width="620" data-original="https://pic1.zhimg.com/v2-3ea4b99cad578b6b3cfd29d1890a60e0_r.png">
RS和负载均衡设备之间报文交互过程
- 结果分析
分析整个报文交互过程：
TCP握手过程：
首先Client向负载均衡设备发送TCP SYN报文请求建立连接，源IP为Client的IP 10.8.21.40，源端口号50894，目的IP为VIP地址172.16.75.84，目的端口号80；
收到请求报文后，负载均衡设备会以源IP为VIP地址172.16.75.84，端口号80，目的IP 10.8.21.40，目的端口号50894回应SYN ACK报文；
Client收到报文后回复ACK报文，TCP三次握手成功。
HTTP报文交互过程：
当负载均衡设备与client完成三次握手后，因为配置的七层SLB，如果收到HTTP请求，就会根据负载均衡算法和服务器健康状态优选出对应的RS（在这次过程中选择的RS设备为172.16.75.82），然后与RS建立TCP连接：
负载均衡设备发送TCP SYN报文请求连接，源IP为负载均衡设备与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报文，负载均衡设备回复ACK报文建立三次握手；
之后，负载均衡设备再将收到的HTTP报文源IP修改为与RS相连下行接口IP地址172.16.75.83，源端口号为随机端口号，将报文发送给RS；
当RS收到报文后，使用源为本地IP 172.16.75.82，目的IP为172.16.75.83进行回复，所以报文直接回复给负载均衡设备；
当负载均衡设备收到RS的回应报文后，将报文的源修改为VIP地址172.16.75.84，目的IP为10.8.21.40发送回Client，再将目的端口号修改为HTTP请求报文中的源端口号，服务器访问成功。
<img src="https://pic2.zhimg.com/50/v2-0ddbc3871dac8bce55d0dd26a6e5f1bd_hd.png" data-rawwidth="903" data-rawheight="293" class="origin_image zh-lightbox-thumb" width="903" data-original="https://pic2.zhimg.com/v2-0ddbc3871dac8bce55d0dd26a6e5f1bd_r.png">
由上述的过程可以看出，在RS端上，client的真实IP地址被负载设备修改成与RS相连接口的IP地址，所以RS无法记录到Client的访问记录，为了解决这个问题，可以采用在HTTP报文头中添加X-Forwarded-For字段，本文不做赘述，可以自行查询。
四、透传模式：当负载均衡设备工作在透传模式中时，RS无法感知到负载均衡设备的存在，对于Client来说，RS的IP地址就是负载均衡设备的VIP地址。
在这种模式下，当负载均衡设备收到源为Client的IP，目的IP为本地VIP地址的报文时，会将报文根据负载均衡策略和健康状况发送给最优的RS设备上，继而RS设备会收到目的为本地IP，源为Client实际IP的请求报文；
然后RS将会直接回应此请求，报文的目的IP地址为Client的IP地址，当负载均衡设备收到此报文后，将源IP地址修改为VIP地址，然后将报文发送给Client。
- 报文解析结果：
同样在RS端和Client端抓取交互报文：
<img src="https://pic3.zhimg.com/50/v2-35504893ad1c1c5e31cde46777b52866_hd.png" data-rawwidth="625" data-rawheight="136" class="origin_image zh-lightbox-thumb" width="625" data-original="https://pic3.zhimg.com/v2-35504893ad1c1c5e31cde46777b52866_r.png">
Client和负载均衡设备之间的报文交互过程
<img src="https://pic1.zhimg.com/50/v2-950fe59a2215c3aa311af25e2c16ad38_hd.png" data-rawwidth="622" data-rawheight="117" class="origin_image zh-lightbox-thumb" width="622" data-original="https://pic1.zhimg.com/v2-950fe59a2215c3aa311af25e2c16ad38_r.png">
RS和负载均衡设备之间的报文交互过程
- 结果分析：
TCP握手过程：
同反向代理模式交互过程
HTTP报文交互过程：
Client向负载均衡设备的VIP地址172.16.75.84以源IP 10.8.21.40发送HTTP请求，当负载均衡设备收到报文后，与优选后的RS进行TCP三次握手，过程同反向代理模式，然后将收到的HTTP报文，不改变报文的源IP地址和源/目的端口号，只修改目的IP修改为优选后的RS地址172.16.75.82；
当RS收到源来自IP 10.8.21.40的报文后，回复报文给IP地址10.8.21.40，此时要注意，必须在RS上配置回复报文经过负载均衡设备，负载均衡设备会将源IP修改为VIP地址172.16.75.84，然后转发给Client，否则Client将会收到源IP为172.16.75.82的HTTP报文，服务器访问失败。
<img src="https://pic1.zhimg.com/50/v2-919aed35b9aa3e41f1a17044aaf52344_hd.png" data-rawwidth="886" data-rawheight="299" class="origin_image zh-lightbox-thumb" width="886" data-original="https://pic1.zhimg.com/v2-919aed35b9aa3e41f1a17044aaf52344_r.png">
五、 三角模式：
在三角模式下，当客户端发送请求到负载设备上时，负载均衡设备会计算出最优RS，然后直接根据MAC地址将报文转发给RS，在RS上配置报文的源IP为VIP地址（一般配置在loopback口上），因此在这种情况下，RS会直接将报文发送给Client，即使回复报文经过负载均衡设备，此设备不做任何处理。由于报文在整个过程中传输途径类似于三角形，因此称之为三角模式。
- 报文解析结果：
分别在Client端和RS端抓包，内容如下：
<img src="https://pic3.zhimg.com/50/v2-f14dda14a2584b15e6feb82d9d30bea6_hd.png" data-rawwidth="606" data-rawheight="119" class="origin_image zh-lightbox-thumb" width="606" data-original="https://pic3.zhimg.com/v2-f14dda14a2584b15e6feb82d9d30bea6_r.png">
Client和负载均衡设备之间的报文交互过程
<img src="https://pic4.zhimg.com/50/v2-667f8cb715128027cfc7d41a4bd80ba7_hd.png" data-rawwidth="608" data-rawheight="116" class="origin_image zh-lightbox-thumb" width="608" data-original="https://pic4.zhimg.com/v2-667f8cb715128027cfc7d41a4bd80ba7_r.png">
RS 和负载均衡设备之间的报文交互过程
- 结果分析：
TCP握手过程：
由于采用了4层SLB，所以在TCP握手过程中与上述的7层SLB有些不同，当Client和RS完成三次握手之后，此时负载均衡设备会直接选择RS，然后跟RS建立TCP三次握手；
在三角模式环境中，由于RS的Loopback口和负载均衡设备上都存在着VIP地址172.16.75.84，当负载均衡设备经过负载均衡算法选择出对应的RS后，会根据实际配置的RS的IP地址对应的mac地址，将报文以目的mac为RS，目的IP为VIP的方式建立TCP连接。
HTTP报文交互过程：
<img src="https://pic4.zhimg.com/50/v2-ba2a56bdecbd0844a760a0486d54a56f_hd.png" data-rawwidth="887" data-rawheight="299" class="origin_image zh-lightbox-thumb" width="887" data-original="https://pic4.zhimg.com/v2-ba2a56bdecbd0844a760a0486d54a56f_r.png">
首先Client向负载均衡设备的VIP发送HTTP请求，源为10.8.21.40，当负载均衡设备收到报文后，将报文直接转发给RS，当RS收到源IP为10.8.21.40，目的IP为本地Loopback口IP地址172.16.75.84的报文后，直接将报文回复给10.8.21.40，同样源为IP地址172.16.75.84，由此访问服务器成功。
在三角模式中，由于回复报文负载均衡设备不做任何处理，所以非常适合于RS到Client方向流量较大或者连接数目较多的组网环境。
采用三角模式时，必须注意RS有路由可以到达Client，并且在RS的Loopback接口上必须有负载均衡设备的VIP地址，否则即使RS设备收到Client的请求报文也会直接丢弃报文，不作回应。
六、总结由于反向代理模式中在RS侧只能收到源为负载均衡设备IP的报文，因此可以使用防火墙增加安全性，只允许源IP为负载均衡设备的IP地址的报文通过，同时增加X-Forwarded-For字段也可以让RS只允许有此字段的报文进行访问，因此安全性相对较高。
<img src="https://pic3.zhimg.com/50/v2-cbfce85101a299ea4e86a89b238efd56_hd.png" data-rawwidth="937" data-rawheight="628" class="origin_image zh-lightbox-thumb" width="937" data-original="https://pic3.zhimg.com/v2-cbfce85101a299ea4e86a89b238efd56_r.png">
反向代理是实现负载均衡的一种方法。
先谈反向代理。用户在请求时，先把请求发送给代理的服务器，然后由代理服务器根据算法去请求真实的服务器，最后返回给用户。这种做法，其一是提高了安全性；其二是通过多台的real server分担了用户的请求，实现了负载均衡。
再谈负载均衡。负载均衡的出现，是通过横向的扩展，尽可能地降低单台服务器的压力。常见WEB层面的负载均衡的方案有硬件F5、Nginx代理、LVS、各个云商的负载均衡服务(如AWS的ELB服务)等。负载均衡后面连的一般是实际提供服务的服务器，如通过ELB服务，可以做到流量的均匀分担，从而减少单机服务器的压力。
由于增加了负载均衡这层，所以单纯地使用某个方案还是要考虑单点的问题。负责由于负载均衡这个服务器未能承受住压力，宕机了，服务也是不可用的。所以Nginx、LVS尽量配置多台代理，可以故障转移和故障报警，从而及时去处理代理层服务器的问题。ELB是亚马逊提供的服务，它本身的实现底层就有数百甚至上千的机器，所以把它想象成一个代理集群就好。
以上是大致的说了下区别，具体的实现还需要结合实际的业务情况。
负载均衡，是把命令转发到不同的服务器上，均衡各个服务器