L4 vs L7 负载均衡：彻底理解、对比与实战指南

L4 vs L7 负载均衡：彻底理解、对比与实战指南 - 实践

2025-09-26 17:46 tlnshuju 阅读(0) 评论(0) 收藏举报

想知道 L4（传输层） 和 L7（应用层） 负载均衡到底有什么不同？该怎么选？怎么配置？这篇文章会把概念、原理、优缺点、实战配置示例和选型建议都讲清楚，尽可能通俗易懂——读完你能把两者拉出来直接比一比并落地实践。

开场比喻（帮助快速记忆）

把网络请求想象成 邮件投递系统：

L4（传输层）：邮局只看收件人地址（IP + 端口），把邮件交给对应的投递员，不打开信封看内容。速度快但不能按信封内容做精细分流。
L7（应用层）：邮局打开信封，看信里写的是“账单”、“杂志”还是“广告”，再把它们分别交给不同的专门送达小组。能做精细规则，但处理更慢、需要更多资源。

什么是 L4 与 L7（简明定义）

L4（第四层，传输层）负载均衡：基于五元组（源IP、源端口、目标IP、目标端口、协议）或更简单的 IP：端口做流量分发。只看到传输层信息，不解析应用层（比如 HTTP）内容。
L7（第七层，应用层）负载均衡：深入到应用层，可以解析 HTTP/HTTPS 报文（URL、Host、Headers、Cookies、Method、Body 等），根据这些信息做更细粒度路由和策略。

工作流程（简要技术流程）

L4 的工作方式

接受客户端 TCP/UDP 连接或数据包。
按调度算法（轮询、最少连接、基于源IP哈希等）把连接转发给后端某台服务器（可以是 NAT 转发或直接代理）。
不理解 HTTP 路径、Host 等内容。

ASCII 图（简化）：

Client ---> L4 LB ---> Backend A
\-> Backend B

L7 的工作方式

接收并解析应用层（如 HTTP）请求。
根据 URL、Host、Header、Cookie、请求方法等规则决定路由目标。
通常会终止（或代理）应用层连接（即可做 TLS 终止），然后再发起新的请求到后端。

ASCII 图（简化）：

Client ---> L7 LB (inspect Host/URL) ---> API Server
\-> Static Server

能做的事：功能对比（几个核心维度）

维度	L4（传输层）	L7（应用层）
解析粒度	IP + 端口（五元组）	URL、Host、Header、Cookie、Method、Body 等
性能	高吞吐、低延迟	相对更高开销（解析报文、TLS 处理）
路由灵活性	低	高（按路径、域名、用户、Header）
支持协议	TCP/UDP 任意协议	主要面向 HTTP/HTTPS（也有 gRPC/HTTP2 支持）
TLS 处理	多为透传（passthrough）或简单 NAT	常做 TLS 终止 / 解密 / 重加密（re-encrypt）
典型用例	数据库、游戏服务器、视频流、TCP 服务	网站、微服务、API 网关、A/B 测试、WAF
常见实现	LVS、Nginx stream、NLB（云）	Nginx http、HAProxy（http 模式）、Envoy、ALB（云）

常见误区澄清

“L7 一定比 L4 慢”：通常 L7 有更多处理（解析、TLS、路由决策），但现代实现（高性能 Nginx/Envoy/HAProxy）优化很好。是否“慢”取决于请求类型、并发量与硬件资源。
“L4 就不能做健康检查”：不对。L4 可以做 TCP 端口级的健康检查（能否 connect），只是无法做 HTTP 200/403 等应用层判断。
“所有 HTTP 都必须用 L7”：也不一定。若你只关心连接分发、不需要按 URL 区分或终止 TLS（例如需要完整透传），L4 依然合适。

关键话题拆解（实务关注点）

1) 会话保持（Sticky Session）

L4 常用：基于源 IP 哈希（ip_hash）、五元组哈希或持久连接保持。优点简单，缺点：NAT 后的源IP一致性问题、客户端可能共享公网IP（NAT）导致不均衡。
L7 常用：基于 Cookie（后端或 LB 插入），也可以用 URL 参数或 Authorization token。更可靠且可控。

示例（Nginx upstream ip_hash）

upstream app_backend {
ip_hash;
server 10.0.0.11:80;
server 10.0.0.12:80;
}

示例（HAProxy cookie sticky）

backend web-back
cookie SERVERID insert
server s1 10.0.0.11:80 cookie s1
server s2 10.0.0.12:80 cookie s2

2) 健康检查

L4：常做 TCP 三次握手是否成功（端口可达）。
L7：可以做 HTTP(s) 路径检查（期望 200）、响应体或 JSON 字段校验，更精细。

3) TLS（HTTPS）处理策略

TLS 终止（L7）：LB 解密后对后端发明文或重新加密；优点：可以做内容路由、WAF、压缩、缓存；缺点：LB 需要证书和计算资源。
TLS 透传（L4）：LB 不解密，直接把 TLS 数据传到后端。优点：安全（后端掌握密钥），适合内网或合规场景；缺点：无法做基于 URL 的路由或 WAF。
TLS 旁路/双向（re-encrypt）：LB 解密做检查后与后端建立新的 TLS 连接，取中间方案的优点（但更复杂）。

4) WebSocket / HTTP2 / gRPC 支持

