从零构建 BPF L4 负载均衡器：XDP + sockmap + 连接跟踪的工程实践

在现代云原生基础设施中，L4 负载均衡是几乎所有流量入口的第一道关卡。传统的 IPVS 模式（Lvs）和基于 iptables 的 kube-proxy 方案虽然成熟，但在百万级 QPS 场景下，它们频繁的 iptables 规则遍历和多次网络栈跳转带来了不可忽视的延迟。内核 4.18+ 引入的 eBPF sockmap 机制和 XDP 提供了在数据包级别和 socket 级别做负载均衡的能力，本文将带你从零构建一个生产可用的 BPF L4 负载均衡器。

一、架构总览

整个负载均衡器分为三层：

• 控制平面（用户空间）：负责后端健康检查、路由规则下发、可观测性
• 数据包路径（XDP）：在网卡驱动层解析 TCP/UDP 首部，做 DNAT，直接重定向到目标网卡
• Socket 路径（BPF_SK_SKB）：在 socket 层面实现真正的零拷贝负载均衡，绕过整个网络栈

Client ──► NIC ──► XDP (parse, pick backend, rewrite dst) ──► NIC (backend)
                            │
                            └── socket-level: bpf_sk_redirect_map ──► backend socket

为什么需要两层？XDP 处理数据包层面的连接路由决策，但要让 payload 零拷贝到达后端 socket，必须借助 sockmap 机制。两者结合才能实现真正的 L4 LB。

二、核心 BPF 程序

2.1 XDP 程序：连接路由

// xdp_l4lb.c
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>

// 后端地址表，由控制面写入
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, __u32);       // vip
    __type(value, struct backend);
    __uint(max_entries, 256);
} backends SEC(".maps");

struct backend {
    __u32 ip;         // 后端真实 IP
    __u16 port;       // 后端真实端口
    __u8  weight;     // 权重
    __u8  alive;      // 健康状态
};

// 连接跟踪：源地址 -> 选定的后端
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __type(key, struct conn_key);   // {sip, dip, sport, dport}
    __type(value, __u32);           // 选定后端的 ip
    __uint(max_entries, 1000000);
} conn_track SEC(".maps");

struct conn_key {
    __u32 sip;
    __u32 dip;
    __u16 sport;
    __u16 dport;
    __u8  proto;
    __u8  pad[3];
};

SEC("xdp")
int xdp_lb(struct xdp_md *ctx)
{
    void *data_end = (void *)(long)ctx->data_end;
    void *data     = (void *)(long)ctx->data;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    __u32 dst_ip = bpf_ntohl(ip->daddr);
    __u16 dst_port = 0;

    if (ip->protocol == IPPROTO_TCP) {
        struct tcphdr *tcp = (void *)(ip + 1);
        if ((void *)(tcp + 1) > data_end)
            return XDP_PASS;
        dst_port = bpf_ntohs(tcp->dest);
    } else if (ip->protocol == IPPROTO_UDP) {
        struct udphdr *udp = (void *)(ip + 1);
        if ((void *)(udp + 1) > data_end)
            return XDP_PASS;
        dst_port = bpf_ntohs(udp->dest);
    } else {
        return XDP_PASS;
    }

    // 检查该 VIP 是否在服务表中
    struct backend *be = bpf_map_lookup_elem(&backends, &dst_ip);
    if (!be || !be->alive)
        return XDP_PASS;

    // 查找已有连接跟踪
    struct conn_key key = {};
    key.sip = bpf_ntohl(ip->saddr);
    key.dip = dst_ip;
    key.dport = dst_port;
    key.proto = ip->protocol;
    if (ip->protocol == IPPROTO_TCP) {
        struct tcphdr *tcp = (void *)(ip + 1);
        key.sport = bpf_ntohs(tcp->source);
    } else {
        struct udphdr *udp = (void *)(ip + 1);
        key.sport = bpf_ntohs(udp->source);
    }

    __u32 *tracked = bpf_map_lookup_elem(&conn_track, &key);
    __u32 selected_ip;

    if (tracked) {
        // 已有连接，确保后端仍然存活
        struct backend *old_be = bpf_map_lookup_elem(&backends, tracked);
        if (old_be && old_be->alive) {
            selected_ip = *tracked;
        } else {
            // 原后端下线，重新选择
            selected_ip = pick_weighted_backend(dst_ip, &be->weight);
            bpf_map_update_elem(&conn_track, &key, &selected_ip, BPF_ANY);
        }
    } else {
        // 新连接或首包，加权选择
        selected_ip = pick_weighted_backend(dst_ip, &be->weight);
        bpf_map_update_elem(&conn_track, &key, &selected_ip, BPF_ANY);
    }

    // DNAT：改写目标 MAC 和 IP
    // 实际生产中需要查后端的 MAC（此处先简化）
    ip->daddr = bpf_htonl(selected_ip);
    ip->check = 0;
    // ... 重新计算 ip checksum (bpf_csum_diff)

    return XDP_TX;  // 直接从接收口发送
}

