踏上eBPF之路 - 系列一：初探eBPF
这份笔记详尽记录了我们从零开始，逐步揭开 eBPF 神秘面纱的全过程。它遵循我们的对话轨迹，从一个个问题出发，最终汇成一幅完整的技术图景，为后续的探索奠定坚实的基础。
第一步：初识eBPF，一个安全的“内核通行证”
我们的旅程始于一个最基本的问题：“eBPF是什么？”
为了理解这个概念，我们引入了一个比喻：将 Linux 内核想象成一个安保森严的“大使馆”，它通常不允许外部人员随意进入或改变其内部规则。而 eBPF 就好比一种**“特殊通行证”和一套“行为准则”**。它允许我们派遣一个经过严格审查的“临时顾问”（eBPF 程序）进入内核，去完成特定的任务，例如：
- 观察 (Observability)：像侦探一样记录系统内部的活动，如网络流量、系统调用、文件访问等。
- 行动 (Networking & Security)：像安保人员一样，根据预设规则拦截可疑的网络请求或进程行为。
最关键的是，这个过程是绝对安全的。在“顾问”进入内核前，一个名为验证器 (Verifier) 的安检系统会仔细检查其所有行动计划，确保它不会导致系统崩溃、不会陷入死循环、也不会访问未授权的内存。
结论：eBPF 是一种让我们能够安全、高效地在 Linux 内核中运行自定义代码的技术，它像即插即用的“内核插件”，功能强大且无风险。
第二步：探寻舞台，理解Linux内核这位“CEO”
要理解 eBPF 的强大，必须先了解它的运行舞台——Linux 内核。我们将其比作一个庞大公司的 CEO。这位 CEO 不直接参与具体业务，但掌控和管理着公司的一切核心运作，包括：
- 进程管理：决定哪个程序可以使用 CPU。
- 内存管理：精确管理内存的分配和回收。
- 设备驱动：作为“翻译官”，与硬件进行沟通。
- 系统调用：作为“秘书处”，处理应用程序提交的资源请求。
为了保证 CEO 的安全，公司被划分为两个区域：内核空间（CEO 办公室，最高权限）和用户空间（员工工位，权限受限）。这种隔离机制是系统稳定的基石。
第三步：深挖细节，揭秘内核的“特权环”
我们进一步探究，发现内核态和用户态的划分背后，是 CPU 硬件层面的保护环 (Protection Rings) 机制。
- 现代 CPU 提供了 Ring 0 到 Ring 3 四个权限级别，Ring 0 权限最高。
- Linux 为了简化设计和增强可移植性，只使用了 Ring 0（内核态） 和 Ring 3（用户态）。
- 这意味着，那些理论上可以放在中间层（Ring 1, Ring 2）的组件，比如设备驱动程序，在 Linux 中被直接放在了 Ring 0 运行。
这个设计决策带来了极致的性能，但也引入了一个风险：一个有 Bug 的驱动程序可能会导致整个系统崩溃。这正是 eBPF 通过其安全验证机制想要解决的核心痛点之一。
第四步：核心关联，eBPF在内核中的位置与原理
既然驱动程序在 Ring 0，那么 eBPF 呢？答案是肯定的：eBPF 程序正是在内核态 (Ring 0) 中运行的。
它的工作流程清晰地体现了其设计哲学：
- 加载：用户态程序将 eBPF 字节码加载进内核。
- 验证：内核的“验证器”对代码进行严格的安全审查。
- 运行：通过验证后，eBPF 程序被附加到内核的某个事件点上，当事件发生时，代码直接在内核态被触发和执行，其速度通过即时编译 (JIT) 达到原生水准。
结论：eBPF 巧妙地结合了在内核态运行的极致性能和由验证器保障的绝对安全。
第五步：蓝图展现，如何开发与应用eBPF
我们了解到，开发 eBPF 应用通常包含两部分：
- 内核态程序：用受限的 C 语言编写，负责核心逻辑。
- 用户态程序：用 Go、Python、Rust 等语言编写，负责加载和控制内核态程序。
主流开发框架分为两种：
- BCC：适合快速原型和学习，它在运行时编译 C 代码，但依赖较重。
- libbpf + CO-RE：现代化的标准方式，实现“一次编译，到处运行”，轻量且易于分发，是生产环境的首选。
基于这些能力，eBPF 可以被用来开发三大类应用：
- 可观测性：扮演“超级侦探”，进行性能分析和故障诊断。
- 网络：扮演“智能交通警察”，实现高性能负载均衡和 DDoS 防御。
- 安全：扮演“贴身保镖”，进行运行时安全监控和系统调用过滤。
第六步：解构性能，为何深入内核却影响甚微
一个核心疑问是：为什么 eBPF 能深入内核，却几乎不影响性能？我们用“记者”和“速记员”的比喻解开了谜团。
传统工具像“记者”，需要在用户态和内核态之间频繁地来回奔跑（上下文切换）和传递大量原始信息（数据拷贝），开销巨大。
而 eBPF 就像一位被允许坐在会场里的“速记员”：
- 事件驱动：只在事件发生时才工作，不产生空闲开销。
- 在内核内处理数据：在内核中就对数据进行聚合与过滤，只将最终的小量结果传递出来，极大地减少了数据拷贝。
核心：eBPF 的高性能秘诀在于，它从根本上避免了昂贵的上下文切换和数据拷贝。
第七步：终极解谜，eBPF与数据包的相遇
我们对话的最高潮，落在了对一个网络数据包处理流程的终极解谜上。
首先，我们明确了 eBPF 的双重身份：它既可以像“书记员”一样被动地观察内核处理过程，也可以像“交通警察”一样主动地干预处理流程。
接着，我们提出了最关键的问题：eBPF 究竟在何时、何地与数据包相遇？
答案是，eBPF 可以在多个不同阶段介入。我们厘清了两个最重要的网络挂钩点：XDP 和 TC。
最后，我们解决了最后一个疑惑：“CPU 是如何知道数据包来了的？” 答案是 DMA (直接内存访问) 和 中断 机制。eBPF (特别是 XDP) 程序，是 CPU 响应中断后，第一个接触到这个数据包的软件逻辑。
附录：一个网络数据包的完整旅程
为了将所有知识点融会贯通，我们以一个数据包的视角，完整地走一遍它在系统中的旅程。
上篇：收包 (Ingress)
- 物理接收：数据包从网络到达网卡 (NIC)。
- DMA传输：网卡通过 DMA 技术，在不占用 CPU 的情况下，将数据包的数据直接写入内存中的一个环形缓冲区 (Ring Buffer)。
- 硬件中断：数据写入完成后，网卡向 CPU 发送一个硬件中断，通知有新数据到达。
- 驱动与XDP：CPU 响应中断，开始执行网卡驱动程序。在驱动程序处理的最早阶段，XDP (Express Data Path) 挂钩点被触发。挂载于此的 eBPF 程序可以进行第一次处理，做出 XDP_PASS (放行), XDP_DROP (丢弃) 等决策。这是软件层面处理数据包的第一个机会，性能极高。
- 内核协议栈：如果数据包被放行，内核会为其分配一个核心的数据结构 sk_buff，并开始解析 IP 头、TCP/UDP 头等信息。
- TC入口与路由：数据包进入 TC (Traffic Control) 层的入口 (Ingress) 挂钩点，挂载于此的 eBPF 程序可以访问到完整的 sk_buff 信息，进行更复杂的过滤、修改或重定向，例如实现负载均衡。随后，内核根据路由表决定数据包的去向。
- Socket交付：内核根据目标端口号，将数据包放入与目标应用程序关联的 Socket 的接收缓冲区。
- 应用读取：应用程序通过 read() 或 recv() 等系统调用，从 Socket 缓冲区读取数据，完成接收。
下篇：发包 (Egress)
- 应用写入：应用程序通过 write() 或 send() 等系统调用，将要发送的数据写入 Socket 的发送缓冲区。
- 内核协议栈：内核从 Socket 缓冲区取出数据，为其添加 TCP/IP 等头部信息，构建 sk_buff。
- 路由与TC出口：内核根据目标地址查找路由，确定出口设备。在数据包被传递给网卡驱动之前，会经过 TC 的出口 (Egress) 挂钩点，eBPF 程序可以在此进行最后的处理，如流量整形、打标记等。
- 驱动与DMA：sk_buff 被传递给网卡驱动程序。驱动程序指示网卡通过 DMA 从内存中读取数据包，并准备发送。
- 物理发送：网卡将数据包从物理端口发送到网络中。