eBPF 网络可观测性实战：从内核探针到零侵入流量分析

一、为什么需要 eBPF 做网络可观测性

传统网络可观测性工具链（tcpdump、iptables、netstat）面临三个核心困境：

性能损耗高：tcpdump 使用 AF_PACKET 套接字抓包，每个数据包需要从内核态拷贝到用户态，万兆网络下 iptables TRACE 规则可导致 40% 以上的吞吐下降。

侵入性强：安装 SystemTap 或内核模块需要重新编译或加载内核代码，生产环境风险极高，一次内核 panic 可能造成数百万损失。

可定制性差：tcpdump 过滤器语法固定，无法实现"统计每个容器 TCP 重传次数"这类自定义聚合需求，只能导出 pcap 再做离线解析。

eBPF（Extended Berkeley Packet Filter）的出现彻底改变了这一格局。它允许在内核中安全地运行沙箱化程序，无需修改内核源码或加载内核模块，以近乎零损耗的方式实现网络数据包过滤、聚合统计和动态追踪。

二、eBPF 核心机制深度解析

2.1 执行流程：从 C 代码到内核字节码

eBPF 程序的执行经过五个关键阶段：

阶段一：编译。LLVM/Clang 将 eBPF C 代码编译为 eBPF 字节码（RISC 风格的 64 位指令集），目标 triple 为 bpf 或 bpfeb/bpfel。

阶段二：验证。内核中的 eBPF Verifier 对字节码进行静态分析，确保程序不会导致内核崩溃。它模拟所有执行路径，拒绝越界内存访问、未初始化寄存器使用、无限循环（除非显式标注 #pragma unroll）等危险操作。

阶段三：JIT 编译。通过验证的 eBPF 字节码由 JIT 编译器转换为本机机器码（x86_64 / ARM64），与原生内核代码性能等同。在 x86_64 上，JIT 编译后的 eBPF 函数调用开销仅为 1-2 个 CPU 周期。

阶段四：挂载。JIT 后的程序被挂载到特定的 hook 点：XDP（网络驱动层）、TC（流量控制层）、kprobe/uprobe（内核/用户态函数探针）、tracepoint（预定义跟踪点）等。

阶段五：事件驱动执行。当数据包经过 XDP hook 点、或内核函数被 kprobe 拦截时，eBPF 程序被触发执行，通过 Maps 与用户态交换数据。

2.2 eBPF Maps：内核态与用户态的数据桥梁

Maps 是 eBPF 程序存储状态和传递数据的核心数据结构。不同类型 Maps 在网络监控中有明确分工：

BPF_MAP_TYPE_HASH：键值对存储，适合保存每个连接的五元组（src_ip, dst_ip, src_port, dst_port, protocol）到连接状态的映射。查找复杂度 O(1)，最多支持 2^32 个条目。在监控 HTTPS 流量时，可用 HASH Map 统计每个目标 IP 的 TLS 握手成功率。

BPF_MAP_TYPE_PERCPU_HASH：每个 CPU 核心维护独立的 HASH Map 实例，避免多核竞争。适合高并发的包速率统计，读取时合并所有 CPU 的结果。单核每秒可处理 600 万次 Map 操作。

BPF_MAP_TYPE_RINGBUF：一个生产者-消费者模型的环形缓冲区，eBPF 程序写入事件，用户态程序异步读取。相比 PERF_EVENT_ARRAY（每个 CPU 一个 buffer），RING_BUFFER 自动处理 CPU 间的负载均衡，丢包率更低。适合发送监控事件（如 DNS 查询日志、TCP 重传告警）到用户态。

BPF_MAP_TYPE_LPM_TRIE：最长前缀匹配树，存储 IP 网段到策略的映射。O(5) 时间复杂度（IPv4 最长前缀 32 位）。可实现"按网段丢弃/标记"等策略，是 eBPF-based 负载均衡的核心数据结构。

BPF_MAP_TYPE_QUEUE / STACK：FIFO/LIFO 队列，无锁实现。适合 eBPF 程序间事件传递，或用户态下发配置到内核态。