上面的 pick_weighted_backend 是个内联辅助函数，负责按权重随机选择后端：

static __always_inline __u32 pick_weighted_backend(__u32 vip, __u8 *weight)
{
    __u32 rnd = bpf_get_prandom_u32();
    __u8 w = *weight ? *weight : 1;

    // 简化版：weight 直接代表数量（1-255 个后端实例）
    // 生产环境应使用一致性哈希或双链结构
    return vip ^ (rnd % w);  // 实际中使用更复杂的 ring 选择
}

2.2 Socket 级零拷贝：BPF_SK_SKB

sockmap 的魔法在于：当数据包已到达本地网络栈时，可以把它"直接桥接"出去，跳过整个 TCP/IP 协议栈。

// sk_skb.c
struct {
    __uint(type, BPF_MAP_TYPE_SOCKHASH);
    __type(key, __u64);   // {sip, dip, sport, dport}
    __type(value, __u32); // socket fd 或索引
    __uint(max_entries, 65535);
} sock_map SEC(".maps");

SEC("sk_skb/stream_parser")
int bpf_skb_parser(struct __sk_buff *skb)
{
    return skb->len;  // 告诉内核处理完整数据包
}

SEC("sk_skb/stream_verdict")
int bpf_skb_verdict(struct __sk_buff *skb)
{
    __u64 key = build_key_from_skb(skb);

    // 查找对应的后端 socket
    int ret = bpf_sk_redirect_map(skb, &sock_map, key, BPF_F_INGRESS);

    if (ret == BPF_REDIRECT_SUCCESS)
        return SK_PASS;
    return SK_DROP;
}

这里的关键：bpf_sk_redirect_map 把当前 socket 缓冲区里的数据包直接投递到目标 socket 的接收队列，全程零拷贝，无需经过协议栈的 ip_rcv → tcp_rcv → recvmsg 路径。

三、用户空间控制面

上面的 BPF 程序只是"数据面"，真正让负载均衡器运行起来还需要一个控制面。我们用 Go + cilium/ebpf 库搭一个最小化的面：

// cmd/lb/main.go
package main

import (
    "encoding/binary"
    "log"
    "net"
    "os"
    "os/signal"
    "syscall"

    "github.com/cilium/ebpf"
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/rlimit"
)

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang xdp_lb ../bpf/xdp_l4lb.c
//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang sk_skb ../bpf/sk_skb.c

type Backend struct {
    IP     uint32
    Port   uint16
    Weight uint8
    Alive  uint8
}

type Config struct {
    VIP        string
    BackendIPs []string
    Port       uint16
}

