📚 课程目录第2章 eBPF基础回顾

2. eBPF 基础回顾：eBPF 程序类型、eBPF Map、eBPF Helper 函数、eBPF 验证器

在深入网络观测与延迟回归检查之前，必须重新夯实 eBPF 的核心基础。本章将围绕四个关键支柱展开：程序类型决定了 eBPF 的挂载点与能力边界；eBPF Map 是内核与用户态共享数据的核心结构；Helper 函数提供了安全访问内核服务的唯一入口；验证器则保证了程序执行的安全性。理解这些基础，是后续构建高性能观测工具的前提。

2.1 eBPF 程序类型：挂载点与能力边界

eBPF 程序类型决定了程序可以挂载到内核的哪个事件上，以及可以访问哪些内核上下文。不同的程序类型拥有不同的入参（Context）和返回值语义。对于网络观测，以下类型最为关键：

程序类型	挂载点/事件	典型用途	延迟回归检查场景
`BPF_PROG_TYPE_XDP`	网卡驱动层（最早）	DDoS 防护、负载均衡、早期丢包	检查入口流量是否被异常丢弃
`BPF_PROG_TYPE_SCHED_CLS`	TC（Traffic Control）入/出方向	流量整形、QoS、包过滤	观测队列延迟与丢包
`BPF_PROG_TYPE_SOCKET_FILTER`	Socket 层	抓包过滤、socket 级别监控	分析单连接延迟
`BPF_PROG_TYPE_KPROBE`	内核函数入口/出口	动态追踪内核函数	追踪 `tcp_v4_do_rcv` 等函数耗时
`BPF_PROG_TYPE_TRACEPOINT`	静态 tracepoint	稳定、低开销的内核事件追踪	监控 `net:netif_receive_skb` 事件

实践提示：在制品库发布窗口的延迟回归检查中，BPF_PROG_TYPE_KPROBE 和 BPF_PROG_TYPE_TRACEPOINT 是最常用的组合。前者用于捕获特定内核函数的执行时间，后者用于获取稳定的网络事件上下文。

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

eBPF Map 是内核态 eBPF 程序与用户态控制面之间共享数据的核心机制。Map 的类型决定了数据的组织方式和访问模式。在延迟回归检查中，Map 用于存储延迟直方图、连接跟踪表、事件计数等关键指标。

Map 类型	数据结构	典型用途	延迟回归场景
`BPF_MAP_TYPE_HASH`	Key-Value 哈希表	连接跟踪、会话状态	按五元组存储延迟统计
`BPF_MAP_TYPE_ARRAY`	固定大小索引数组	计数器、直方图桶	延迟分布直方图（微秒级桶）
`BPF_MAP_TYPE_PERCPU_HASH`	Per-CPU 哈希表	高性能计数，避免锁竞争	高并发场景下的延迟采样
`BPF_MAP_TYPE_RINGBUF`	环形缓冲区	高效事件推送	实时推送延迟事件到用户态
`BPF_MAP_TYPE_STACK_TRACE`	栈跟踪存储	记录函数调用栈	定位延迟发生的代码路径

  关键设计原则：在延迟回归检查中，推荐使用 BPF_MAP_TYPE_PERCPU_ARRAY 作为直方图桶，以避免多核竞争；使用 BPF_MAP_TYPE_RINGBUF 推送异常延迟事件，确保用户态能及时收到告警。

2.3 eBPF Helper 函数：安全访问内核服务的唯一入口

eBPF 程序不能直接调用内核函数，必须通过 Helper 函数 来访问内核服务。Helper 函数是经过验证器检查的安全接口，提供了数据读取、时间获取、Map 操作、网络包修改等能力。对于延迟回归检查，以下 Helper 函数至关重要：

bpf_ktime_get_ns()：获取当前时间（纳秒级），是计算延迟的基石。
bpf_map_lookup_elem() / bpf_map_update_elem()：操作 Map，用于更新延迟直方图。
bpf_perf_event_output()：将数据推送到用户态（Perf Event / Ringbuf）。
bpf_get_current_pid_tgid()：获取当前进程 PID 和 TGID，用于关联延迟与进程。
bpf_probe_read_kernel()：安全读取内核内存，用于获取 sk_buff 等结构体字段。

注意事项：Helper 函数的可用性取决于 eBPF 程序类型。例如，XDP 程序不能使用 bpf_get_current_pid_tgid()，因为 XDP 运行在网卡驱动层，没有进程上下文。在编写延迟检查程序时，务必查阅对应程序类型的 Helper 函数列表。

2.4 eBPF 验证器：安全保证与性能约束

eBPF 验证器是内核中的一个静态分析器，负责在程序加载前检查其安全性。验证器确保程序不会导致内核崩溃、死循环或非法内存访问。对于延迟回归检查，验证器的约束直接影响程序的设计：

验证器检查项	约束说明	对延迟观测的影响
有界循环	循环次数必须在编译时确定	遍历 Map 时需使用 `#pragma unroll` 或固定次数
栈大小限制	最大 512 字节	延迟直方图桶数不能过多，需合理设计桶粒度
指令数限制	最大 100 万条指令（复杂程序）	延迟计算逻辑需精简，避免复杂条件分支
指针检查	所有内存访问必须经过边界检查	读取 sk_buff 字段时必须使用 `bpf_probe_read_kernel()`
辅助函数调用	只能调用允许的 Helper 函数	不能直接调用 `printk` 或 `kmalloc`

  优化策略：为了通过验证器并保持高性能，延迟回归检查程序应尽量使用 BPF_MAP_TYPE_PERCPU_ARRAY 避免锁竞争，使用 bpf_ktime_get_ns() 直接获取时间戳，并将复杂的聚合逻辑放在用户态完成。验证器不是敌人，而是保证生产环境稳定性的盟友。

2.5 四者协同：构建延迟回归检查的基础设施

在制品库发布窗口的延迟回归检查中，这四者协同工作：

程序类型 选择 BPF_PROG_TYPE_KPROBE 挂载到 tcp_v4_do_rcv 或 __netif_receive_skb_core，捕获网络包处理入口和出口。
Helper 函数 bpf_ktime_get_ns() 在入口和出口分别获取时间戳，计算差值得到单包处理延迟。
eBPF Map 使用 BPF_MAP_TYPE_PERCPU_ARRAY 作为延迟直方图，按微秒粒度累加计数；使用 BPF_MAP_TYPE_RINGBUF 推送超过阈值的异常延迟事件。
验证器 确保上述逻辑在 512 字节栈和 100 万指令限制内安全运行，不会引入死循环或内存泄漏。