山己几

四层与七层负载均衡对比

11 min read

四层与七层负载均衡对比

一句话概括

L4 只管「把包送到谁手上」，L7 还管「包里装的是什么，该送给谁」。

四层负载均衡（L4，传输层）

工作在 OSI 模型的传输层（TCP/UDP），核心特点是不解析应用层协议内容。

工作原理

客户端请求 ─→ L4 负载均衡器 ─→ 按 IP + Port 分发 ─→ Real Server
                        │
                不解析 HTTP 头部/内容
                只做 IP:Port → IP:Port 的映射

决策依据

仅根据以下五元组做决策：

  • 源 IP
  • 源端口
  • 目标 IP
  • 目标端口
  • 协议号（TCP/UDP）

不解包 HTTP 头部、URL、Cookie 等应用层数据。

常见实现

实现说明
IPVS (LVS)Linux 内核内置四层负载均衡，哈希查找 O(1)，详见 IPVS-IP虚拟服务器详解
HAProxy (TCP 模式)HAProxy 可工作在 pure TCP 四层模式
Nginx (Stream 模块)Nginx stream{} 块做四层 TCP/UDP 代理
AWS NLB网络负载均衡器
K8s Service (ClusterIP)kube-proxy IPVS/iptables 模式本质是四层转发

优势与劣势

优势劣势
✅ 性能极高（内核态处理，O(1) 哈希）❌ 无法基于 URL/Header/Cookie 分发
✅ 协议无关（TCP/UDP 都支持）❌ 无法做 SSL 卸载（TLS termination）
✅ 配置简单，延迟极低（μs 级）❌ 无法做内容路由（如 /api→A, /web→B）
✅ 只改 IP:Port，对后端透明❌ 只能做 TCP 端口级健康检查，无法检查 HTTP 状态码

七层负载均衡（L7，应用层）

工作在 OSI 模型的应用层（HTTP/HTTPS/gRPC），核心特点是解析应用层协议内容后再做分发决策。

工作原理

客户端请求 ─→ L7 负载均衡器 ─→ 解析 HTTP 头部/URL/Cookie → 按内容分发 ─→ Real Server
                        │
                看得见 HTTP Method、URL Path、
                Header、Cookie、甚至 Body

决策依据

不仅根据 IP:Port，还会解析：

  • HTTP Method（GET/POST/PUT/DELETE）
  • URL Path（/api/users vs /web/index.html）
  • HTTP Header（Host、User-Agent、Accept 等）
  • Cookie / Session
  • TLS SNI 扩展（HTTPS 场景下根据域名分发）
  • 请求 Body 内容（较少见，如 gRPC 服务方法）

常见实现

实现说明
Nginx (HTTP 模块)最广泛的七层负载均衡，反向代理 + 静态服务，详见 Nginx-location块
HAProxy (HTTP 模式)高可靠七层代理，支持 ACL 规则
AWS ALB应用负载均衡器，支持路径/主机名路由
Envoy云原生七层代理，Istio 数据面，支持 L7 策略丰富
Traefik容器化场景自动发现，K8s Ingress 原生支持

优势与劣势

优势劣势
✅ 内容路由（/api→A, /web→B）❌ 性能低于四层（用户态解析协议，ms 级延迟）
✅ SSL 卸载（TLS termination）❌ 协议相关（无法直接转发 TCP/UDP 流量）
✅ 基于 Cookie 的会话保持（精确到客户端）❌ 配置更复杂
✅ 应用层健康检查（检查 HTTP 200 响应）❌ 可能成为瓶颈（需解包再封包，消耗 CPU）
✅ 数据修改（改写 Header、重写路径）

核心对比总表

对比维度L4 四层L7 七层
OSI 层级传输层（TCP/UDP）应用层（HTTP/HTTPS/gRPC）
决策依据五元组（IP:Port）URL、Header、Cookie、Body
性能⭐⭐⭐⭐⭐ 极高⭐⭐⭐ 中等
延迟极低（μs 级，内核态）较低（ms 级，用户态解包）
SSL 卸载❌ 不支持✅ 支持（TLS termination）
内容路由❌ 不支持✅ 支持（路径/域名/Header 路由）
会话保持基于源 IP（不精确，NAT 穿透失效）✅ 基于 Cookie（精确到客户端）
健康检查TCP 端口探测（能否连上）HTTP 状态码检查（响应是否正确）
协议范围TCP/UDP 全部HTTP/HTTPS/gRPC 等应用层协议
配置复杂度简单较复杂
典型实现IPVS/LVS, Nginx Stream, HAProxy TCP, NLBNginx HTTP, HAProxy HTTP, ALB, Envoy, Traefik
K8s 场景kube-proxy IPVS/iptablesIngress Controller（Nginx/Envoy）

典型场景选型流程

                    ┌─ 纯 TCP/UDP 协议转发（Redis/MySQL/DNS/游戏/视频流）
                    │     → L4（IPVS / Nginx Stream）— 性能优先
                    │
  我的后端服务需要 ──┼─ 简单 HTTP 负载均衡（客户端→后端，一轮转发）
                    │     → L4 就够了（性能最好，无需应用层特性）
                    │
                    ├─ HTTP 内容路由（/api → A 服务, /web → B 服务）
                    │     → L7（Nginx / ALB）
                    │
                    ├─ 需要 SSL 卸载 + HTTP 策略
                    │     → L7（Nginx / HAProxy HTTP / ALB）
                    │
                    └─ 微服务/API Gateway（限流、鉴权、重试、灰度发布）
                          → L7（Envoy / Traefik / Kong）

