四层负载均衡处理效率更高，因其工作在传输层，仅基于IP和端口转发，不解析应用层内容，延迟微秒级、CPU占用低；七层需完整解析HTTP等协议，引入毫秒级延迟和更高资源开销。
比较负载均衡协议的处理效率，关键不在“协议本身快不快”，而在于它所处的网络层级（四层 vs 七层）以及对应的数据处理方式。四层协议（如 TCP/UDP）转发更轻量，七层协议（如 HTTP/HTTPS）解析更深但开销更大——这个根本差异决定了性能天花板。
看协议层级：四层比七层天然更快
四层负载均衡工作在传输层，只读取和修改 IP + 端口信息，不拆包、不解析应用内容。数据流经内核或专用转发模块（如 LVS 的 IPVS），几乎不引入额外延迟。实测中，LVS 在万级并发下 CPU 占用常低于 10%。
七层负载均衡（如 Nginx、HAProxy 的 HTTP 模式）必须完整解析 TCP 流，提取请求行、Header、甚至 Body，才能做 URL 路由、Header 改写或安全策略。这个过程涉及用户态与内核态多次拷贝、内存分配和字符串匹配，单请求平均多消耗 0.5–2ms，高并发时容易成为瓶颈。
- 四层典型场景：数据库连接池分发、游戏服务器 TCP 长连接、实时音视频流代理
- 七层典型场景：Web 前端路由、API 网关鉴权、动静分离、A/B 测试分流
比实际指标：吞吐量、延迟、资源占用三者缺一不可
不能只看“QPS 多高”，要结合单位资源下的表现。例如：
- 相同硬件上，LVS（四层）可稳定支撑 50 万并发连接，Nginx（七层）通常在 5–10 万并发时需调优内核参数或启用多进程模型
- 在同等 1KB 小请求压测下，HAProxy 的 P99 延迟比 Nginx 低约 15%，因其事件模型更精简；但 Nginx 对大文件静态响应有零拷贝优化，反而更优
- 内存占用：四层负载均衡器（如 LVS）常驻内存一般
查协议适配：不是所有七层都一样重
HTTP/1.1 和 HTTP/2/3 对负载均衡器压力差异巨大。HTTP/2 多路复用减少了连接数，但头部压缩（HPACK）和流管理逻辑增加了 CPU 开销；HTTP/3 基于 QUIC，要求负载均衡器支持 UDP 处理和加密握手，目前主流开源工具（如 Nginx 1.25+）才初步支持，性能尚未完全释放。
同样，TLS 终止位置直接影响效率：在四层终止 TLS（如使用 TLS Proxy 模式），后端仍走明文，减轻了七层解析负担；若在七层终止并解密再加密（双 TLS），则 CPU 成为明显瓶颈。
- 建议：对外暴露 HTTPS 时，优先在四层 LB 做 TLS 终止（如云厂商 SLB），再以 HTTP 或 HTTP/2 转发给后端七层网关
- 避免在七层 LB 上同时做 TLS 终止 + 复杂 Rewrite + WAF 规则，这类组合极易触发 CPU 饱和
看真实链路：协议效率受上下游协同影响
单独测试 LB 性能意义有限。真正影响终端体验的是整条链路：客户端 → 四层 LB → 七层 LB → 应用服务。比如：
- 若后端服务响应慢（平均 800ms），那么 LB 层 0.2ms 和 2ms 的延迟差对用户几乎不可感知
- 若四层 LB 后直接接高并发 API 服务，却用七层 LB 做简单反向代理，属于过度设计，白白增加跳转和故障点
- 混合部署常见：LVS（四层）作入口，分发到多组 Nginx（七层）集群，每组按业务域做精细化路由，兼顾性能与灵活性
