ELB深度解析：四层vs七层转发原理与性能对比

大家好，我是知秋一叶！做云原生的同学，几乎每天都在跟负载均衡打交道，但很多人对”四层”和”七层”的理解还停留在”一个快一个慢”的层面：

同样是负载均衡，为什么有的叫L4有的叫L7？
四层只看IP端口，七层能看URL，底层到底差在哪？
生产环境到底选四层还是七层？还是组合用？
阿里云SLB、腾讯云CLB、天翼云ELB，底层实现有啥不一样？

很多人配置了一堆监听器，却搞不清DNAT和反向代理的本质区别，排障的时候抓瞎。今天我们就从底层原理到云厂商实现，把四层和七层负载均衡这件事讲透，帮你建立清晰的认知框架。

一、为什么需要ELB#

在单台服务器扛不住的时候，最直觉的方案就是加机器。但加完机器后，谁来决定每个请求去哪台？这就是负载均衡要解决的问题。

ELB（Elastic Load Balancing，弹性负载均衡）的核心职责：将入站流量按照策略分发到多台后端服务器，实现水平扩展与高可用。

一旦后端某台服务器挂了，ELB通过健康检查自动剔除，流量无感切换——这就是”弹性”的含义。

二、从OSI模型理解”四层”和”七层”#

“四层”和”七层”不是玄学，它的依据是OSI七层网络模型。理解了层级，就理解了它们的能力边界。

四层负载均衡（L4） ：工作在传输层，只能看到 IP + 端口，不关心应用层内容
七层负载均衡（L7） ：工作在应用层，能解析 HTTP 报文，基于域名、URL、Header、Cookie 等做调度

一句话概括区别：四层看”门牌号”，七层看”信封内容” 。

三、四层转发原理深度剖析#

3.1 核心机制：DNAT#

四层负载均衡的核心是 DNAT（Destination Network Address Translation，目标地址转换） 。它只改写报文头部的IP和端口，不碰数据内容。

转发流程：

客户端连接 ELB 的 VIP:Port
ELB 查看报文的目标 IP + 端口，根据调度算法选一台后端服务器（Real Server）
ELB 将报文目标地址从 VIP 改为 RS_IP，转发给后端
后端处理后，响应报文经 ELB 将源地址改回 VIP，返回客户端

整个过程 不解析应用层内容，只改写网络层/传输层头部，所以处理速度极快。

3.2 四层的两种转发模式#

NAT 模式（Full NAT）#

最常见的方式。ELB 同时修改源 IP 和目标 IP：

请求方向：客户端IP → ELB IP → 后端RS_IP
响应方向：RS_IP → ELB IP → 客户端IP

特点：所有流量都经过 ELB，ELB 可能成为瓶颈；后端 RS 不需要配置 VIP。

DR 模式（Direct Routing）#

ELB 只修改目标 MAC 地址，不修改 IP：

请求方向：客户端 → ELB（改MAC）→ 后端RS（IP仍然是VIP）
响应方向：RS → 直接返回客户端（绕过ELB）

特点：响应流量不经过 ELB，性能极高；但要求 RS 和 ELB 在同一二层网络，且 RS 需要配置 VIP。

3.3 四层连接模型#

四层负载均衡建立的是一个端到端的连接映射：

在 NAT 模式下，ELB 维护一张连接表（五元组：源IP、源端口、目标IP、目标端口、协议），将客户端连接映射到后端连接。同一条流的报文始终转发到同一台 RS。

3.4 TCP SSL 卸载#

部分四层负载均衡支持 TCP SSL 卸载：在传输层就完成 SSL/TLS 的加解密，后端 RS 无需处理加密逻辑。这不同于七层的 HTTPS 卸载——四层只做传输层加解密，仍不解析应用层内容。

3.5 四层健康检查#

检查方式	原理
TCP 连接检查	尝试建立 TCP 三次握手，成功即健康
UDP 检查	发送 UDP 探测报文，收到响应即健康

四层健康检查只关注网络是否可达，不关心应用逻辑是否正常。

四、七层转发原理深度剖析#

4.1 核心机制：反向代理#

七层负载均衡本质是一个 反向代理（Reverse Proxy） ，它终止客户端连接，解析应用层协议，再以自己的身份向后端发起新连接。

七层 ELB 是真正的”中间人”：客户端认为自己与后端 RS 通信，实际是和 ELB 通信；RS 也认为自己与 ELB 通信。

4.2 七层转发完整流程#

以 HTTPS 请求为例：

客户端发起 TLS 握手 → ELB（VIP:443）
ELB 出示证书，完成 TLS 握手，建立加密通道
ELB 解密 HTTP 请求，读取：
- Host 头（域名）
- URL 路径
- Cookie
- 自定义 Header
- Query String
匹配转发规则，选择目标后端服务器组
ELB 以 HTTP（内网通常不再加密）向后端 RS 发送请求
RS 返回响应 → ELB → 加密 → 返回客户端

关键环节：ELB 完成了 TLS 终止（SSL Offloading） ，后端 RS 只需处理 HTTP，大幅降低加解密负担。

4.3 七层路由规则详解#

七层的核心价值是 基于内容的路由：

路由维度	示例	场景
域名	`api.example.com` → RS组A, `web.example.com` → RS组B	同一IP多域名
URL路径	`/api/` → 后端服务, `/static/` → CDN/对象存储	前后端分离
HTTP Header	`X-Canary: true` → 灰度 RS	金丝雀发布
Cookie	`sessionid=abc` → RS-1	会话保持
Query String	`?version=v2` → 新版本RS	A/B测试
HTTP方法	`GET` → 读服务, `POST` → 写服务	读写分离