2.3 网络层 Hook 点全对比

XDP（eXpress Data Path）：最早可介入数据包处理的 hook 点，位于网卡驱动层的 NAPI poll 循环中，在 sk_buff 分配之前。这意味着 XDP 程序处理数据包的内存开销最小（没有 skb 结构体），单核可达 2400 万 pps（packets per second）。适用场景：DDoS 防护、负载均衡、防火墙的丢弃/转发决策。

TC（Traffic Control）：在协议栈 ingress/egress 阶段介入，处理对象是 sk_buff。相比 XDP，TC 可以访问完整的协议头（L2-L7）、socket 信息、以及 cgroup 上下文。TC eBPF 支持修改数据包（bpf_skb_store_bytes）、重定向（bpf_redirect）、标记（bpf_set_csum_level）。Kubernetes 中 Cilium 就用 TC eBPF 替代了 kube-proxy。

Socket Filter / cGroup Socket：挂载到特定 socket 或 cgroup 上，只处理该 socket/cgroup 的流量。cgroup socket eBPF 可以实现进程级别的网络策略——不依赖 iptables 规则，直接在一个 cgroup 内所有 socket 上执行策略。Cilium 的 "per-cgroup 带宽控制" 就是基于此。

Kprobes / Tracepoints：追踪内核函数调用，不涉及数据包本身。适合连接生命周期分析：追踪 tcp_v4_connect、tcp_close、tcp_retranmit_skb 等函数，提取连接建立、关闭、重传等事件。Tracepoints 相比 kprobes 更稳定（ABI 不随内核版本变化）。

三、实战：编写 XDP 网络监控程序

3.1 环境准备

# 需要内核版本 >= 5.4 (推荐 Ubuntu 22.04 / Debian 11)
uname -r
# 5.15.0-91-generic

# 安装依赖
apt install -y llvm clang libbpf-dev linux-tools-generic bpftool

# 验证 eBPF 支持
bpftool feature

3.2 eBPF C 代码：XDP 流量统计

/* xdp_monitor.bpf.c */
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <bpf/bpf_helpers.h>

/* 使用 PERCPU_HASH 避免多核竞争 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_HASH);
    __type(key, __u32);           // 目标 IP
    __type(value, __u64);         // 计数
    __uint(max_entries, 10240);
} ip_traffic SEC(".maps");

SEC("xdp")
int xdp_prog(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 != __constant_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 = ip->daddr;

    __u64 *cnt = bpf_map_lookup_elem(&ip_traffic, &dst_ip);
    if (cnt) {
        __sync_fetch_and_add(cnt, 1);
    } else {
        __u64 init = 1;
        bpf_map_update_elem(&ip_traffic, &dst_ip, &init, BPF_ANY);
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

3.3 用户态加载器（Go 实现）

/* main.go */
package main

import (
    "fmt"
    "net"
    "os"
    "time"

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

type IpKey uint32
type IpValue uint64

func main() {
    spec, err := ebpf.LoadCollectionSpec("xdp_monitor_bpfel.o")
    if err != nil {
        panic(err)
    }

    var obj struct {
        XdpProg   *ebpf.Program `ebpf:"xdp_prog"`
        IpTraffic *ebpf.Map     `ebpf:"ip_traffic"`
    }
    if err := spec.LoadObjects(&obj, nil); err != nil {
        panic(err)
    }
    defer obj.XdpProg.Close()
    defer obj.IpTraffic.Close()

    iface := os.Args[1]
    l, err := link.AttachXDP(link.XDPOptions{
        Program:   obj.XdpProg,
        Interface: ifaceindex(iface),
    })
    if err != nil {
        panic(err)
    }
    defer l.Close()

    fmt.Println("XDP 监控已启动...")

    for {
        time.Sleep(5 * time.Second)
        dumpStats(obj.IpTraffic)
    }
}

func dumpStats(m *ebpf.Map) {
    var key IpKey
    var value IpValue

    iter := m.Iterate()
    fmt.Println("=== 目标 IP 流量统计 (过去5秒) ===")
    for iter.Next(&key, &value) {
        ip := net.IPv4(byte(key>>24), byte(key>>16), byte(key>>8), byte(key))
        fmt.Printf("%-16s %d packets/n", ip.String(), value)
    }
}

3.4 编译与部署

# 编译 eBPF 字节码
clang -O2 -g -target bpf -c xdp_monitor.bpf.c -o xdp_monitor_bpfel.o

# 编译用户态程序
go build -o xdp_monitor main.go

# 运行监控（需要 root 或 CAP_BPF 能力）
sudo ./xdp_monitor eth0

四、实战：TC 程序实现精细流量控制

4.1 基于 TC eBPF 的带宽限速

与 XDP 不同，TC eBPF 可以直接修改 sk_buff 的校验和，实现更精细的流量控制。以下程序在 TC ingress 方向对指定 IP 进行带宽限速：

/* tc_police.bpf.c */
#include <linux/bpf.h>
#include <linux/pkt_cls.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __type(key, __u32);
    __type(value, __u64);
    __uint(max_entries, 1024);
} rate_limit SEC(".maps");

