一、http重定向
当http代理（比如浏览器）向web服务器请求某个URL后，web服务器可以通过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转。
性能缺陷：
1、吞吐率限制
主站点服务器的吞吐率平均分配到了被转移的服务器。现假设使用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率要达到3000reqs/s才能完全发挥三台子服务器的作用，那么如果有100台子服务器，那么主服务器的吞吐率可想而知得有大？相反，如果主服务的最大吞吐率为6000reqs/s，那么平均分配到子服务器的吞吐率为2000reqs/s，而现子服务器的最大吞吐率为1000reqs/s，因此就得增加子服务器的数量，增加到6个才能满足。
2、重定向访问深度不同
有的重定向一个静态页面，有的重定向相比复杂的动态页面，那么实际服务器的负载差异是不可预料的，而主站服务器却一无所知。因此整站使用重定向方法做负载均衡不太好。
我们需要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例如下载。你可以去很多镜像下载网站试下，会发现基本下载都使用了Location做了重定向。
二、DNS负载均衡
DNS负责提供域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它就像http重定向转换策略一样，将用户的请求分散到多台服务器上，但是它的实现机制完全不同。
使用dig命令来看下"baidu"的DNS设置
可见baidu拥有三个A记录
相比http重定向，基于DNS的负载均衡完全节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职能。但不同的是，作为调度器，DNS服务器本身的性能几乎不用担心。因为DNS记录可以被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过期后才会重新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上可以无限增加实际服务器的数量。
特性:
1、可以根据用户IP来进行智能解析。DNS服务器可以在所有可用的A记录中寻找离用记最近的一台服务器。
2、动态DNS：在每次IP地址变更时，及时更新DNS服务器。当然，因为缓存，一定的延迟不可避免。
不足：
1、没有用户能直接看到DNS解析到了哪一台实际服务器，加服务器运维人员的调试带来了不便。
2、策略的局限性。例如你无法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工作在HTTP层面，它可以充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，比如根据请求不同的URL来进行合理的过滤和转移。
3、如果要根据实际服务器的实时负载差异来调整调度策略，这需要DNS服务器在每次解析操作时分析各服务器的健康状态，对于DNS服务器来说，这种自定义开发存在较高的门槛，更何况大多数站点只是使用第三方DNS服务。
4、DNS记录缓存，各级节点的DNS服务器不同程序的缓存会让你晕头转向。
5、基于以上几点，DNS服务器并不能很好地完成工作量均衡分配，最后，是否选择基于DNS的负载均衡方式完全取决于你的需要。
三、反向代理负载均衡
这个肯定大家都有所接触，因为几乎所有主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工作就是转发HTTP请求。
相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：
1、任何对于实际服务器的HTTP请求都必须经过调度器
2、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不需要经过调度反馈，是实际服务器直接发送给用户）
特性：
1、调度策略丰富。例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。
2、对反向代理服务器的并发处理能力要求高，因为它工作在HTTP层面。
3、反向代理服务器进行转发操作本身是需要一定开销的，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，但是当后端服务器处理请求的时间非常短时，转发的开销就显得尤为突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。
4、反向代理服务器可以监控后端服务器，比如系统负载、响应时间、是否可用、TCP连接数、流量等，从而根据这些数据调整负载均衡的策略。
5、反射代理服务器可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器上（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。
四、LVS 工作在4层
五、工作在4层和7层的硬件
下面部分详细讲解了三种LVS模式的原理，转自
1、lvs-nat：
多目标的DNAT：通过将请求报文的目标地址和目标端口修改为挑选出的某RS的RIP和PORT实现转发； 注意: lvs-nat 需开启连接追踪机制, 并发能力有限 (1) RIP和DIP必须在同一IP网络, 且使用私网地址，RS的网关应该指向DIP(保证响应报文必须经由VS)； (2) 请求和响应报文都要经由director转发；极高负载的场景中，Director可能会成为系统性能瓶颈； (3) 支持端口映射； (4) VS必须为Linux，RS可以是任意的OS； (5) RS的RIP与Director的DIP必须在同一IP网络； 补充: 调度器上需要两块网卡,一个配置vip 一个配置dip
2、lvs-dr：direct routing 直接路由
通过为请求报文重新封装一个MAC首部进行转发,源MAC是DIP所在接口的MAC,目标MAC是挑选出的某RS的RIP所在接口的MAC地址；IP首部不会发生变化（源IP为CIP，目标IP始终为VIP）； (1) 确保前端路由器将目标IP为VIP的请求报文一定会发送给Director； 解决方案： 在路由器上静态绑定VIP和Director的MAC地址； 禁止RS响应VIP的ARP请求,禁止RS的VIP进行通告 (a) arptables； (b) 修改各RS的内核参数，并把VIP绑定在l0的别名上,实现禁止其响应； arp_ignore, arp_announce (2) RS的RIP可以使用私有地址，也可以使用公网地址； (3) RS跟Director必须在同一物理网络中；RS的网关必须不能指向DIP (4) 请求报文必须由Director调度，但响应报文必须不能经由Director； (5) 不支持端口映射； (6) 各RS可以使用大多数的OS；一般是linux
情形1: RIP DIP VIP 都在一个网络, 都是公网IP 地址
情形2: VIP 是公网ip地址, RIP,DIP是私有地址, 情况要复制些, RS要通过另一个路由出去
注意:
一个路由其可以有多个网络接口
一个交换机可以承载多个ip网络
所以路由器1和路由器2可以使用同一个
私网交换机和公网交换机也可以用同一个
3、lvs-tun：ip tunnel，ip隧道
转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而是在原有的IP首部之外再次封装一个IP首部（源IP为DIP，目标IP为RIP）； (1) RIP，DIP，VIP全得是公网地址； (2) RS的网关不能也不可能指向DIP； (3) 请求报文经由Director调度，但响应报文将直接发给CIP； (4) 不支持端口映射； (5) RS的OS必须支持IP隧道功能； 注意: 容易超出MTU, 弊端比较大
4、lvs-fullnat：非标准模型, ipvs默认不支持,ipvsadm也不支持, nat模型的扩展（阿里云的SLB使用的是此方式）
通过同时修改请求报文的源IP地址（cip-->dip）和目标IP地址（vip --> rip）实现转发； (1) VIP是公网地址；RIP和DIP是私网地址，且通常不在同一IP网络中，但需要通过路由互相通信； (2) RS收到的请求报文的源IP为DIP，因此其响应报文将发送给DIP； (3) 请求报文和响应报文都必须经由director； (4) 支持端口映射； (5) RS可使用任意OS；