func main() {
    // 解除 RLIMIT_MEMLOCK（eBPF maps 需要）
    if err := rlimit.RemoveMemlock(); err != nil {
        log.Fatal(err)
    }

    // 加载编译好的 BPF 内核对象
    objs := xdp_lbObjects{}
    if err := loadXdp_lbObjects(&objs, nil); err != nil {
        log.Fatalf("loading objects: %v", err)
    }
    defer objs.Close()

    // attach XDP 到网卡
    iface, err := net.InterfaceByName("eth0")
    if err != nil {
        log.Fatalf("lookup eth0: %v", err)
    }

    l, err := link.AttachXDP(link.XDPOptions{
        Program:   objs.XdpLb,
        Interface: iface.Index,
    })
    if err != nil {
        log.Fatalf("attach XDP: %v", err)
    }
    defer l.Close()

    log.Println("BPF L4 LB attached to eth0")

    // 写入后端表
    cfg := loadConfig("lb.yaml")
    vip := ipToKey(cfg.VIP)

    for i, ip := range cfg.BackendIPs {
        be := Backend{
            IP:     ipToKey(ip),
            Port:   uint16(cfg.Port),
            Weight: 100 / len(cfg.BackendIPs),  // 等比分配
            Alive:  1,
        }
        if err := objs.Backends.Update(uint32(i), be, ebpf.UpdateAny); err != nil {
            log.Fatalf("update backends map: %v", err)
        }
    }

    // 启动健康检查协程
    go healthCheckLoop(&objs, cfg)

    // 处理 SIGTERM 优雅停机
    sigs := make(chan os.Signal, 1)
    signal.Notify(sigs, syscall.SIGTERM, syscall.SIGINT)
    <-sigs

    log.Println("graceful shutdown...")
}

健康检查部分，我们用纯 TCP connect 来判定后端状态，每 2 秒轮询：

func healthCheckLoop(objs *xdp_lbObjects, cfg Config) {
    ticker := time.NewTicker(2 * time.Second)
    defer ticker.Stop()

    for <-ticker.C {
        for i, ip := range cfg.BackendIPs {
            addr := fmt.Sprintf("%s:%d", ip, cfg.Port)
            alive := checkTCP(addr)

            var one uint8 = 1
            var zero uint8 = 0
            if alive {
                objs.Backends.Update(uint32(i), one, ebpf.UpdateAny)
            } else {
                objs.Backends.Update(uint32(i), zero, ebpf.UpdateAny)
            }
        }
    }
}

func checkTCP(addr string) bool {
    conn, err := net.DialTimeout("tcp", addr, 1*time.Second)
    if err != nil {
        return false
    }
    conn.Close()
    return true
}

四、生产级优化

4.1 加权一致性哈希

在实际生产环境中，后端扩缩容时，如果采用纯随机分配，会破坏已有连接的会话亲和性。生产级方案需要一致性哈希：

// ring_hash.go
import "github.com/serialx/hashring"

type WeightedRing struct {
    ring *hashring.HashRing
}

func NewWeightedRing(ips []string, weights map[string]int) *WeightedRing {
    nodes := make([]string, 0)
    for _, ip := range ips {
        weight := weights[ip]
        for w := 0; w < weight; w++ {
            nodes = append(nodes, fmt.Sprintf("%s#%d", ip, w))
        }
    }
    return &WeightedRing{ring: hashring.New(nodes)}
}

func (r *WeightedRing) Get(key string) string {
    node, _ := r.ring.GetNode(key)
    // 去掉虚拟节点后缀
    parts := strings.SplitN(node, "#", 2)
    return parts[0]
}

但一致性哈希有个严重问题：当后端掉线时，球面上的位置会塌缩，导致该位置的全部连接都漂移到下一个后端——引发级联过载。

更好的方案是 Ketama + bounded loads：

func (r *WeightedRing) GetWithBound(key string, maxLoadFactor float64) string {
    // Ketama 哈希 2 次
    for i := 0; i < r.maxRetries; i++ {
        candidate := r.ring.GetNode(fmt.Sprintf("%s-%d", key, i))
        if r.loadOf(candidate) < maxLoadFactor {
            candidate = r.candidates[0]  // fallback
        }
        return candidate
    }
    return r.ring.GetNode(key)  // exhausted
}

bounded loads 是 Google Maglev 和 Envoy 使用的策略：每个后端"负载"有一个上界，当超过上界时自动尝试下一个候选。这使得最坏情况下单后端负载仅为平均值的 1.25 倍（理论下界 1.0）。

4.2 BPF Map 的规模化设计