SEC("tc")
int tc_ingress(struct __sk_buff *skb) {
    void *data_end = (void *)(long)skb->data_end;
    void *data = (void *)(long)skb->data;

    struct iphdr *ip = data + 14;
    if ((void *)(ip + 1) > data_end)
        return TC_ACT_OK;

    __u32 dst = ip->daddr;
    __u64 *tokens = bpf_map_lookup_elem(&rate_limit, &dst);

    if (tokens && *tokens < 64) {
        bpf_printk("DROP to %pI4, tokens=%llu/n", &dst, *tokens);
        return TC_ACT_SHOT;
    }

    if (tokens) {
        __sync_fetch_and_sub(tokens, skb->len);
    }

    return TC_ACT_OK;
}

4.2 TC 命令挂载方式

# 添加 clsact qdisc
tc qdisc add dev eth0 clsact

# 挂载 TC eBPF 程序到 ingress
tc filter add dev eth0 ingress bpf da object-file tc_police.o section tc

# 查看
tc filter show dev eth0 ingress

五、实战：kprobe 追踪 TCP 连接异常

5.1 监控 TCP 连接建立延迟

通过 kprobe 追踪 tcp_v4_connect 和 tcp_rcv_state_process 两次时间戳之差，可精确测量 TCP 三次握手延迟。

/* tcp_latency.bpf.c */
#include <linux/bpf.h>
#include <linux/tcp.h>
#include <net/sock.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

struct conn_key {
    __u32 saddr;
    __u32 daddr;
    __u16 sport;
    __u16 dport;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 100000);
    __type(key, struct conn_key);
    __type(value, __u64);
} start SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 256 * 1024);
} events SEC(".maps");

struct event {
    __u32 saddr, daddr;
    __u16 sport, dport;
    __u64 latency_us;
};

SEC("kprobe/tcp_v4_connect")
int BPF_KPROBE(trace_connect_entry, struct sock *sk) {
    struct conn_key key = {0};
    key.saddr = sk->__sk_common.skc_rcv_saddr;
    key.daddr = sk->__sk_common.skc_daddr;
    BPF_CORE_READ_INTO(&key.sport, sk, __sk_common.skc_num);
    BPF_CORE_READ_INTO(&key.dport, sk, __sk_common.skc_dport);

    __u64 ts = bpf_ktime_get_ns();
    bpf_map_update_elem(&start, &key, &ts, BPF_ANY);
    return 0;
}

