负载均衡分类四层负载均衡真的是在四层吗
数据链路层负载均衡网络层负载均衡
IP隧道传输（IP Tunnel）网络地址转换（NAT） 负载均衡到底是转发还是代理总结 负载均衡分类
工作学习中我们接触过形形色色的负载均衡产品，但他们从形式上说都可以分为两种：四层负载均衡和七层负载均衡。
这里所说的四层、七层指的是经典的OSI七层网络模型的传输层和应用层。这里我们再来回顾一下OSI模型：
四层负载均衡的优势是性能高，七层负载均衡的优势是功能强。
然而四层/七层负载均衡这种我们已经习以为常的说法，真的就是字面上的含义吗？你有没有思考负载均衡到底是在做什么事情，它的本质是什么？为什么会有四层和七层的区别呢？
四层负载均衡真的是在四层吗我们现在所说的“四层负载均衡”是多种均衡器工作模式的统称，这些工作模式的共同特点是维持同一个TCP连接，而不是他只工作在第四层。
事实上，这些模式都主要工作在第二层（数据链路层）和第三层（网络层），单纯只处理第四层（传输层）的数据是无法做到负载均衡的。
因为数据链路层根据MAC地址寻找目标主机，网络层根据IP地址寻找目标主机，而传输层是在数据已经到达目标主机之后根据端口号寻找应用程序。
而OSI的下三层是媒体层，上四层是主机层，既然数据在传输层的时候已经到达目标主机了，也就谈不上流量转发，最多只能做代理。
根据工作的具体层次，“四层负载均衡”又包含了数据链路层（二层）负载均衡和网络层（三层）负载均衡。
数据链路层负载均衡数据链路层传输的内容是数据帧（frame），比如常见的以太网帧等。数据帧里面会存储 MAC源地址和MAC目标地址。
我们都知道每一块网卡都有独立的MAC地址，通过数据帧上的MAC源地址和目标地址可以告诉交换机，数据是从哪块网卡发出，送到哪块网卡的。
数据链路层负载均衡所做的工作，就是修改请求的数据帧中的MAC目标地址，让用户原本发送给负载均衡器的数据帧，被负载均衡器根据新的MAC目标地址转发到某个真实服务器上。
由于二层负载均衡器在转发时只修改了帧的MAC目标地址，并没有改动三层IP数据包中的目标IP，因此它的目标IP仍然是负载均衡器的IP。而只有保证真实服务器的IP地址和数据包的目标IP一致，数据才能被正确处理。因此需要把真实服务器集群中的所有机器的虚拟IP（VIP）配置成和负载均衡器的IP一样，才能使经过负载均衡器转发之后的数据包在真实服务器中顺利的使用。也正是因为真实服务器的虚拟IP和数据包中的目标IP是一致的，所以响应结果就不需要再通过负载均衡器转发到客户端，因此数据链路层负载均衡效率是相当高的。该模式整个过程如下图所示：
上述工作模式整个请求、转发、响应的链路形成了一个“三角关系”，所以这种负载均衡模式也被形象的称为“三角传输模式”（Direct Server Return，DSR），也称为“单臂模式”（Single Legged Mode）或者“直接路由”（Direct Routing）。
数据链路层负载均衡直接改写MAC目标地址的工作原地决定了它与真实服务器的通信必须是二层可达的，也就是说必须位于同一个子网中。
网络层负载均衡网络层传输的单位是数据包。数据包分为Header和Payload，Header里面会存储源IP地址和目标IP地址。
参考二层负载均衡器修改目标MAC地址的思路，通过改变这里的源/目标IP地址来实现数据包的转发，具体有两种常见的方式：IP隧道传输、网络地址转换。
IP隧道传输（IP Tunnel） 保持原数据包不变，新创建一个数据包，把原数据包的Header和Payload整个作为新数据包的Payload，并在这个新数据包的Header里写入真实服务器的IP作为目标地址，如下图所示：
然后把这个新数据包发送出去。经过三层交换机的转发，真实的服务器收到数据包后，必须在接收入口处进行拆包，将由负载均衡器添加的那个Header卸载掉，还原出来原始的数据包进行使用。这样真实服务器拿到了一个原本不是发送给他的数据包，达到流量转发的目的。这种“套娃式”的传输被称为“IP隧道”传输。该模式整个过程如下图所示：
因为要封装新的数据包，所以IP隧道转发模式比直接路由的效率要低，但是由于没有修改原始数据包内容，所以负载均衡器转发来的请求，可以有真实服务器直接返回给客户端，无须经过负载均衡器的转发。而且由于IP隧道工作在网络层，可以跨越子网，摆脱了直接路由模式中必须在同一个子网的束缚。
从上述过程中也可以发现该模式有两个缺点：
他要求真实服务器必须支持“IP隧道协议”，也就是自己可以拆包卸载掉外面一层的Header，进而还原出原始数据包。值得欣慰的是现在几乎所有的Linux系统都支持IP隧道协议。这种模式和数据链路层负载均衡一样，需要专门的配置保证真实服务器的VIP和负载均衡器的IP保持一致。
然而，对服务器进行虚拟IP的配置并不是在任何情况下都可行，尤其是当多个服务公用一台物理机的时候，此时就必须考虑第二种方式——修改原数据包。
网络地址转换（NAT） 直接修改原数据包的目标IP地址，修改后原本由客户端发送给负载均衡器的数据包也会被三层交换机转发到真实服务器。因为修改了目标IP地址，如果真实服务器直接将响应包返回给客户端，响应包的源IP地址是真实服务器的IP而不是负载均衡器的IP，所以客户端是不能正确处理响应数据包的。所以只有让响应包先回到负载均衡器，由负载均衡器把响应包的源IP改为负载均衡器的IP，然后转发给客户端，这样才能保证客户端正确处理数据包，让响应包先回到负载均衡器 只需要将真实服务器的网关地址设置为负载均衡器的的地址即可实现，这种负载均衡模式就是“网络地址转换”（Network Address Translation，NAT）。该模式整个过程如下：
在流量压力比较大的时候，NAT模式因为需要负载均衡器做请求和响应的转发，所以会相比直接路由和IP隧道模式有较大的性能损失，导致负载均衡器成为网络瓶颈。
还有一种更加彻底的NAT模式——Source NAT（SNAT），这种模式处了修改目标IP地址，还会将源IP地址修改为负载均衡器的IP，这样也就无需真实服务器配置网关了，因为在客户端和真实服务器看来，都是直接只与负载均衡器打交道，客户端相对于服务器以及服务器相对于客户端都是透明的。但是这种“透明”在对一些服务器需要知道客户端IP的应用场景就无能为力了。
负载均衡到底是转发还是代理 前面说的“四层”负载均衡模式都属于“转发”，四层以上的负载均衡更应该称为“代理”。转发和代理的区别如下图：
转发，直接承载着TCP报文的底层数据格式（IP数据包或者以太网帧）转发到真实服务器上，此时客户端与相应请求的真实服务器维持着同一条TCP通道。代理，真实服务器、负载均衡器、客户端三者之间有两条独立的TCP通道来维持通信。
代理根据“哪一方能感知到”又分为正向代理（客户端可知代理的存在，服务端无感知）和反向代理（服务端可知代理的存在，客户端无感知）和透明代理（服务端和客户端都无感知，配置在网络中间设备上，比如路由器上的透明翻墙代理），而七层负载均衡正是属于反向代理的一种。
在网络性能上七层负载均衡相比于“四层”负载均衡的各种转发模式不尽人意，比如要多一轮TCP握手，负载均衡器本身也会因为带宽成为网络性能瓶颈。但因为工作在应用层，可以感知到通信的具体内容，所以在实际应用场景上，对数据的处理可以有更高的自由度，玩出更多的花样。
总结四层负载均衡并不意味着工作在网络协议栈的传输层。四层以下的负载均衡属于转发，四层以上的负载均衡因为已经到达目标主机，更符合代理。网络协议栈是个有趣的东西，还需要深入了解网络协议栈的工作原理。