eBPF 全称extended Berkeley Packet Filter扩展的伯克利包过滤器一、什么是 eBPFeBPFextended 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 的初心在不修改内核、不写内核模块的前提下安全地、动态地、以极低开销在内核中执行用户逻辑。它解决问题的方式主要体现在三点用户态编写程序内核负责安全验证程序可以动态加载和卸载不需要重启逻辑运行在关键路径上性能极高因此eBPF 常被称为Linux 内核的“插件系统”四、BPF 和 eBPF 有什么区别1. 先有 BPFClassic BPFBPF 最早诞生于 1990 年代目标非常单一高效过滤网络包tcpdump / libpcap特点指令集极其简单只能访问包数据无状态、无循环仅用于网络过滤它本质上是一个内核里的规则匹配引擎。2. eBPF借了名字换了灵魂eBPFextended BPF并不是在 cBPF 上“打补丁”而是一次彻底重构对比项cBPFeBPF使用范围网络包过滤整个内核计算能力极弱通用受限计算状态无Map 支持状态JIT部分完整安全模型简单静态 VerifiereBPF 是一个“安全的内核态虚拟机”。五、eBPF 的历史演进1. 1992–1997BPF 的诞生提出者McCanne Jacobson背景tcpdump 性能问题目标把过滤逻辑放进内核 BPF 高性能包过滤器2. 2000–2010BPF 的“沉寂期”功能受限无法扩展仅作为抓包工具的底层实现 BPF 一度被认为已经“走到头了”。3. 2013–2014eBPF 的诞生关键人物Alexei Starovoitov决策彻底重写 BPF 体系引入64 位寄存器 VM静态 VerifierJIT 编译BPF Map这是 eBPF 的真正起点。4. 2015–2016Tracing 成为第一个杀手级应用kprobe / tracepoint 支持Brendan Gregg 推广 eBPF tracing成果execsnoopbiolatencyopensnoopeBPF 首次在生产环境大规模落地。5. 2016–2017XDP 推动网络方向爆发需求高 PPS、DDoS 防护XDP在驱动层运行 eBPF效果百万 / 千万 PPS极低延迟eBPF 从“观察”走向“决策”。6. 2018–2019云原生时代的成熟内核版本碎片化引入 BTF CO-RE结果编译一次到处运行工程可用性大幅提升7. 2020–至今平台化与未来eBPF LSM安全Cilium、Falco 等项目用户态 eBPF、硬件卸载eBPF 已成为内核级基础设施。六、一句话总结BPF 是为“过滤包”而生eBPF 是被“内核可扩展性需求”逼出来的。它的演进路径是包过滤 → 内核观察 → 路径加速 → 动态安全 → 内核插件平台
从零入门：eBPF 是什么、解决什么问题以及它的历史
eBPF 全称extended Berkeley Packet Filter扩展的伯克利包过滤器一、什么是 eBPFeBPFextended 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 的初心在不修改内核、不写内核模块的前提下安全地、动态地、以极低开销在内核中执行用户逻辑。它解决问题的方式主要体现在三点用户态编写程序内核负责安全验证程序可以动态加载和卸载不需要重启逻辑运行在关键路径上性能极高因此eBPF 常被称为Linux 内核的“插件系统”四、BPF 和 eBPF 有什么区别1. 先有 BPFClassic BPFBPF 最早诞生于 1990 年代目标非常单一高效过滤网络包tcpdump / libpcap特点指令集极其简单只能访问包数据无状态、无循环仅用于网络过滤它本质上是一个内核里的规则匹配引擎。2. eBPF借了名字换了灵魂eBPFextended BPF并不是在 cBPF 上“打补丁”而是一次彻底重构对比项cBPFeBPF使用范围网络包过滤整个内核计算能力极弱通用受限计算状态无Map 支持状态JIT部分完整安全模型简单静态 VerifiereBPF 是一个“安全的内核态虚拟机”。五、eBPF 的历史演进1. 1992–1997BPF 的诞生提出者McCanne Jacobson背景tcpdump 性能问题目标把过滤逻辑放进内核 BPF 高性能包过滤器2. 2000–2010BPF 的“沉寂期”功能受限无法扩展仅作为抓包工具的底层实现 BPF 一度被认为已经“走到头了”。3. 2013–2014eBPF 的诞生关键人物Alexei Starovoitov决策彻底重写 BPF 体系引入64 位寄存器 VM静态 VerifierJIT 编译BPF Map这是 eBPF 的真正起点。4. 2015–2016Tracing 成为第一个杀手级应用kprobe / tracepoint 支持Brendan Gregg 推广 eBPF tracing成果execsnoopbiolatencyopensnoopeBPF 首次在生产环境大规模落地。5. 2016–2017XDP 推动网络方向爆发需求高 PPS、DDoS 防护XDP在驱动层运行 eBPF效果百万 / 千万 PPS极低延迟eBPF 从“观察”走向“决策”。6. 2018–2019云原生时代的成熟内核版本碎片化引入 BTF CO-RE结果编译一次到处运行工程可用性大幅提升7. 2020–至今平台化与未来eBPF LSM安全Cilium、Falco 等项目用户态 eBPF、硬件卸载eBPF 已成为内核级基础设施。六、一句话总结BPF 是为“过滤包”而生eBPF 是被“内核可扩展性需求”逼出来的。它的演进路径是包过滤 → 内核观察 → 路径加速 → 动态安全 → 内核插件平台