介绍
ipvs 是内核中的一个模块，工作在四层（传输层），正因如此，它并不理解上层包中的内容是什么，只负责转发，所以它不会像Nginx、Haproxy那样可以实现根据 url实现负载均衡。因为ipvs工作在内核，所以性能会比后面二者高一些。
ipvs 模块主要监控在input链上，当请求经过 PREROUTING 链，到达INPUT 链时，ipvs 会检查一下该报文的 IP + Port，看看是不是来访问LVS所管辖的服务，如果是，则直接转发到 FORWARD 链，然后到达后面提供服务的服务器（Real Server），后面的多台RS如何选择，选择哪个就是LVS中算法控制的。根据相应的负载均衡算法来选择RS。
NAT 模式
NAT（Network Address Translation，网络地址转换），这种模式比较简单，因为只需要设置一下iptables规则即可。他的流程是这样的：
当请求到达director（负载均衡器）时，director会根据算法选择一台RS，然后通过网络地址转换的方法，将报文转发到这台RS，RS将报文处理后，先发送给director，然后再由director将应答返回给客户端。因为是使用NAT模式，director和 RS们分别处在2 、3层，因此RS的网关必须指向director，这就出现了一个问题，就是来回的报文都必须要经过director，随着RS的增多，性能会大大降低，director会成为瓶颈。但是NAT模式的RS不管是什么操作系统的主机，只要能提供服务，能收到报文可提供服务。
DR 模式
由于NAT模式来回都要经过director，所以说性能特别的低，为了解决这个问题，出现了DR模式。
DR（Director Routing，直接路由模式）这种模式在RS收到报文时，处理后直接返回给客户端，而不需要经过director的转发，性能大大提升。DR模式过程大致是这样的：
客户端请求到达director时，director会根据算法将该请求的目的MAC地址改为对于RS的MAC，然后来一个ARP广播，但是后端的RS收到director的ARP，发现这个包上面的IP地址并不是我的，于是会不理这个ARP。为了解决这个问题，就必须在每个RS上配置一个VIP，那么问题又来了，如果每个RS都配置相同的VIP，就是导致ARP记录不唯一（MAC地址和IP地址不是一一对应），当客户端发请求到VIP时，RS上都配有VIP，到底哪个RS接收？如果都接收，那么director将起不到相应作用，会不会冲突？为了解决这些问题，就必须要抑制ARP，用户发来的报文，到达director时，让RS的VIP不做任何应答。这样就解决了多个VIP的问题。RS收到报文，处理后直接返回给后端。
DR模式虽然性能高，缺点当然也有，因为请求到达director时候，由于director向RS转发需要通过MAC，数据链路层，因此就必须将director和RS放在同一局域网内。
TUN 模式
DR模式的性能已经特别高，为何还会出现一个TUN模式呢？TUN模式的出现与性能无关，与场景有关。如果多台real server不在一个局域网呢，一个在北京，一个在上海，怎么让他们提供业务呢？于是就出现了TUN模式。
大部分隧道都是是在报文上做手脚，TUN实现的方式就是当客户端请求到达director时候，将报文再次增加一层报头，该报头根据预先设定的负载均衡算法选择一台机器，然后将报头指向这台主机，目的就是将报文引领到远程的RS上，当报文到达RS时，由于和正常的报文不一样，默认会以错误的报文将其丢弃，因此就必须要让RS端也能明白这层报头的含义，所以说director和后面的RS必须得支持TUN隧道的协议，做额外的配置才可以。