四层负载均衡分析：GitHub GLB
内容提要
GitHub的四层负载均衡（LB）设计被称为GLB，与Cloudflare Unimog类似。GLB的连接保持技术创新性强，不需要同步信息。GLB根据TCP连接五元组hash进行转发决策，不保存状态。GLB的转发表生成满足多个条件，使用Rendezvous hashing实现。GLB使用DSR转发架构，封装使用GUE。GLB基于DPDK实现，支持TCP和ICMP，不支持UDP。非数据面流量可通过Flow Bifurcation分流。GLB运行健康检查程序，失败时交换主备RS。RS上的二次转发使用Netfilter和IPtables实现。
延伸解读
无状态连接保持的优势
GLB 的连接保持设计无需在实例间同步状态，每个包独立根据五元组哈希选择主备 RS，并通过二次转发提供容错。与 Maglev 相比，GLB 不保存连接表，避免了 SYN DDoS 导致的内存问题，且当 LB 或 RS 数量变化时，现有连接不会中断，因为转发决策仅依赖哈希和转发表，无需状态迁移。
转发表生成与运维约束
转发表使用 Rendezvous hashing 生成，满足最小变更、无外部依赖、主备不同和负载均衡四个条件。运维时需注意：删除 RS 应先交换主备位置，待旧连接自然结束再下线；添加 RS 每次只能加一个，否则可能因两个新 RS 同时出现在同一行的前两名，导致旧 RS 未 drain 就失去流量，造成连接中断。
封装选择与性能考量
GLB 采用 DSR 架构，使用 GUE 封装以携带备 RS 地址。相比 IPIP，GUE 可避免在 IP option 中存放信息导致的路由器慢路径处理；相比直接 IP 封装，GUE 基于 UDP 使中间路由器能按四元组哈希，分散流量，避免单一队列瓶颈。这些选择平衡了功能需求与转发性能。
DPDK 实现与流量分流
GLB 基于 DPDK 实现，利用 Packet Distributor 将工作并行到多个 CPU，扩展性强。但 DPDK 接管流量后，非数据面流量（如 SSH）需通过 Flow Bifurcation 分流：借助 SR-IOV 或网卡过滤功能，将物理网卡虚拟为多个，内核协议栈和 DPDK 各走独立虚拟网卡，硬件分流几乎不耗 CPU，可保持线速。
Q&A
GitHub的四层负载均衡GLB有什么创新之处？
GLB的连接保持技术创新性强，不需要同步信息，且不保存状态，基于TCP连接五元组hash进行转发决策。
GLB是如何生成转发表的？
转发表生成依赖于Rendezvous hashing，确保每一行的两个RS不同，且所有RS出现次数大致相同。
GLB支持哪些协议？
GLB支持TCP和ICMP，但不支持UDP。
GLB如何处理非数据面流量？
GLB使用Flow Bifurcation将物理网卡虚拟成多个虚拟网卡，以区分Kernel协议栈和DPDK流量。
GLB的健康检查机制是怎样的？
GLB运行健康检查程序，若发现不健康的RS，会交换主备RS，以确保新连接转发到健康的RS。
GLB与Google Maglev的连接保持方案有什么不同？
GLB不保存状态，转发时SYN包和其他包使用相同逻辑，而Maglev需要保存连接状态，可能导致连接中断。
