网络七层模型中包括：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。每一层分别解决网络连接层面特定范围的问题。
Web应用开发主要是基于应用层协议进行接口设计、开发以及服务之间的通信。在Web开发的过程中，通常我们很少关注其它层的协议，比如传输层、网络层级数据链路层。
在当前应用系统的演进中，会随着系统本身承载并发的提高而进行架构的演进。应用的扩展分为横向和纵向扩展，应用系统通常会利用负载均衡服务来达到服务节点的横向扩展。
比如我们现在用的比较多的Nginx或者Apache反向代理负载均衡服务，默认是基于应用层Http协议实现的七层负载均衡。通过配置upstream定义上游节点地址、负载权重以及重连超时策略等；通过配置location配置具体的路由策略。Nginx在接收到http请求后根据请求的url进行对应的路由选择，确定具体处理的上游节点后修改source ip和 dest ip并将请求转发到对应节点进行处理。接收到处理结果后再还原source ip和dest ip并将结果返回给调用方。这样就完成了一次http请求的调用。
从底层原理看，七层负载均衡需要分别跟客户端及上游服务器建立网络连接，同时要修改请求的报文（源、目标地址）。这样对负载均衡服务器的性能必然会产生影响，同时所有的流量也都会经过负载均衡服务器，无法满足上游节点的线性扩展。因为可能扩展到数十台服务器后负载均衡服务器的网卡带宽就已经成了瓶颈。那这个问题怎么解决了？在当前主流的互联网公司通常会采用链路层（二层）负载均衡，如下图：
基于链路层的负载均衡通常也称为三角模式负载均衡。这样负载均衡模式有效解决了负载均衡服务器带宽瓶颈的问题。通常我们的请求报文数据较小，但响应的报文数据量可能很大。可能是一篇博文的内容甚至是一个图片，可能要几十K甚至几十M。通过再请求报文中修改目标MAC地址的方式将请求转发给上游服务器，同时上游服务器查询到结构后直接将相应结果发送给请求客户端。
当然还有基于四层（通常是TCP）和三层（基于IP）的负载均衡，都在不同场景下发挥作用。后续再针对其它层负载均衡单独进行描述。
以上是个人的肤浅理解，可能有不正确的地方，还望各位不吝赐教！