IPVS 与 Nginx 场景对比（为什么两者并存？）

这是最常见的问题之一：既然 ipvsadm（IPVS）能做负载均衡，为什么还需要 Nginx？ 答案在于两者面向的决策层次不同。

根本区别：能看到什么

IPVS 看到的流量：
┌─────────────────────────────┐
│ TCP: 192.168.1.100:80       │  ← 只能看到「谁 + 哪个端口」
│    ↓                        │
│    转发给 10.0.0.10:80      │     不知道请求的是什么 URL
└─────────────────────────────┘

Nginx 看到的流量：
┌─────────────────────────────┐
│ GET /api/users HTTP/1.1     │  ← 能「读懂」HTTP 协议
│ Host: example.com           │
│ Cookie: session=abc123      │     知道路径、域名、Header
│    ↓                        │
│ 根据 /api/* → 后端 A 服务   │
│ 根据 /web/* → 后端 B 服务   │
└─────────────────────────────┘

场景矩阵

场景IPVS(L4)Nginx(L7)说明
TCP/UDP 纯透传（Redis、MySQL、DNS、游戏）✅ 最佳⚠️ 能但浪费IPVS 零开销转发，Nginx 需 stream 模块折衷
海量连接入口（百万级并发）✅ 内核态 O(1)❌ 用户态瓶颈IPVS DR 模式回包直返客户端
URL 路径路由（/api→A, /web→B）❌ 做不到✅ 核心能力IPVS 看不到 URL
域名路由（多租户按 Host 分发）❌✅基于 Host Header 或 TLS SNI
SSL 卸载❌ DR/TUN 无法解密✅ 挂证书IPVS DR 模式下包原封不动
Cookie 会话保持❌ 仅源 IP 哈希✅ Cookie 插入强制绑定源 IP 哈希在 NAT 穿透时失效
应用层健康检查❌ 仅端口探测✅ HTTP 200/5xx 检测Nginx 能确认服务真正可用
请求头修改/重写路径/CORS❌✅Nginx 可灵活修改请求
限流/WAF/缓存/压缩❌✅七层附加能力
配置变更代价✅ 规则简单，秒级生效⚠️ reload 或热加载IPVS 命令直写内核

一句话选型原则

不需要看 HTTP 内容就用 IPVS（快），需要看 HTTP 内容就用 Nginx（灵活）。

生产中的黄金组合

两者不是替代关系，而是分层配合：

                 ┌──────────────┐
                 │   公网 VIP    │
                 └──────┬───────┘
                        │
                 ┌──────▼───────┐
                 │   IPVS/LVS   │  ← 四层入口：扛百万并发，DR 模式直转
                 │  (内核态)     │     不解析包体，性能无损耗
                 └──────┬───────┘
                        │ DR 模式（只改 MAC）
              ┌─────────┼──────────┐
              │         │          │
         ┌────▼───┐ ┌──▼────┐ ┌──▼────┐
         │ Nginx-1 │ │Nginx-2│ │Nginx-3│  ← 七层集群：做 SSL 卸载、
         │ /api    │ │ /web  │ │/admin │     URL 路由、限流、缓存
         └────┬───┘ └───┬───┘ └───┬───┘
              │         │         │
         ┌────▼───┐ ┌──▼────┐ ┌──▼────┐
         │后端服务A │ │前端服务B│ │管理后台C│
         └────────┘ └───────┘ └───────┘

IPVS 解决「流量怎么到正确的机器」，Nginx 解决「流量到了机器后怎么分给正确的服务」。

类比理解

  • IPVS 像快递分拣中心的传送带 — 只管把包裹送到正确的分拣口
  • Nginx 像分拣口的质检员 — 检查包裹标签、决定放哪个货架、是否需要重新包装

选型原则

能用 L4 就不用 L7，L7 仅在需要应用层决策时引入。

原因很简单：

  • L4 在内核态完成转发（IPVS 哈希 O(1)），开销远小于 L7
  • L7 需要在用户态解包 → 解析协议 → 决策 → 封包转发，每个请求都走一遍

这也是为什么在大型架构中常见 L4 + L7 分层架构：

                  ┌──────────┐
  Internet ───→   │  L4 入口  │  ← IPVS/NLB：高并发流量入口，DDoS 防护
                  │ (IPVS)   │
                  └────┬─────┘
                       │
               ┌───────┼────────┐
               ▼       ▼        ▼
          ┌────────┐ ┌────────┐ ┌────────┐
          │ L7 集群 │ │ L7 集群 │ │ L7 集群 │  ← Nginx/Envoy：精细路由到各微服务
          │ /api   │ │ /web   │ │ /admin │
          └───┬────┘ └───┬────┘ └───┬────┘
              │          │          │
              ▼          ▼          ▼
          后端服务     前端服务    管理后台
  • 前端 L4 做流量入口和高性能转发
  • 后端 L7 做精细路由和应用层策略

相关笔记

Graph View

Backlinks