一、先搞懂两个词：控制平面 vs 数据平面

网络设备里的活儿，向来分两摊：

为啥要拆开？因为数据平面要的是"快"，控制平面要的是"准"。一个在毫秒级逐包处理，一个慢慢算策略、同步给数据平面。两者节奏不同，自然分而治之。

而 eBPF 最厉害的地方，恰恰是它直接进了数据平面——不是在外围喊口号，而是真的站到流水线边上，对每一个路过的包动手。

二、传统 Linux 网络栈：一条写死的流水线

Linux 的网络栈本质上是一条固定流水线：网卡收到包 → 驱动 → 协议栈 → 路由判断 → socket 分发。每一站该干啥，内核源码里写得明明白白。

问题来了：你想在中间插点自己的逻辑怎么办？比如"凡是访问 3306 端口的包，先记个日志再放行"。传统路子只有两条：

至于大家熟悉的 iptables / netfilter，它确实在数据平面上开了钩子，能挂规则。但它设计得偏"通用"，规则一多，逐条匹配的开销就上来了，在高吞吐场景下性能顶不住。于是工程师们常常陷入两难：要么改不动，要么改得起但跑不快。

三、eBPF 带来的变化：在流水线上插自己的工位

eBPF 的解法很巧妙：它不重写流水线，而是在流水线的关键位置开了"挂载点"。你写一段 eBPF 小程序，加载进去，它就会在数据包经过那个位置时自动执行——改包、丢包、转发、统计，随你。

打个比方：快递分拣线上，原本每个工位都是厂里焊死的。eBPF 相当于在几个关键工位旁边留了个"临时工位"，你随时能放一个自己的质检员上去，看看包、贴个标签、甚至拦下来。质检员（eBPF 程序）不用经过厂长审批（改内核），上岗下岗也不停流水线（不重启）。

而且这个"质检员"不是随便放的闲人——他得先通过验证器的体检（安全检查），保证不会把流水线搞崩，才能上岗。这就是 eBPF 既能灵活、又不出乱子的底气。

四、eBPF 在网络栈的关键挂载点

那这些"工位"具体在哪儿？eBPF 在 Linux 网络栈里主要开了这么几个挂载点，按数据包流向从早到晚排列：

注意这条路径的妙处：越靠前的挂载点，性能越高、能做的事越"粗"；越靠后，能拿到的上下文越丰富、能做的事越"细"，但开销也越大。比如 XDP 在驱动层，连 socket 信息都没有，但每秒能处理上千万包；到了 socket 层，你能知道是哪个进程在收发，但包已经走了一大段路。

所以选挂载点，本质是在"性能"和"信息丰富度"之间做权衡"。这也是后面几节我们会反复纠结的核心问题。

五、"可编程数据平面"到底香在哪？

把上面这些拼起来，eBPF 给网络带来的"可编程数据平面"，核心价值就三条：

再套回那个快递分拣的比喻：传统方式是"想加质检得停线改造，或者用厂里统一发的固定规则模板"；eBPF 是"随时能放自己的质检员，还不耽误分拣速度，连安保和统计都能让同一个质检员顺手干了"。