四层与七层的本质区别
四层负载均衡只看 IP 与端口，按连接转发，不解析应用层内容，因此兼容任意 TCP/UDP 协议且开销低；七层负载均衡会解析 HTTP 请求，能按域名、路径、Header 决定转发目标，还承担 HTTPS 卸载、重定向与灰度能力。选型的第一判断是：是否需要根据请求内容做路由，需要就选七层。
基本信息
| 四层协议 | TCP / UDP，任意基于二者之上的协议 |
|---|---|
| 七层协议 | HTTP / HTTPS（部分产品支持 QUIC） |
| 四层转发依据 | 源 IP、目的 IP、端口、协议号 |
| 七层转发依据 | 域名、路径、请求头、Cookie 等请求内容 |
| 证书处理 | 四层不做证书卸载，七层可在入口完成 HTTPS 卸载 |
| 客户端源 IP | 七层通过 X-Forwarded-For 传递，四层通常需额外模块或代理协议支持 |
典型使用场景
- 四层：数据库代理、消息队列、MQTT、游戏长连接等非 HTTP 服务
- 四层：要求极低转发开销、超大连接数的场景
- 七层：多域名共用一个入口，按域名分发给不同后端
- 七层：按路径把 /api 与 /static 分到不同服务，或做 API 版本灰度
- 七层：在入口统一卸载 HTTPS 并强制跳转，简化后端证书部署
按协议快速判断
按协议快速判断
MySQL / Redis / MQ → 四层监听
HTTP API 需按域名路径分发 → 七层监听
非 HTTP 且要 TLS 卸载 → 四层（或评估支持 TLS 的产品）
同一后端同时挂四层与七层 → 按流量类型分别接入，互不影响能力对照
| 能力 | 四层 | 七层 |
|---|---|---|
| 按域名/路径分发 | 不支持 | 支持，可配默认兜底组 |
| HTTPS 卸载与证书管理 | 不承担 | 入口统一处理 |
| 强制跳转 HTTPS | 不承担 | 支持 301/302 重定向 |
| 空闲超时控制 | 需按长连接业务调大 | 可按请求特征配置 |
| 获取真实客户端 IP | 需额外模块支持 | 通过 X-Forwarded-For 传递 |
| 长连接开销 | 低 | 有协议解析开销 |
同一批后端可以同时挂四层与七层监听：HTTP 流量走七层入口做规则分发，内网 TCP 调用走四层入口，两边配置互不影响，扩缩容时只需维护一份后端成员。
HTTP 业务如果只配四层监听，后续想做按路径灰度、Header 改写或统一跳转 HTTPS 时只能改建监听，前期选型时值得多花十分钟确认。
混合场景的常见做法
- 同一后端组同时挂 HTTP 与 TCP 监听，按客户端类型分流
- 七层入口负责 HTTPS 卸载与规则分发，后端之间仍用四层内网调用
- 推送、订阅等长连接服务走四层，避免七层空闲超时干扰业务
- 内部微服务调用用四层内网监听，减少协议解析开销
- 对外 HTTP 接口用七层，便于后续做灰度、限流与重定向
判断流量走的是哪一层
判断流量走的是哪一层
curl -sv -H 'Host: api.example.com' http://<入口地址>/health
# 七层：Host 头参与规则匹配；返回默认组内容说明未命中域名规则
openssl s_client -connect <入口>:443 </dev/null 2>/dev/null | head -3
# 四层：TLS 由后端直接应答，入口不参与证书处理四层监听看不到 HTTP 内容，因此无法在入口做路径级限流或 Header 改写；这类需求必须在七层或应用侧实现，选型时先把需求列全。
选型判断清单
| 判断问题 | 答「是」则选 |
|---|---|
| 需要按域名或路径分发请求吗 | 七层 |
| 需要在入口卸载 HTTPS 与强制跳转吗 | 七层 |
| 承载的是非 HTTP 协议吗 | 四层 |
| 对转发开销与连接数规模极其敏感吗 | 四层 |