网络负载均衡（Network Load Balancer，简称 NLB） 是云计算和数据中心架构中专门用于处理极高并发、超低延迟流量转发的关键组件。
简单来说，它的主要任务就是站在一群后端服务器的前面，把成千上万来自客户端的网络请求，均匀、快速地分发给后面的服务器，避免某台服务器被压垮，同时保证系统的高可用。
1. NLB 的核心定位：四层负载均衡
在网络 OSI 七层模型中，NLB 工作在 第 4 层（Transport Layer，传输层），主要处理 TCP、UDP、TLS 协议。
与工作在 第 7 层（Application Layer，应用层） 的应用负载均衡（ALB，如 Nginx、HTTP 转发）不同：
| 特性 | NLB（四层负载均衡） | ALB（七层负载均衡） |
|---|---|---|
| 工作层级 | OSI 第 4 层（IP + Port） | OSI 第 7 层（HTTP / HTTPS / Cookie 等） |
| 数据感知 | 不解析应用层数据，只看源/目的 IP 和端口 | 解析完整 HTTP 报文、URL 路径、Header、Cookie |
| 性能/延迟 | 极高吞吐量，亚毫秒级延迟 | 吞吐量较低，毫秒级延迟（解包/组包有开销） |
| 典型场景 | 游戏服务器、物联网（IoT）、数据库集群、K8s NodePort / Ingress 入口 | Web 网站、微路由分发、API 网关 |
关键区别：NLB 就像快递分拣中心，只看包裹外面的地址（IP 和端口） 就快速甩给下一站，根本不拆开看包裹里面装的是文字、图片还是视频。因此它的处理效率极高。
2. NLB 是怎么工作的？（技术实现原理）
NLB 要实现高性能转发，底层依赖于几种核心技术机制：
① 哈希算法与连接保持（5-Tuple Hashing）
当客户端发起 TCP/UDP 请求时，NLB 会提取数据包的五元组信息：
-
源 IP（Source IP）
-
源端口（Source Port）
-
目的 IP（Destination IP）
-
目的端口（Destination Port）
-
传输层协议（TCP/UDP）
通过对五元组计算 Hash 值，NLB 将请求映射到后端的某台特定的后端服务器（Real Server）。只要这五元组不变，同一个客户端连接的所有后续数据包都会落到同一台后端机器上。
② 转发模式（DNAT 与 Direct Server Return）
在底层数据包转发上，NLB 主要有两种主流模式：
-
DNAT 模式（Destination Network Address Translation）：
-
客户端发送请求到 NLB 的 VIP（Virtual IP）。
-
NLB 将数据包的目的 IP 修改为所选后端服务器的 Real IP，然后转发过去。
-
后端服务器响应时，数据包再原路返回给 NLB，NLB 把源 IP 改回 VIP 再发给客户端。
-
-
DSR 模式（Direct Server Return / 三角传输）：
-
超高性能场景常用。NLB 收到请求后，仅修改数据包的目的 MAC 地址（IP 保持 VIP 不变），直接送给后端服务器。
-
后端服务器配置有 Loopback 虚拟网卡挂载该 VIP，处理完请求后，直接把响应包发送给客户端，不再经过 NLB。
-
优势：出网流量（通常远大于入网流量）不占用 NLB 的带宽瓶颈。
-
③ 健康检查（Health Check）与故障转移
NLB 会定期向后端服务器发送探针：
-
TCP 探针：尝试与后端的指定端口建立 TCP 三次握手。
-
HTTP/UDP 探针：发送简单请求并校验返回状态。
如果某台后端服务器在连续 N 次检查中未响应，NLB 会将其自动标记为 "Unhealthy"（不健康），并将新流量切走；待该节点恢复后，再自动将其拉回集群。
3. 生产环境中的典型架构示例
在现代云原生架构（如 AWS、阿里云或 Kubernetes 环境）中，NLB 通常与 ALB 配合形成双层负载均衡：
Plaintext
[ 互联网客户端 / 移动 App ]
│
▼
┌──────────────────────────┐
│ NLB (网络负载均衡 - L4) │ ──► 负责处理极高并发、提供固定公网静态 IP、防 DDOS 入口
└────────────┬─────────────┘
│ (将 TCP 流量透传)
▼
┌──────────────────────────┐
│ ALB (应用负载均衡 - L7) │ ──► 负责 SSL 证书卸载、基于域名/路径路由 (如 /api, /static)
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ Backend Pods / VMs │ ──► 真正的业务微服务集群
└──────────────────────────┘关键使用场景：
-
静态公网 IP 需求：云厂商的 NLB（如 AWS NLB）通常可以为每个可用区绑定固定的静态 IP（甚至 Elastic IP），非常适合需要域名白名单采纳的企业场景。
-
超大流量 / 突发流量：在双十一抢购、大游戏开服等场景下，NLB 可以直接应对每秒数百万级别的并发连接（CPS），且无需像七层负载均衡那样预热（Pre-warming）。
-
非 HTTP 协议：如 MQTT（物联网）、gRPC（部分场景）、MySQL/Redis 数据库代理、DNS 服务等。