SEC("kprobe/tcp_rcv_state_process")
int BPF_KPROBE(trace_connect_end, struct sock *sk, struct sk_buff *skb) {
    if (sk->__sk_common.skc_state != TCP_ESTABLISHED)
        return 0;

    struct conn_key key = {0};
    key.saddr = sk->__sk_common.skc_rcv_saddr;
    key.daddr = sk->__sk_common.skc_daddr;
    BPF_CORE_READ_INTO(&key.sport, sk, __sk_common.skc_num);
    BPF_CORE_READ_INTO(&key.dport, sk, __sk_common.skc_dport);

    __u64 *start_ts = bpf_map_lookup_elem(&start, &key);
    if (!start_ts) return 0;

    __u64 delta_ns = bpf_ktime_get_ns() - *start_ts;
    bpf_map_delete_elem(&start, &key);

    struct event *e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e) return 0;

    e->saddr = key.saddr;
    e->daddr = key.daddr;
    e->sport = key.sport;
    e->dport = bpf_ntohs(key.dport);
    e->latency_us = delta_ns / 1000;
    bpf_ringbuf_submit(e, 0);

    return 0;
}

5.2 使用 CO-RE 实现跨内核版本兼容

上述代码使用了 BPF_CORE_READ_INTO 宏，这是 libbpf CO-RE（Compile Once, Run Everywhere）的核心机制。传统的 BTF-based eBPF 需要在目标机器上用相同内核头文件编译，而 CO-RE 允许编译一次 eBPF 字节码后，在不同内核版本（只要 BTF 信息存在）上运行。

# 生成 vmlinux.h（只需执行一次）
bpftool btf dump file /sys/kernel/elf/vmlinux format c > vmlinux.h

# 编译 eBPF 字节码（带 BTF 信息）
clang -O2 -g -target bpf -D__TARGET_ARCH_x86 -I/usr/include/bpf -c tcp_latency.bpf.c -o tcp_latency_bpfel.o

# 生成 skeleton
bpftool gen skeleton tcp_latency_bpfel.o tcp_latency.skel.h

CO-RE 解决了 eBPF 生态最大的痛点——内核版本碎片化。一套 eBPF 二进制可以运行在所有支持 BTF（Linux 5.4+）的内核上，极大简化了可观测性工具的分发和运维。

六、高性能场景关键优化

6.1 批量化 Map 操作减少 syscall

Map 操作（lookup/update/delete）每次触发一次系统调用，高频场景下成为瓶颈。eBPF 支持 bpf_map_lookup_batch、bpf_map_delete_batch 等批量接口：

__u32 batch_key[100];
__u64 batch_vals[100];
__u32 count = 100;
__u64 batch_in = 0, batch_out = 0;

bpf_map_lookup_batch(&conn_map, &batch_in, &batch_out, batch_key, batch_vals, &count, NULL);
bpf_map_delete_batch(&conn_map, batch_key, &count, NULL);

在监控 100 万连接的 NAT 设备时，使用批量操作可将 CPU 使用率从 35% 降至 8%。

6.2 Per-CPU Map 消除锁竞争

默认的 HASH Map 使用自旋锁，高并发下多个 CPU 争抢同一把锁会导致性能悬崖。解决方案是使用 BPF_MAP_TYPE_PERCPU_HASH：每个 CPU 维护独立的 Hash Map 实例，写操作无需加锁，读操作时合并所有 CPU 的数据。在 32 核服务器上，使用 PERCPU_HASH 相比带锁的 HASH Map，Map 写入吞吐提升 20 倍以上。

6.3 XDP 零拷贝转发

XDP 的 bpf_redirect_map 函数允许直接将数据包转发到另一个网卡或 CPU，无需经过协议栈。Intel ixgbe 驱动的 XDP 在 40Gbps 网卡上实现每核 25Mpps 的转发能力（线速）。

struct {
    __uint(type, BPF_MAP_TYPE_DEVMAP);
    __type(key, __u32);
    __type(value, __u32);
    __uint(max_entries, 64);
} tx_port SEC(".maps");

SEC("xdp")
int xdp_forward(struct xdp_md *ctx) {
    __u32 iface_idx = bpf_get_smp_processor_id() % num_queues;
    return bpf_redirect_map(&tx_port, iface_idx, XDP_PASS);
}

七、生产级部署与工具链推荐

7.1 开工前检查清单

内核版本 >= 5.8（推荐 5.15 LTS 或 6.1 LTS），确保 XDP 和 BTF 完整可用。

