2. eBPF 基础回顾：程序类型、CO-RE 原理与库生态

在深入流量可视化与配额校准之前，必须夯实 eBPF 的核心基础。本章聚焦三个关键维度：程序类型决定了 eBPF 的挂载点与触发时机；CO-RE（一次编译，到处运行）解决了内核版本差异带来的兼容性痛点；libbpf 与 cilium/ebpf 则是当前最主流的两大开发库。理解这三者，是后续编写可观测性探针的基石。

2.1 eBPF 程序类型与挂载点

eBPF 并非单一的执行单元，而是根据挂载位置和触发事件划分为多种类型。每种类型对应不同的内核子系统，决定了程序能访问的数据和执行的上下文。下表列出了与网络可观测性最相关的几种类型：

2.2 CO-RE 原理：一次编译，到处运行

传统 eBPF 程序需要针对每个内核版本重新编译，因为内核数据结构（如 struct sk_buff）的布局在不同版本间可能发生变化。CO-RE（Compile Once – Run Everywhere）通过以下机制解决了这一痛点：

1. BTF（BPF Type Format）： 内核将自身的数据结构布局以调试信息形式暴露给 eBPF 程序。
2. 重定位（Relocation）： 编译器在生成 BPF 字节码时，不直接硬编码字段偏移量，而是记录一个“访问路径”（如 task->pid）。
3. 运行时适配： 加载器（如 libbpf）在加载时，根据目标内核的 BTF 信息，动态修正所有字段偏移量。

2.3 libbpf 与 cilium/ebpf 库简介

选择合适的开发库直接影响开发效率和程序性能。目前主流的两大库是 libbpf（C 语言生态） 和 cilium/ebpf（Go 语言生态）。下表从多个维度进行对比：

2.4 最小 eBPF 程序骨架（cilium/ebpf 示例）

以下是一个使用 cilium/ebpf 库编写的 XDP 程序骨架，用于统计经过网卡的数据包数量：

//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang -cflags "-O2 -g -Wall" bpf xdp_stats.c

package main

import (
    "log"
    "net"
    "github.com/cilium/ebpf/link"
    "github.com/cilium/ebpf/rlimit"
)

// 对应 xdp_stats.c 中定义的 map
type bpfObjects struct {
    bpfPrograms
    bpfMaps
}

func main() {
    // 允许当前进程锁定内存
    if err := rlimit.RemoveMemlock(); err != nil {
        log.Fatal(err)
    }

    // 加载编译好的 BPF 对象
    objs := bpfObjects{}
    if err := loadBpfObjects(&objs, nil); err != nil {
        log.Fatal(err)
    }
    defer objs.Close()

    // 挂载到指定网卡
    iface, _ := net.InterfaceByName("eth0")
    link, err := link.AttachXDP(link.XDPOptions{
        Program:   objs.XdpStatsFunc,
        Interface: iface.Index,
    })
    if err != nil {
        log.Fatal(err)
    }
    defer link.Close()

    log.Println("XDP 程序已挂载到 eth0，开始统计...")
    // 后续可通过 map 读取统计值
}