连接跟踪表是最关键的 BPF map，设计要点：

• 使用 BPF_MAP_TYPE_LRU_HASH 而非普通 hash map——自动淘汰最久未使用的条目，避免内存爆炸
• key 设计为 5 元组 {sip, dip, sport, dport, proto}，区分方向
• max_entries 按 并发连接数 × 1.5 设置（留 buffer）
• 在 BPF 程序中用 bpf_map_update_elem(..., BPF_NOEXIST) 避免覆盖已有条目

// 更健壮的场景：VIP 绑定的多个后端
struct vip_backends {
    __u32 backends[16];   // 最多 16 个后端
    __u8  count;
    __u8  pad;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, __u32);              // vip
    __type(value, struct vip_backends);
    __uint(max_entries, 1024);
} vip_table SEC(".maps");

4.3 无旋转后端切换

生产中最棘手的场景是后端扩缩容时的连接迁移。一个下线操作如果直接移除 map 条目，客户端 TCP 连接的后续包就找不到后端。正确做法是设置" draining 状态"：

struct backend {
    __u32 ip;
    __u16 port;
    __u8  weight;
    __u8  alive;
    __u8  draining;    // 0=active, 1=draining
    __u8  pad;
};

// 选择逻辑
static __always_inline __u32 pick_backend(struct vip_backends *vbe)
{
    // 第一轮：只选 alive=1 && draining=0 的
    // 第二轮：若无可选，退回到 draining=1 的（处理残留连接）
    // 第三轮：全部不可用，返回 XDP_PASS
    for (int phase = 0; phase < 2; phase++) {
        for (int i = 0; i < vbe->count; i++) {
            struct backend *be = bpf_map_lookup_elem(&backend_pool, &vbe->backends[i]);
            if (!be) continue;

            if (phase == 0 && be->alive && !be->draining)
                return be->ip;
            if (phase == 1 && be->alive && be->draining)
                return be->ip;
        }
    }
    return 0; // 触发 PASS
}

这个两阶段选择策略是 kube-proxy IPVS 模式在实现 graceful termination 时的核心思想，用 BPF 可以直接内化到数据面。

五、调试与可观测性

5.1 bpf_trace_printk

最简单的 BPF 调试方式，但性能极差（每个事件写 tracefs 缓冲区），仅适用于开发阶段：

char fmt[] = "sip=%x dip=%x sport=%d dport=%d => backend=%x";
bpf_trace_printk(fmt, sizeof(fmt),
    bpf_ntohl(ip->saddr), dst_ip,
    bpf_ntohs(tcp->source), dst_port, selected_ip);

查看日志：

cat /sys/kernel/debug/tracing/trace_pipe

5.2 BPF ring buffer 导出 metrics

生产环境使用 BPF_MAP_TYPE_RINGBUF 替代 perfd_event_array，支持零碎通量和高吞吐：

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 1 << 24);  // 16MB
} events SEC(".maps");

struct lb_event {
    __u32 sip, dip, backend;
    __u16 sport, dport;
    __u64 ts;
    __u8  status;  // 0=ok, 1=backend_down, 2=no_backend
};

SEC("xdp")
int xdp_lb(struct xdp_md *ctx)
{
    // ... 路由逻辑 ...

    struct lb_event *ev = bpf_ringbuf_reserve(&events, sizeof(*ev), 0);
    if (ev) {
        ev->sip = bpf_ntohl(ip->saddr);
        ev->dip = dst_ip;
        ev->backend = selected_ip;
        ev->ts = bpf_ktime_get_ns();
        ev->status = backend_down ? 1 : (no_backend ? 2 : 0);
        bpf_ringbuf_submit(ev, 0);
    }

    return XDP_TX;
}

用户空间的 Prometheus exporter 可以轻松消费 ring buffer 并输出 histogram：

rd, err := ringbuf.NewReader(objs.LbEvents)
for {
    record, err := rd.Read()
    ev := lbEventFromRaw(record.RawSample)
    requestsTotal.WithLabelValues(ev.status).Add(1)
}