检查 eBPF 参数：sysctl kernel.bpf_stats_enabled=1 允许查看 eBPF 程序 CPU 耗时。

配额限制：非特权用户可创建的 Map 条目数默认限制为 4096，可通过内核参数调整。

权限：加载 XDP/TC eBPF 需要 CAP_BPF + CAP_NET_ADMIN 能力（或 root）。

7.2 主流 eBPF 工具栈

bcc（BPF Compiler Collection）：基于 Python 的 eBPF 工具集，包含 100+ 预置脚本。例如 tcplife 脚本可展示所有 TCP 连接的完整生命周期（源/目标 IP:Port、持续时长、数据量），一条命令无需代码即可使用。

sudo /usr/share/bcc/tools/tcplife

bpftrace：类似 awk 的 eBPF 脚本语言，适合快速排查问题：

# 统计每个进程的 TCP 发送字节数
bpftrace -e 'kprobe:tcp_sendmsg { @[comm] = sum(arg2); }'

# 追踪 connect() 调用
bpftrace -e '
kprobe:tcp_v4_connect { @start[tid] = nsecs; }
kprobe/tcp_rcv_state_process /@start[tid]/ {
    printf("%s connect took %d ms/n", comm, (nsecs - @start[tid]) / 1000000);
    delete(@start[tid]);
}'

Cilium：基于 eBPF 的 Kubernetes CNI 网络方案，提供 L3-L7 的网络策略、负载均衡、服务网格能力。Cilium 的 Hubble 组件基于 eBPF 实现了无缝的网络可观测性，自动绘制服务依赖图、记录 DNS/HTTP/TCP 黄金指标。

Pixie / Falco / Tetragon：分别专注于应用层可观测性、安全审计、运行时的进程行为监控。

7.3 监控数据导出到 Prometheus

var tcpRetransTotal = prometheus.NewCounterVec(
    prometheus.CounterOpts{Name: "tcp_retrans_total"},
    []string{"dst_ip", "dst_port"},
)

for iter.Next(&key, &value) {
    tcpRetransTotal.WithLabelValues(key.DstIP, key.DstPort).Set(float64(value))
}
// 通过 :9090/metrics 端口暴露为标准格式

八、eBPF 局限与规避方案

指令数限制：经典 eBPF 程序最多 4096 条指令（内核 5.2 之前），eBPF 尾调用（bpf_tail_call）可突破限制——通过尾调用链式跳转到下一个 eBPF 程序，每个程序独立计算指令数。这对实现复杂协议解析非常关键。

不支持循环：Verifier 默认拒绝任何循环（有界循环需显式 #pragma unroll 替代）。替代方案：将循环展开为顺序代码，或使用 bpf_loop() helper（内核 5.17+）。

Maps 的内存限制：默认受 RLIMIT_MEMLOCK 约束。大流量场景下使用 ring buffer 流式输出，避免将所有数据缓存在 Maps 中。

调试困难：eBPF 程序无法使用传统 GDB。调试方法：(1) bpf_printk() 打印日志到 /sys/kernel/debug/tracing/trace_pipe；(2) bpftrace 单行快速验证逻辑；(3) 使用 bpftool prog dump xlated 查看 JIT 编译后的指令。

九、总结

eBPF 的革命性在于实现了内核级别的网络可观测性和控制能力，同时保证了安全性（Verifier 验证）和高性能（JIT 编译）三者的统一。相比 tcpdump 的"全量抓包再分析"模式，eBPF 是"先聚合再导出"，内核内只保留汇总统计量，将用户态需要的数据量缩减了三个数量级。

从生产实践看，eBPF 在以下场景价值最大：(1) Kubernetes 容器网络可观测性（Cilium + Hubble）；(2) 云原生四层负载均衡（Katran、Merbridge）；(3) DDoS 快速防护（XDP DROP 动作）；(4) 内核级安全审计（Falco、Tetragon）。

下一步建议深入学习：bcc 工具集、cilium/ebpf Go 语言库、BPF CO-RE 参考指南。