引言
前面一篇文章对负载均衡进行了简介，其中谈到了各种负载均衡集群，下面我们来看下四层和七层负载均衡的区别。
四层、七层负载均衡简介
- 所谓四层就是基于 IP + 端口的负载均衡；
七层就是基于 URL 等应用层信息的负载均衡；
同理，还有基于 MAC 地址的二层负载均衡和基于 IP 地址的三层负载均衡。
换句换说，
二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址；
三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址；
四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器；
七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。
- 所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。
比如四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，
对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，
后续这个连接的所有流量都同样转发到同一台服务器处理。
七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，
比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，
还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。
举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，
那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
-
负载均衡器通常称为四层交换机或七层交换机。
四层交换机主要分析 IP 层及 TCP/UDP 层，实现四层流量负载均衡。
七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如 HTTP 协议 URI 或 Cookie 信息。 -
负载均衡分为 L4 Switch（四层交换），即在 OSI 第 4 层工作，就是 TCP 层啦。
此种 Load Balancer 不理解应用协议（如 HTTP/FTP/MySQL 等等）。例子：LVS，F5。 -
另一种叫做 L7 Switch（七层交换），OSI 的最高层，应用层。
此时，该 Load Balancer 能理解应用协议。例子： HAProxy，MySQL Proxy。
注意：上面的很多 Load Balancer 既可以做四层交换，也可以做七层交换。
当前可以看到对于 F5, Array 等硬件负载均衡设备本身也是支持 7 层负载均衡的，
同时在 4 层负载均衡的时候我们还可以设置是否进行会话保持等高级特性。
要明白 ** 4 层负载均衡本质是转发，而 7 层负载本质是内容交换和代理**，具体说明如下：
区别
1. 技术原理上的区别
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的 TCP 为例，负载均衡设备在接收到第一个来自客户端的 SYN 请求时，即通过上述方式选择一个最佳的服务器，
并对报文中的目标 IP 地址进行修改(改为后端服务器 IP），直接转发给该服务器。
TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。
在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，
再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的 TCP 为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，
只能先代理最终的服务器和客户端建立连接（TCP 三次握手）后，才可能接收到客户端发送的真正应用层内容的报文，
然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立 TCP 连接。
所以从这个技术原理上来看，七层负载均衡明显地对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
2. 应用场景的需求
七层应用负载均衡的好处，是使得整个网络更“智能化”, 例如访问一个网站的用户流量，可以通过七层的方式，
将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。
当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。
很多在后台(例如 Nginx 或者 Apache )上部署的功能可以前移到负载均衡设备上，例如客户请求中的 Header 重写，服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的 SYN Flood 攻击，即黑客控制众多源客户端，使用虚假 IP 地址对同一目标发送 SYN 攻击，
通常这种攻击会大量发送 SYN 报文，耗尽服务器上的相关资源，以达到 Denial of Service(DoS) 的目的。
从技术原理上也可以看出，四层模式下这些 SYN 攻击都会被转发到后端的服务器上；
而七层模式下这些 SYN 攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。
另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如 SQL Injection 等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。
现在的 7 层负载均衡，主要还是着重于应用广泛的 HTTP 协议，所以其应用范围主要是众多的网站或者内部信息平台等基于 B/S 开发的系统。
4 层负载均衡则对应其他 TCP 应用，例如基于 C/S 开发的 ERP 等系统。
3. 七层应用需要考虑的问题
- 是否真的必要，七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。
在设计系统时需要考虑四层七层同时应用的混杂情况。 - 是否真的可以提高安全性。例如 SYN Flood 攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗 DDoS 能力，
否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。 - 是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。
最简单的一个考核就是能否取代后台 Nginx 或者 Apache 等服务器上的调度功能。
能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。