5.3 bpftool 动态查看 map 内容

# 查看所有 map
bpftool map show

# dump map 内容
bpftool map dump id <map_id>

# 查看 BPF 程序 JIT 编译后的指令
bpftool prog dump xlated id <prog_id>

# 查看某个 BPF 程序的运行状态（运行时长、invocation 次数）
bpftool prog show id <prog_id>

六、性能基准

在 AWS c6i.4xlarge（16 vCPU, 32GB）上，对比 IPVS、纯 XDP、XDP+sockmap 三者的 TCP 短连接和长连接吞吐：

XDP + sockmap 模式在两种场景下都有显著优势，特别是长连接零拷贝场景下接近线速。

七、实战踩坑指南

7.1 BPF verifier 拒绝你的程序

最常见的 verifier 报错：

R9 invalid mem access 'inv'

原因：指针运算未做边界检查。verifier 要求每一个对 packet data 的访问都必须有明确的 if (ptr + N > data_end) 检查。

解法：把所有 packet 数据访问都放在边界检查之后。记住 BPF 程序的 "look first, touch later" 原则。

7.2 XDP 模式选择（driver vs generic）

XDP 有三种 attach 模式：

• native XDP（driver mode）：在网卡 driver 的 NAPI poll 之前执行，性能最优，但需要驱动支持
• offload XDP（ HW offload）：直接将 BPF 编译到 SmartNIC 或 ASIC 上执行（Netronome/SmartNIC）
• generic XDP（skb mode）：在 netif_receive_skb_internal 中执行，fallback 用，性能差 2-3 倍

# 检查网卡是否支持 native XDP
ethtool -i eth0 | grep xdp
# 或者查看内核 log
dmesg | grep xdp

7.3 连接跟踪表过期策略

BPF_MAP_TYPE_LRU_HASH 的淘汰基于全局访问时间，不能按 TTL 精确淘汰。如果你的 VIP 支持 websocket（小时级长连接），LRU 会导致误淘汰。

解决方案：

• 使用 BPF_MAP_TYPE_HASH + 定时器（通过用户空间定时遍历 map）
• 或者用 BPF_MAP_TYPE_LRU_HASH 但配合连接首包刷新：在 TCP SYN / FIN 包上做 map 操作，让连接在空闲达到时限后才被淘汰
• 新内核 6.8+ 支持 BPF_MAP_TYPE_LRU_HASH 的 capacity 被溢出时主动驱逐策略

7.4 多 VIP 共享后端时的 BPF map 冲突

当多个 VIP 映射到同一组后端时，BPF map 的 value 如果把后端 IP 写在一起，更新一个后端会影响所有共享它的 VIP。

解法：将"后端健康状态"单独放在一个名为 backend_health 的 map 里，所有 VIP 共享读这个 map来实现级联健康检查：

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, __u32);
    __type(value, __u8);   // alive
    __uint(max_entries, 1024);
} backend_pool SEC(".maps");  // 所有 VIP 共享查这个

八、与现有方案对比

作者的实践经验：在 P99 延迟要求 < 1ms、QPS > 500K 的场景下，BPF LB 几乎是唯一选择；否则 IPVS 的综合优势更明显。

九、总结

从 XDP 在 nic driver 层的包处理，到 sockmap 在 socket 层的零拷贝桥接，eBPF 为 L4 负载均衡提供了构建高性能网络数据面的完整工具链。

关键设计决策：

1. XBP + sockmap 两段式架构：包层决策 + socket 层零拷贝
2. LRU_MAP 做连接跟踪 + 锥形探活保证会话亲和
3. 重量级一致性哈希 + bounded loads 避免雪崩
4. Ringbuf + Prometheus 做生产级可观测性
5. Draining 状态实现零宕机后端切换

整个系统的核心 BPF 代码不超过 600 行，用户空间控制面不到 800 行，但能实现生产环境所需的所有核心功能。关键是充分理解 verifier 的约束和 BPF 程序执行的上下文，然后把正确的 map 语义匹配到对应的流量特征上。

完整代码现已开源，覆盖本文所有实现细节。