四层负载 vs 七层负载——从概念到选型一次讲清

做后端迟早要碰负载均衡。一开始只知道 Nginx 反向代理，后来发现还有 LVS、NLB、ALB 这些东西，文档里动不动就”四层”“七层”，听着像黑话。这篇把这两个概念、它们的区别、市面上的产品分类，以及什么场景选哪个，一次整理清楚。

先说结论

四层快但”瞎”——只看 IP 和端口，转发速度极快；七层慢但”聪明”——能读懂 HTTP 请求内容，做精细路由。大多数生产架构是 L4 在前扛量，L7 在后做智能分发。

什么是四层负载均衡

工作在 OSI 模型的传输层（第 4 层，TCP/UDP）。它只看 IP 地址 + 端口号，不解析应用层的任何内容。收到 TCP 连接或 UDP 数据报后，根据负载均衡算法（轮询、加权、最少连接等）把流量转发到后端服务器。

打个比方：快递分拣中心只看包裹上的地址和收件人编号，不拆包看里面是什么，直接往对应的卡车上扔。

核心特点：

• 不关心包里装的是 HTTP、MySQL 还是 Redis 协议
• 转发几乎是线速的，性能极高
• 对后端来说，客户端的 TCP 连接是”透传”的（或经过 NAT）
• 健康检查只能做到 TCP 端口探活

什么是七层负载均衡

工作在 OSI 模型的应用层（第 7 层，HTTP/HTTPS/gRPC 等）。它会拆开包裹，解析协议内容——URL 路径、Host 头、Cookie、Header、甚至请求体，然后根据这些信息做路由决策。

还是快递的比方：这次分拣中心会拆开包裹，看里面的商品类型——食品送冷链仓，3C 送电子仓，易碎品送专用通道。

核心特点：

• 能理解 HTTP 协议（部分产品也支持 gRPC、WebSocket）
• 可以根据 URL、域名、Header 做精细路由
• 支持 SSL/TLS 卸载（在负载均衡层终止加密，后端走明文）
• 可以做 WAF、限流、认证等安全功能
• 连接模型是”代理”——客户端到 LB 一段 TCP，LB 到后端另一段 TCP

核心区别对照表

维度	四层（L4）	七层（L7）
工作层级	传输层（TCP/UDP）	应用层（HTTP/gRPC/WebSocket…）
感知内容	IP、端口、TCP 标志	URL、Header、Cookie、Body
路由能力	只能按 IP:Port 分发	可按路径、域名、Header 精细路由
性能	极高（几乎线速转发）	较低（需解析协议，开销大）
SSL 卸载	不支持（透传加密流量）	支持（可终止 TLS）
会话保持	基于源 IP	基于 Cookie / Header
连接模型	透传或 NAT（客户端直连后端）	代理模式（两段 TCP 连接）
健康检查	TCP 端口探活	HTTP 状态码 / 内容检查
安全能力	基本（SYN Flood 防护）	WAF、限流、认证、请求过滤

一句话概括差异：四层做的是”搬运工”，七层做的是”调度员”。

市面上的产品分类

四层负载均衡

产品	说明
LVS (Linux Virtual Server)	Linux 内核级转发，性能极高，国内大厂标配
DPVS (基于 DPDK)	用户态转发，百万级并发
AWS NLB (Network Load Balancer)	AWS 四层，超低延迟
阿里云 NLB / CLB (TCP 模式)	阿里云四层负载
HAProxy (TCP 模式)	既能做 L4 也能做 L7，万金油
Keepalived + LVS	经典高可用四层方案
Cloudflare Spectrum	四层代理，支持任意 TCP/UDP 协议

七层负载均衡

产品	说明
Nginx / OpenResty	最主流的七层反向代理，生态最好
HAProxy (HTTP 模式)	高性能七层，功能丰富
Envoy	云原生 L7 代理，Service Mesh 的数据面核心
Traefik	云原生，自动服务发现，配置友好
AWS ALB (Application Load Balancer)	AWS 七层
阿里云 ALB	阿里云七层
Cloudflare / 各类 CDN	全球七层分发
Kong / APISIX	API 网关 = 七层负载 + API 管理
Istio (基于 Envoy)	Service Mesh，L7 流量治理

两者兼备的

HAProxy 是最典型的”双栖”选手——配置里写 mode tcp 就是四层，写 mode http 就是七层。Nginx 也能做 TCP/UDP 四层代理（stream 模块），不过它的强项还是七层。