WebSocket：既可由 L7（HTTP 升级）代理，也可以 L4 透传；如果需要基于路径路由，必须用 L7。
gRPC（HTTP/2）：L7 能识别 HTTP/2 的 Host 路由并做细粒度控制；L4 只能按 IP/端口分发。

实战配置示例（常见代理/负载均衡器）

Nginx（L7 HTTP 反向代理）

http {
upstream api_backend {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
}
server {
listen 80;
server_name example.com;
location /api/ {
proxy_pass http://api_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /static/ {
proxy_pass http://10.0.0.20:80;
}
}
}

Nginx stream（L4 TCP 负载均衡）

stream {
upstream mysql_back {
server 10.0.0.11:3306;
server 10.0.0.12:3306;
}
server {
listen 3306;
proxy_pass mysql_back;
}
}

HAProxy（L4 与 L7 示例）

L4（TCP 模式）

defaults
mode tcp
timeout client  50s
timeout server  50s
frontend mysql_front
bind *:3306
default_backend mysql_back
backend mysql_back
balance roundrobin
server db1 10.0.0.11:3306 check
server db2 10.0.0.12:3306 check

L7（HTTP 模式，按路径路由）

defaults
mode http
timeout connect 5s
timeout client  50s
timeout server  50s
frontend http_front
bind *:80
acl is_api path_beg /api
use_backend api_back if is_api
default_backend web_back
backend api_back
server api1 10.0.0.11:8080 check
backend web_back
server web1 10.0.0.20:80 check

性能考量（在选型时必须考虑）

每秒连接数 vs 并发请求数：L4 处理开销小，能支撑更高并发；L7 在解析、TLS 终止时会增加 CPU/内存负担。
TLS 带来的成本：若 LB 做 TLS 终止，CPU 与证书管理是额外工作；可借助硬件加速或专用 TLS 组件。
短连接 vs 长连接：长连接（WebSocket、gRPC）会占用更多连接表资源，L4 更擅长低延迟的网络转发，L7 需要更谨慎地配置超时与连接复用（keepalive）。
缓存：L7 可以做 HTTP 缓存（静态资源缓存），显著降低后端压力。

常见部署架构（现实中的组合模式）

纯 L4：高性能 TCP 服务（数据库代理、游戏服务器）。
纯 L7：网站、API、WAF、灰度发布、A/B 测试。
混合（常见）：外层使用 L4（NLB / LVS）做初步分发，再把流量发给 L7 级的代理群（Nginx/Envoy）做应用层路由和策略（兼顾性能与灵活性）。
CDN + L7：静态资源由 CDN 提供，动态请求到 L7 LB；可减少 L7 负载。

云服务便于理解的映射（常见做法，供参考）：

AWS NLB（Network Load Balancer） ≈ L4，ALB（Application Load Balancer） ≈ L7。
（不同云有不同命名，但概念一致：NLB/LB：传输层分发；ALB/HTTP LB：应用层智能路由）

监控与可观测性（必做）

监控哪些指标？建议最小集合：

请求吞吐（RPS/Requests）
平均/分位延迟（p50/p95/p99）
连接数（active connections）与新建连接率
后端错误率（5xx/4xx）
后端健康状态与响应时间
TLS 握手失败率（如果做 TLS）

工具：Prometheus + Grafana、ELK/EFK、Datadog 等（根据你们已有栈选择）。

安全考虑

L7：能部署 WAF（阻止 SQLi、XSS、恶意 UA 等），做细粒度速率限制（per IP、per API Key）。
L4：更多用于 DDoS 撤退（通过速率限制在更低层拦截），但无法识别应用层攻击。
X-Forwarded-For 与真实客户端 IP**：若 LB 做代理（即终止连接后发起新连接），务必正确设置并信任代理链中的 X-Forwarded-For，并在后端做来源校验。

选型指南（决策清单）

在做选择前，回答下面的问题（快速 checklist）：

你的流量类型是什么？（HTTP/HTTPS / TCP / UDP / WebSocket / gRPC）
需要按 URL/Host/Headers 做路由吗？（需要 -> L7）
是否必须透传 TLS？（需要 -> L4 或 TLS passthrough）
是否对延迟或极高并发敏感？（高敏感 -> 倾向 L4）
是否需要 WAF、缓存或应用层限流？（需要 -> L7）
预算/运维能力如何？（L7 复杂度更高）

常见快速决策：

纯数据库/游戏/视频流（高并发、低延迟） → L4
网站、API、需要 A/B/灰度、WAF、缓存 → L7
又想兼顾性能与灵活性 → L4 前端 + L7 后端 的混合架构

实操小贴士（避免踩坑）

若使用 L4 做 TCP 转发但后端需要知道真实客户端 IP，确保使用 proxy protocol 或在网络边界用 X-Forwarded-For（需要代理支持）。
使用 Cookie 粘滞会阻碍后端扩容/下线，推荐配合 session store（Redis）或无状态设计（token）替代粘滞。
健康检查一定要设置，不同后端应设定合理的阈值与重试策略，避免“假死”后端被流量继续打满。
性能测试要基于真实负载（使用 wrk/ab/k6 等），对比 L4/L7 在你场景下的真实延迟与 QPS。
TLS 密钥管理：若 LB 负责 TLS 终止，证书轮换策略要提前规划（自动化：ACME/Let's Encrypt 或使用云证书管理）。