4.4 七层连接模型#

七层是 两个独立的 TCP 连接：

两个连接完全独立：

客户端连接数 ≠ 后端连接数
可以对后端使用连接池/长连接复用
ELB 可以对请求做缓冲、限速、重试

4.5 HTTPS 卸载 vs 透传#

模式	TLS终止位置	后端收到	安全性	后端负担
卸载（Offload）	ELB	明文 HTTP	内网足够安全	低
透传（Pass-through）	后端RS	加密 HTTPS	端到端加密	高
端到端加密	ELB解密再加密→后端	HTTPS（二次加密）	最高	中

生产环境最常见的是 卸载模式：ELB 终止 TLS，内网用 HTTP 通信，兼顾安全与性能。

4.6 七层健康检查#

七层不仅能检查网络可达性，还能检查 应用层是否正常：

检查方式	原理	示例
HTTP 状态码	发起 HTTP 请求，检查响应码	200 为健康，502 为异常
HTTP 响应体	检查返回内容是否包含指定字符串	包含 “OK” 为健康
指定检查路径	专门用于健康检查的轻量接口	`GET /health`

这比四层的 TCP 连接检查精确得多——服务进程还在，但业务逻辑已经挂了，四层查不出来，七层能查出来。

五、四层与七层协同架构#

在真实的生产环境中，四层和七层不是二选一，而是协同工作：

为什么不全用七层？

性能：四层只改 IP/Port，吞吐量远高于七层（解析 HTTP 开销大）
协议覆盖：非 HTTP 协议（MQTT、自定义 TCP）只能走四层
连接规模：IoT 场景百万级设备并发，四层是唯一选择

为什么不全用四层？

精细调度：无法基于域名/URL/Header 做路由
安全：无法做 SSL 卸载、WAF 防护
云原生：Ingress 网关、灰度发布需要七层能力

六、核心对比#

6.1 原理对比#

维度	四层（L4）	七层（L7）
工作层级	传输层	应用层
转发依据	IP + 端口	域名/URL/Header/Cookie
连接模型	一个连接映射	两个独立连接
协议解析	无	解析HTTP等应用层协议
典型实现	LVS、DPDK、TGW	Nginx、HAProxy、Envoy、Tengine
数据面改动	仅改IP/Port头部	可增删改HTTP报文

6.2 性能对比#

指标	四层	七层
转发延迟	微秒级	毫秒级
吞吐量	极高	较高
并发连接	亿级	百万QPS级
CPU开销	低	高（需解析+加解密）
内存开销	低（仅连接表）	高（HTTP报文缓冲）

6.3 功能对比#

能力	四层	七层
域名/URL路由	❌ 不支持	✅ 支持
Header/Cookie路由	❌ 不支持	✅ 支持
请求重定向/重写	❌ 不支持	✅ 支持
SSL卸载	仅TCP SSL	HTTPS卸载
WAF安全防护	❌ 不支持	✅ 支持
流量镜像/灰度发布	❌ 不支持	✅ 支持
限速	连接级限速	请求级限速
WebSocket	❌ 不支持	✅ 支持
gRPC/QUIC	❌ 不支持	✅ 支持
健康检查精度	TCP端口级	HTTP应用级

七、获取客户端真实IP#

7.1 四层场景#

四层在 NAT 模式下，后端 RS 看到的源 IP 是 ELB 的内网 IP，不是客户端真实 IP。

解决方案：

转发层透传：部分 ELB 支持在四层直接透传客户端 IP（如 TOA / Proxy Protocol）
TOA（TCP Option Address） ：在 TCP SYN 报文的 Option 字段中携带客户端真实 IP，后端内核模块解析获取
Proxy Protocol：在 TCP 连接建立后，ELB 先发送一行文本 PROXY TCP4 客户端IP ELB_IP 端口端口\r\n，后端需开启 Proxy Protocol 支持

7.2 七层场景#

七层 ELB 是反向代理，后端 RS 看到的源 IP 一定是 ELB IP。标准方案通过 HTTP 头部传递：

1
X-Forwarded-For: 客户端IP, 代理1_IP, 代理2_IP

取第一个地址即为客户端真实 IP
多级代理时，前面追加，越靠左越接近客户端
部分ELB还支持 X-Real-IP 头部

注意：X-Forwarded-For 可以被客户端伪造。如果需要可信的客户端 IP，应信任 ELB 追加的最后一个 X-Forwarded-For 值，或使用 ELB 提供的 Remote Address 字段。

八、三大云厂商 ELB 实现对比#

了解了原理，我们再看看国内三大云厂商的具体实现，每家都有自己的技术栈和产品矩阵。

8.1 阿里云 SLB 家族#

阿里云负载均衡不是单一产品，而是一个完整家族：

产品	定位	层级	底层实现
NLB 网络型负载均衡	高性能四层入口	四层为主	基于洛神云网络平台，DPDK加速
ALB 应用型负载均衡	云原生七层网关	七层	基于Tengine增强
CLB 传统型负载均衡	经典款，四七层混合	混合	四层LVS+Keepalived，七层Tengine

技术特点：

四层：LVS（Linux Virtual Server）+ Keepalived 定制化实现
七层：Tengine（淘宝开源的Nginx增强版）
NLB 最大支持 1亿并发连接，面向海量连接场景
ALB 支持 HTTP/HTTPS/gRPC/QUIC，面向云原生和微服务

8.2 腾讯云 CLB#

腾讯云走的是自研路线，底层基于统一接入网关：

层级	底层实现	特点
四层	TGW（Tencent Gateway）自研 + DPDK	单集群亿级并发、千万级PPS
七层	STGW（安全Tencent网关）	集成WAF、HTTPS加速