四层负载均衡原理：TCP/UDP协议回顾、工作模式与会话保持
大家好，我是你们的老朋友。今天我们来聊聊四层负载均衡。说实话，这玩意儿是很多高并发系统的基石。我当年刚接触时，觉得不就是转发个包嘛，有啥难的？后来线上出过一次事故，才明白里面的门道有多深。
四层负载均衡，说白了就是在传输层（TCP/UDP）干活。它不关心你的HTTP请求里写了啥，只看IP和端口。嗯，这样效率极高，但也有些限制。我们一点点拆开讲。
TCP/UDP协议回顾
先简单回顾一下。TCP是面向连接的协议，三次握手、四次挥手，大家都很熟。UDP呢，无连接，发就完了，管你收没收到。
为什么负载均衡要区分这俩？因为状态维护不一样。
- TCP：有状态。连接建立后，负载均衡器得记住这个连接属于哪个后端服务器。
- UDP：无状态。每个包都是独立的，负载均衡器只能靠五元组（源IP、源端口、目的IP、目的端口、协议）来哈希。
我记得有一次，一个游戏团队找我排查问题。他们的UDP服务总是丢包，查了半天，发现是负载均衡器把同一个用户的包发到了不同的后端。嗯，这就是没做好会话保持的后果。
核心要点：四层负载均衡不解析应用层数据，所以它无法识别HTTP的Cookie或Session。它只能靠传输层的信息来做决策。
四层负载均衡的工作模式
常见的模式有三种：NAT、DR、TUN。每种都有各自的适用场景。我一个个说。
1. NAT模式（网络地址转换）
这是最基础的模式。负载均衡器作为网关，接收客户端请求，修改目标IP和端口，转发给后端服务器。后端服务器的响应再经过负载均衡器，修改源IP和端口，返回给客户端。
说白了，就是负载均衡器当了个中间人。所有流量都得经过它。
- 优点：配置简单，后端服务器不需要额外配置。
- 缺点：负载均衡器容易成为瓶颈。进出流量都走它，压力很大。
我在项目中遇到过这种情况：早期业务量小，用NAT模式完全没问题。后来流量涨了10倍，负载均衡器的网卡先扛不住了。嗯，这时候就得考虑换模式了。
2. DR模式（直接路由）
DR模式就聪明多了。负载均衡器只处理入站流量，出站流量直接由后端服务器返回给客户端。怎么做到的？
负载均衡器修改数据链路层的MAC地址，把请求转发给后端服务器。后端服务器配置了VIP（虚拟IP）在loopback接口上，收到请求后直接响应。因为响应包的源IP是VIP，客户端认它。
- 优点：性能高，负载均衡器只处理一半流量。
- 缺点：后端服务器需要配置VIP，且必须和负载均衡器在同一个二层网络。
避坑指南：我曾经在DR模式下踩过一个坑。后端服务器的ARP广播把VIP暴露了，导致路由器直接把请求发给了后端，绕过了负载均衡器。解决方案是抑制后端服务器的ARP响应，只让负载均衡器响应VIP的ARP请求。
3. TUN模式（IP隧道）
TUN模式解决了DR模式的网络限制问题。它通过IP隧道，把原始数据包封装在一个新IP包中，发送给后端服务器。后端服务器解封装后处理请求，直接响应客户端。
你想想看，后端服务器可以在不同的网段，甚至不同的机房。这就灵活多了。
- 优点：后端服务器可以跨网段部署，适合异地多活。
- 缺点：需要配置隧道，增加了CPU开销。
我个人习惯在跨机房场景下用TUN模式。比如北京和上海各有一组服务器，用TUN模式做负载均衡，流量调度非常灵活。
三种模式对比
| 特性 | NAT模式 | DR模式 | TUN模式 |
|---|---|---|---|
| 流量路径 | 进出都经过LB | 进经过LB，出直连 | 进经过LB，出直连 |
| 后端配置 | 无特殊要求 | 需配置VIP | 需配置隧道 |
| 网络要求 | 无限制 | 同二层网络 | 跨网段 |
| 性能 | 低（LB瓶颈） | 高 | 中（隧道开销） |
| 典型场景 | 小规模、简单部署 | 高并发、同机房 | 异地多活、跨机房 |
会话保持机制
会话保持，也叫粘性会话。说白了，就是让同一个客户端的请求，始终落到同一台后端服务器上。
为什么需要这个？因为很多应用是有状态的。比如用户登录后，session存在某台服务器上。下次请求跑到另一台服务器，session就丢了。
四层负载均衡的会话保持，常见做法有几种：
1. 源IP哈希
根据客户端的源IP做哈希计算，决定转发到哪台后端。同一个IP永远落到同一台。
- 优点：简单，无额外开销。
- 缺点：如果客户端通过代理访问，所有用户都落到同一台，负载不均。
我记得有个电商客户，用了源IP哈希。结果双十一那天，某个代理IP下的用户特别多，那台服务器直接被打挂了。嗯，这就是没考虑代理场景的后果。
2. Cookie插入（四层也能做？）
等等，四层不是不解析应用层吗？对，但有些负载均衡器可以在TCP层面做手脚。比如在SYN+ACK包中插入一个Cookie，客户端下次请求时会带上这个Cookie，负载均衡器根据Cookie做转发。
不过说实话，这种做法比较tricky，不是所有负载均衡器都支持。
3. 一致性哈希
这是源IP哈希的升级版。当后端服务器增减时，只有少量会话会迁移，不会导致大规模失效。
我个人比较推荐一致性哈希。尤其是在动态扩缩容的场景下，它能最大程度保证会话的稳定性。
注意：会话保持虽然好用，但会降低负载均衡的灵活性。如果某台服务器挂了，它上面的所有会话都会丢失。所以，关键业务还是建议做session共享，比如用Redis集中存储。
知识体系结构图
下面我用一张SVG图，把四层负载均衡的核心逻辑串起来。你一看就明白了。
这张图把整个知识体系串起来了。从客户端到负载均衡器，再到后端服务器，中间穿插了协议选择和会话保持。三种模式的对比也一目了然。
好了，四层负载均衡的原理就讲到这里。记住一句话：选对模式，做好会话保持，你的系统就能扛住高并发。下次我们聊聊七层负载均衡，那又是另一番天地了。
个人建议：如果你刚开始搭建负载均衡，先从NAT模式入手，跑通流程。等业务量上来了，再切换到DR模式。别一上来就搞TUN，那玩意儿配置起来挺折腾的。
想要更多资料，联系可可