内容摘要：四层服务UDP负载均衡SLB实例这事儿，真不是随便配个监听就完事的。上周刚帮朋友排查了一个线上故障，游戏登录服务用的是UDP 8000端口，SLB后端挂了三台ECS，结果高峰期客户端疯狂报“连接超时”

四层服务UDP负载均衡SLB实例这事儿，层服真不是负载随便配个监听就完事的。上周刚帮朋友排查了一个线上故障，均衡游戏登录服务用的例通是UDP 8000端口，SLB后端挂了三台ECS，层服结果高峰期客户端疯狂报“连接超时”。负载查了半天，均衡问题出在SLB实例的例通会话保持策略上——UDP是无状态的，但游戏登录偏偏需要源IP哈希，层服默认轮询直接把同一用户的负载多个包打到了不同后端，业务层状态没同步，均衡自然就崩了。例通

所以核心观点先撂这儿：UDP的层服SLB，难点不在“转发”，负载而在“如何假装有状态”。均衡TCP有三次握手，SLB能靠连接追踪做会话保持，UDP呢？一个包一个包飞过来，SLB只能靠四元组（源IP、源端口、目的IP、目的端口）硬记。你配了哈希就哈希，配了轮询就轮询，但哈希的键选错了，照样白搭。我见过最蠢的配置，是拿目的端口做哈希——所有流量都打到一个后端，另外两台闲得发慌，这叫负载均衡？这叫单点故障预演。

再说说健康检查。TCP的SLB可以发SYN包探活，UDP呢？你发个空包过去，后端服务理都不理你。阿里云默认的UDP健康检查是发一个字符串，比如“hello”，后端得回“world”才算健康。但这有个坑——很多自研的UDP服务根本不处理这种探测报文，直接丢弃。结果SLB判定后端全挂，流量全丢。我那次排查，最后发现就是后端代码里没写健康检查的响应逻辑，加了个if判断就解决了。

细节上还有个容易忽略的点：MTU和分片。UDP包一旦超过链路MTU，IP层就要分片。SLB转发时如果没配置好，分片包可能走不同路径，后端重组超时，数据直接扔了。TCP有MSS协商，UDP没有，所以你得在SLB层面设置好MTU值，或者干脆让后端服务主动限制包大小。我们当时把游戏客户端的发送缓冲从64KB调到1.5KB，分片问题立刻消失——但这属于业务侧妥协，SLB本身也得支持“不分片标记”才行。

再唠叨一句性能调优。UDP的SLB吞吐量瓶颈经常在CPU中断处理上，尤其当开启了fullnat模式，每个包都要做地址转换，单核处理能力有限。你看监控图，SLB实例的CPU使用率不高，但网卡软中断飙到80%，那就是包量太大，小包居多。解决办法是开RPS（Receive Packet Steering），把中断分散到多核，或者干脆升级到更强的SLB规格。别迷信“四层比七层快”，四层只是少了解析HTTP头，但UDP包处理本身就有代价。

最后说个反直觉的观察：很多人觉得UDP的SLB配好就不用管了，其实恰恰相反。TCP有重传机制，丢了包客户端自己会补，UDP丢了就丢了，所以SLB的丢包率对UDP业务是致命的。你必须在SLB和后端上都开启丢包统计，定期比对。有一次我们发现SLB显示丢包0.1%，但后端收到的包比客户端发的少了3%，查了两小时，结果是后端网卡的rx-checksumming关了，导致UDP校验和错误被内核静默丢弃。这种问题，监控不细到网卡层，永远发现不了。

别指望SLB能替你解决所有UDP的“无状态”痛点，它就是个聪明的管道，但管道两端的服务得自己学会适应。配好哈希键、写好健康检查响应、控制包大小、盯紧丢包率，这四件事做到位，UDP的SLB实例才算是真正“通过”了测试——不是配置通过，是线上流量通过。