哪个好？

没有绝对的好坏，只有场景匹配。

实际生产环境通常是 L4 + L7 混合部署，各取所长：

客户端请求
    ↓
┌─────────────────────────┐
│  L4 负载均衡 (LVS/NLB)  │  ← 扛住海量连接，分散到多台 L7 机器
└────────────┬────────────┘
             ↓
┌─────────────────────────┐
│  L7 负载均衡 (Nginx)     │  ← 按域名/路径精细路由、SSL 卸载、WAF
└────────────┬────────────┘
             ↓
┌─────────────────────────┐
│  后端服务集群             │
└─────────────────────────┘

这就是经典的”三级架构”：L4 在最前面当挡箭牌扛并发，L7 在后面做智能路由。

什么场景选四层

场景	为什么选 L4
数据库集群（MySQL、Redis、MongoDB）	非 HTTP 协议，只需要 TCP 转发
游戏服务器	自定义 TCP/UDP 协议，需要超低延迟
超高并发入口	百万级连接时 L7 扛不住，需要 L4 在前面分流
非 HTTP 协议（MQTT、FTP、自定义 RPC）	L7 不认识这些协议
直播/音视频流（RTMP、SRT）	需要 UDP/TCP 透传，延迟敏感
VPN / 隧道流量	加密流量透传，L7 解析不了
内部微服务 TCP 通信	简单分发就够了，不需要 HTTP 级别的路由

总结：协议不是 HTTP 的、或者量大到 L7 撑不住的，用 L4。

什么场景选七层

场景	为什么选 L7
Web 应用 / API 网关	按 URL、域名、Header 路由到不同后端服务
SSL/TLS 卸载	集中管理证书，后端走明文，降低后端开销
灰度发布 / A-B 测试	按 Cookie / Header 把 5% 流量导到新版本
多租户 SaaS	按 Host 头 tenant-a.example.com 路由到不同集群
精细限流	按 URL 粒度限流：/api/search 限 100 QPS
WAF / 安全防护	检测 SQL 注入、XSS 等应用层攻击
WebSocket 路由	根据路径 /ws/chat vs /ws/notification 分发到不同服务
请求改写	重写 URL、添加/删除 Header、修改响应
Service Mesh	Envoy sidecar 做 L7 流量治理、可观测性

总结：需要”看懂请求内容”才能做决策的，用 L7。

一个典型的选型决策树

你的流量是 HTTP/HTTPS 吗？
├── 是 → 用 L7（Nginx / ALB / Envoy / Traefik）
│      需要扛更大量？ → L4 (LVS/NLB) 放前面
│
└── 否（TCP/UDP 自定义协议）
    ├── 需要按内容路由？ → 可能需要自己写代理，或用支持该协议的 L7
    └── 只需要分发连接？ → 用 L4（LVS / NLB / HAProxy TCP 模式）

常见误区

误区一：Nginx 只能做七层。 不对。Nginx 1.9+ 加入了 stream 模块，可以做 TCP/UDP 四层代理。但它的四层性能比不上 LVS 这种内核级方案。

误区二：四层比七层好，因为性能高。 性能高不等于”好”。如果你需要按 URL 路由、做灰度、卸载 SSL，四层根本做不了这些事。

误区三：用了七层就不需要四层了。 当并发量上去后（比如百万级连接），单台 Nginx 会成为瓶颈。这时候需要 L4 在前面把流量分散到多台 L7 机器上。

误区四：云上直接用 ALB/NLB 就行，不需要了解原理。 云产品确实省事，但出问题时（比如连接数暴涨、长连接不均衡、WebSocket 断连）不懂原理就只能干瞪眼。

总结

	四层	七层
一句话	快递分拣只看地址	快递分拣会拆包检查
性能	极高	较高（但有解析开销）
智能程度	低（只认 IP 端口）	高（读得懂 HTTP 内容）
适用协议	任意 TCP/UDP	HTTP/HTTPS/gRPC/WebSocket
典型产品	LVS、NLB、HAProxy(TCP)	Nginx、ALB、Envoy、Traefik
典型场景	DB 集群、游戏、超高并发入口	Web 应用、API 网关、灰度发布

实际项目中，两者不是二选一，而是组合使用：L4 在前扛量，L7 在后做智能路由。理解了它们各自的能力边界，选型就不会纠结了。