四层负载均衡分析：Cloudflare Unimog
内容提要
该文章介绍了Cloudflare的四层负载均衡方案Unimog，它是一种基于自定义硬件服务器的负载均衡器，采用了类似于Google的Maglev的技术选型。Unimog具有动态负载均衡的特性，可以根据机器负载自动调整连接数量。文章还介绍了Unimog的转发链路、连接保持技术和基于XDP的软件实现。控制面使用Conductor来生成转发表、进行健康检查和负载均衡。此外，文章还讨论了UDP的支持和特殊情况下的处理。
延伸解读
动态负载均衡如何解决新旧硬件混布难题
Cloudflare 机房内服务器型号新旧混杂，若按静态权重均分流量，旧机器易因性能不足导致延迟升高，新机器则利用率不足。Unimog 的动态负载均衡根据 RS 实时负载自动调整连接数，负载低时多承接，负载高时少承接，使不同型号服务器的利用率趋于一致。这种机制还能应对连接成本不均或机器上运行其他程序带来的额外负载，是静态权重调整难以实现的。
全员负载均衡的架构取舍与收益
Cloudflare 将四层负载均衡部署到机房内所有机器，而非单独划分专用集群。这样做的好处包括：无需为负载均衡做容量规划，所有可用机器都参与流量处理；最大化 DDoS 防护能力，因为每台机器都能运行 L4Drop 丢弃攻击包；运维架构统一，所有 Edge Server 运行相同软件栈。代价是单机无需追求极致吞吐优化，但整体资源利用率和防护规模得到提升。
连接保持与转发表变更的巧妙处理
Unimog 通过全局一致的 forwarding table 确保相同 TCP 四元组总是映射到相同 RS。当 RS 下线或调整流量比例时，只需修改 bucket 对应的 RS，无需重算整个表。为保持已有连接，每个 bucket 维护主备两跳：主表指向新 RS，备表指向旧 RS。RS 收到包若本地无对应 socket，则按备表转发。这种机制仅影响约 1% 的长连接，且备表状态只维持几分钟，平衡了连接保持与运维效率。
UDP 流量处理的特殊逻辑与局限
UDP 无连接，Unimog 区分两类场景：ping-pong 型（如 DNS）可跳过两跳表，单跳必中；流式响应型则需维护两跳表。由于 UDP 没有 SYN 包，新连接几乎都先转发到第二跳，与 TCP 相反。Conductor 添加 RS 时，若希望其接收 UDP 流量，需将其放在第二跳。此外，Unimog 能识别 QUIC 等流量的 flow id，基于 flow id 而非四元组做哈希，即使客户端 IP 变化也能保持同一流。但若使用 unconnected socket，则无法处理。
Q&A
Cloudflare的Unimog负载均衡方案有什么特点？
Unimog具有动态负载均衡特性，能够根据机器负载自动调整连接数量，并且所有机器都作为负载均衡器，简化运维架构。
Unimog如何处理UDP流量？
Unimog通过维护2 hop表来处理UDP流量，确保相同的UDP流量能够到达同一台RS，并且能够识别UDP流量中的flow id以保持连接稳定。
Unimog的控制面是如何工作的？
控制面Conductor负责生成转发表、进行健康检查和负载均衡，基于Consul实现，能够动态调整RS的负载。
Unimog如何解决新旧服务器性能差异的问题？
Unimog通过动态负载均衡，根据每台服务器的负载自动调整连接数量，从而有效解决新旧服务器性能差异的问题。
Unimog使用了什么技术来提升性能？
Unimog选择了XDP进行包转发，这种选择允许软件兼容多种硬件，提升了整体性能。
Unimog的转发链路是如何设计的？
Unimog使用GUE封装转发链路，解决MTU超过1500 bytes的问题，并通过Jumbo Frame提高转发效率。
