🔀 四层 vs 七层负载均衡

深入理解 OSI 模型与网络转发原理

🌐 OSI 七层网络模型

理解四层/七层负载均衡，先理解 OSI 模型。点击任意层查看详情。

7
应用层 (Application)
HTTP、HTTPS、DNS、FTP、SMTP
浏览器、Web 服务、API
6
表示层 (Presentation)
数据格式转换、加密解密、压缩
SSL/TLS、JPEG、ASCII、Base64
5
会话层 (Session)
会话管理、连接建立/维护/终止
RPC、SQL 会话、NetBIOS
4
传输层 (Transport)
TCP、UDP、端口号、端到端连接
端口 80/443/3306、滑动窗口
3
网络层 (Network)
IP 地址、路由选择、数据包转发
IP、ICMP、路由器
2
数据链路层 (Data Link)
MAC 地址、帧传输、错误检测
以太网、交换机、网卡
1
物理层 (Physical)
比特流传输、电气信号、物理介质
网线、光纤、集线器

🎯 负载均衡在 OSI 模型中的位置

客户端 浏览器/App 四层负载均衡 L4 Load Balancer 只看 IP + Port 七层负载均衡 L7 Load Balancer 解析 URL/Header 后端 1 10.0.0.1:8080 后端 2 10.0.0.2:8080 后端 3 /api/users ⚡ 核心区别 四层 (L4) - 传输层: • 基于 IP + Port • 不解析内容 • 性能极高 七层 (L7) - 应用层: • 基于 HTTP 内容 • 解析 URL/Header

🟢 为什么叫"四层"负载均衡？

因为它工作在 OSI 模型的第 4 层（传输层），基于 IP 地址 + 端口号 进行转发决策。它只关心"数据包要发到哪个 IP:Port"，不解析数据包的具体内容。就像快递员只根据收件地址（IP:Port）送货，不关心包裹里是什么。

🟠 为什么叫"七层"负载均衡？

因为它工作在 OSI 模型的第 7 层（应用层），需要解析 HTTP/HTTPS 等应用层协议。它可以读取 URL 路径、请求头、Cookie 等信息，就像快递员不仅看地址，还会拆开包裹看看里面的物品清单（URL），然后决定送到哪个部门（后端服务）。

⚖️ 四层 vs 七层负载均衡深度对比

🟢 四层负载均衡 (L4)

传输层 · 基于连接

基于 TCP/UDP 协议的 IP 地址和端口号进行流量分发。不解析应用层数据，只负责建立连接并转发。

  • ⚡ 性能极高 - 转发速度快，延迟低
  • 🔒 透明转发 - 不修改数据包内容
  • 🌐 协议无关 - 支持任意 TCP/UDP
  • 💾 资源占用低 - 只维护连接状态

🟠 七层负载均衡 (L7)

应用层 · 基于内容

解析 HTTP/HTTPS 等应用层协议，基于 URL、Header、Cookie 等信息进行智能路由。

  • 🎯 智能路由 - 基于 URL/Header 路由
  • 🛡️ 安全防护 - 拦截恶意请求
  • 📊 内容优化 - 压缩、缓存、SSL
  • 🔧 灵活控制 - 重写 URL、Header
对比维度 🟢 四层 (L4) 🟠 七层 (L7)
OSI 层级第 4 层 - 传输层第 7 层 - 应用层
转发依据IP 地址 + 端口号URL、Header、Cookie
数据解析不解析应用层数据解析 HTTP/HTTPS
性能极高（百万级 QPS）较高（数万级 QPS）
延迟极低（微秒级）较低（毫秒级）
资源消耗低较高
路由能力简单（端口区分服务）灵活（按路径/Header）
SSL 终结不支持（透传）支持（可解密 HTTPS）
缓存能力无可缓存静态资源
会话保持IP HashCookie、Session
典型场景数据库、游戏、IoTWeb 应用、API 服务
代表产品LVS、AWS NLBNGINX、Kong、AWS ALB

🔍 实际数据包对比

四层数据包 Layer 4 只看到这些： Src IP | Dst IP Src Port | Dst Port 应用数据 (不解析) 七层数据包 L7 可以解析全部： IP 头 TCP 头 (Port) GET /api/users HTTP/1.1 Host: api.example.com Authorization: Bearer xxx

🛠️ 常见产品选型

🔄

NGINX

高性能反向代理服务器，支持四层/七层负载均衡

L4L7
⚡

LVS (Linux Virtual Server)

Linux 内核级负载均衡，性能极高

L4
☁️

AWS NLB

AWS 网络负载均衡器

L4
🌐

AWS ALB

AWS 应用负载均衡器

L7
🐵

Kong / APISIX

API 网关，支持四层/七层

L4L7
🔷

云产品 SLB

阿里云/腾讯云四层负载均衡

L4

🎯 产品能力对照表

产品四层转发七层转发SSL 终结健康检查性能
NGINX✓✓✓✓极高
LVS✓✗✗✓极高
AWS NLB✓✗✗✓极高
AWS ALB✗✓✓✓高
Kong✓✓✓✓中高

🎮 交互式流程演示

客户端 Browser 负载均衡器 L4 / L7 选择后端 后端服务 待命中 REQ RES 📋 处理日志 点击按钮开始演示...
[--:--:--] 点击上方按钮开始演示

💡 演示要点

四层：客户端 → LB(只看IP:Port) → 后端 | 速度快，不关心内容
七层：客户端 → LB(解析HTTP) → 根据URL路由到不同后端 | 功能丰富

❓ 为什么总是强调四层/七层？

📌 核心原因：选择不同的层，决定了你能做什么

SLB 和 NGINX 在宣传时强调"四层/七层"，是因为这决定了产品的能力边界和适用场景。选错层级，可能导致性能浪费或功能缺失。

🟢 选四层的场景

  • 🎮 游戏服务器（长连接、低延迟）
  • 🗄️ 数据库代理（MySQL、Redis）
  • 📱 物联网 MQTT 协议
  • 🔊 视频流媒体（RTMP、HLS）
  • 🔒 需要超高并发（百万级）
  • ⚡ 对延迟极度敏感

🟠 选七层的场景

  • 🌐 Web 应用/API 服务
  • 🔐 需要 HTTPS 终结
  • 🔀 按 URL 路径路由到不同服务
  • 🍪 基于 Cookie/Session 的会话保持
  • 🛡️ 需要 WAF 防护
  • 📊 API 限流、认证授权

🏆 最佳实践：组合使用

客户端 Browser 四层 SLB 高性能入口 SSL 终结 七层网关 智能路由 认证/限流 后端微服务集群 用户 订单 支付 ⚡ 追求极致性能 🛡️ 业务安全控制 🎯 业务逻辑处理

💎 四层 + 七层组合是最佳实践

四层 SLB（入口）：处理海量连接，SSL 终结，基础负载均衡
七层网关（内部）：URL 路由、认证授权、限流熔断、API 管理

这样既能保证高性能，又能实现精细化的业务控制。