企业官网建设流程全解析

eBPF 全称：extended Berkeley Packet Filter（扩展的伯克利包过滤器）

一、什么是 eBPF？

eBPF（extended Berkeley Packet Filter）是一种运行在 Linux 内核中的安全、可编程执行环境，
允许用户在不修改内核源码、不加载内核模块的前提下，
动态地向内核关键路径注入自定义逻辑。

需要注意的是，虽然名字里仍然叫Packet Filter，但现代 eBPF 早已不限于网络包过滤，而是被广泛用于：

• 内核可观测性（Tracing / Profiling）
• 高性能网络（XDP / TC）
• 系统与容器安全（LSM eBPF）
• 内核功能扩展

二、为什么会有 eBPF？

在理解 eBPF 之前，先看一个根本问题：

Linux 内核很强，但长期以来“不好改、难观察、扩展危险”。

1. 内核不好扩展

传统上，如果你想在内核中加入逻辑，只有几种方式：

• 修改内核源码并重新编译
• 编写内核模块（.ko）

这些方式的问题非常明显：

• 开发和调试成本极高
• 一个 bug 就可能导致 kernel panic
• 内核版本差异巨大，兼容性差
• 在云环境中通常禁止加载内核模块

👉“在内核里写点逻辑”是一件高风险的事。

2. 内核长期是一个“黑盒”

在生产环境中，我们经常想知道：

• 某个系统调用为什么变慢了？
• 哪个进程在频繁进行 IO？
• 网络包到底在哪一层被丢弃了？

传统工具的局限：

• printk：性能开销巨大
• strace：只能观察用户态
• perf / ftrace：灵活性和可编程性有限

👉缺少一种“低成本、可编程、可动态加载”的内核观测手段。

3. 网络路径过长，性能浪费严重

经典 Linux 网络路径：

NIC → 内核网络栈 → Netfilter → TC → Socket → 用户态

问题在于：

• 路径层级多
• 每层都有函数调用和锁
• 防火墙 / ACL / LB 决策点太靠后

👉如果能在“最早的位置”处理包，性能会好很多。

4. 安全机制不够灵活

传统安全方案（SELinux / AppArmor）：

• 配置复杂
• 规则静态
• 难以做实时、细粒度控制

👉现代系统需要“可编程 + 实时”的安全能力。

三、eBPF 的核心目标

一句话概括 eBPF 的初心：

在不修改内核、不写内核模块的前提下，
安全地、动态地、以极低开销在内核中执行用户逻辑。

它解决问题的方式主要体现在三点：

1. 用户态编写程序，内核负责安全验证
2. 程序可以动态加载和卸载，不需要重启
3. 逻辑运行在关键路径上，性能极高

因此，eBPF 常被称为：

Linux 内核的“插件系统”

四、BPF 和 eBPF 有什么区别？

1. 先有 BPF（Classic BPF）

BPF 最早诞生于 1990 年代，目标非常单一：

高效过滤网络包（tcpdump / libpcap）

特点：

• 指令集极其简单
• 只能访问包数据
• 无状态、无循环
• 仅用于网络过滤

它本质上是一个内核里的规则匹配引擎。

2. eBPF：借了名字，换了灵魂

eBPF（extended BPF）并不是在 cBPF 上“打补丁”，而是一次彻底重构：

👉eBPF 是一个“安全的内核态虚拟机”。

五、eBPF 的历史演进

1. 1992–1997：BPF 的诞生

• 提出者：McCanne & Jacobson
• 背景：tcpdump 性能问题
• 目标：把过滤逻辑放进内核

👉 BPF = 高性能包过滤器

2. 2000–2010：BPF 的“沉寂期”

• 功能受限，无法扩展
• 仅作为抓包工具的底层实现

👉 BPF 一度被认为已经“走到头了”。

3. 2013–2014：eBPF 的诞生

• 关键人物：Alexei Starovoitov
• 决策：彻底重写 BPF 体系

引入：

• 64 位寄存器 VM
• 静态 Verifier
• JIT 编译
• BPF Map

👉这是 eBPF 的真正起点。

4. 2015–2016：Tracing 成为第一个杀手级应用

• kprobe / tracepoint 支持
• Brendan Gregg 推广 eBPF tracing

成果：

• execsnoop
• biolatency
• opensnoop

👉eBPF 首次在生产环境大规模落地。

5. 2016–2017：XDP 推动网络方向爆发

• 需求：高 PPS、DDoS 防护
• XDP：在驱动层运行 eBPF

效果：

• 百万 / 千万 PPS
• 极低延迟

👉eBPF 从“观察”走向“决策”。

6. 2018–2019：云原生时代的成熟

• 内核版本碎片化
• 引入 BTF + CO-RE

结果：

• 编译一次，到处运行
• 工程可用性大幅提升

7. 2020–至今：平台化与未来

• eBPF LSM（安全）
• Cilium、Falco 等项目
• 用户态 eBPF、硬件卸载

👉eBPF 已成为内核级基础设施。

六、一句话总结

BPF 是为“过滤包”而生，
eBPF 是被“内核可扩展性需求”逼出来的。

它的演进路径是：

包过滤 → 内核观察 → 路径加速 → 动态安全 → 内核插件平台