第3章：eBPF/XDP实战：在网卡驱动层过滤数据包，绕过内核协议栈

各位好，我是你们的网络协议栈讲师。今天咱们聊点硬核的——eBPF/XDP。

说实话，我在做网络优化之前，一直觉得内核协议栈挺完美的。直到有一次，我在一个金融交易系统里做延迟优化，发现数据包从网卡到应用层，光在内核里就转了七八个弯。我当时就想：能不能在数据包刚进网卡时，就直接把它干掉？

嗯，XDP（eXpress Data Path）就是干这个的。

3.1 为什么需要XDP？

先看一个典型的数据包路径：

网卡 → DMA → 内核协议栈（IP层 → TCP层 → socket） → 用户态应用

这条路径，延迟通常在5-10微秒。对于大部分业务来说，这完全够用。但如果你在做高频交易、游戏服务器、或者CDN边缘节点，这10微秒可能就是致命的。

我当年在优化一个实时竞价系统时，发现数据包在内核里排队、校验、重组，光TCP层就耗了3微秒。我当时就想：如果我只关心UDP包，或者只关心特定端口的包，能不能直接跳过这些步骤？

XDP的答案是：能。它在网卡驱动层，数据包刚被DMA到内存时，就让你有机会处理它。处理完，你可以选择：

• XDP_DROP：直接丢弃，内核都看不到这个包
• XDP_PASS：放行，交给内核协议栈
• XDP_TX：从原网卡发回去（比如用于防火墙）
• XDP_REDIRECT：重定向到其他网卡或用户态程序

说白了，XDP就是在网卡驱动和内核协议栈之间，插了一个可编程的过滤层。

3.2 eBPF + XDP：为什么是绝配？

XDP本身只是一个框架，它需要程序来定义过滤逻辑。而eBPF，就是那个写程序的语言。

你可能要问：为什么不用内核模块？

我刚开始也这么想。但后来发现，内核模块太危险了。你写个bug，整个系统就挂了。而且每次升级内核，模块还得重新编译。

eBPF不一样。它运行在沙箱环境里，有验证器检查你的代码是否安全。说白了，eBPF程序不会让内核崩溃，最多就是性能差一点。

而且，eBPF程序可以动态加载，不需要重启机器。我在生产环境里，经常是写个eBPF程序，直接挂到网卡上，几秒钟就生效了。

3.3 实战：用eBPF在网卡驱动层过滤数据包

好，咱们直接上代码。这个例子很简单：丢弃所有来自特定IP的UDP包。

3.3.1 环境准备

你需要：

• Linux内核版本 >= 4.8（推荐5.x以上）
• 安装 clang、llvm、libbpf-dev
• 网卡支持XDP（大部分现代网卡都支持）

我个人习惯用Ubuntu 22.04，内核5.15，直接apt安装就行。

3.3.2 编写eBPF程序

创建一个文件 drop_udp.c：

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_drop_udp(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    // 只处理IPv4
    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = data + sizeof(*eth);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    // 只处理UDP
    if (ip->protocol != IPPROTO_UDP)
        return XDP_PASS;

    // 检查源IP是否为192.168.1.100
    if (ip->saddr == __constant_htonl(0xC0A80164)) // 192.168.1.100
        return XDP_DROP;

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

这段代码的逻辑很简单：

1. 先检查以太网帧头，确保是IPv4
2. 再检查IP头，确保是UDP协议
3. 最后检查源IP，如果是192.168.1.100，直接丢弃

注意，这里有个边界检查。我在项目中遇到过，有人忘了检查 data_end，结果eBPF验证器直接拒绝加载。嗯，验证器很严格，这是好事。

3.3.3 编译和加载

编译命令：

clang -O2 -target bpf -c drop_udp.c -o drop_udp.o

加载到网卡（假设网卡名为 eth0）：

ip link set dev eth0 xdp obj drop_udp.o sec xdp

就这么简单。现在所有来自192.168.1.100的UDP包，在网卡驱动层就被丢弃了。内核根本看不到它们。

我曾经在压测环境里试过，延迟从5微秒降到了0.5微秒。当然，这取决于你的过滤逻辑复杂度。

3.3.4 卸载XDP程序

想恢复原状？

ip link set dev eth0 xdp off

嗯，就是这么干净。

3.4 性能对比：XDP vs 传统内核协议栈

我整理了一个简单的对比表：

场景	传统内核协议栈	XDP（eBPF）
数据包处理延迟	5-10微秒	0.5-2微秒
CPU占用	高（中断+上下文切换）	低（轮询模式）
灵活性	固定协议栈	可编程过滤
安全性	内核原生，稳定	沙箱验证，安全
部署难度	无需额外操作	需加载eBPF程序

你看，XDP在延迟和CPU占用上优势明显。但代价是：你只能处理原始数据包，不能使用内核的TCP状态机、路由表等高级功能。

所以，XDP最适合的场景是：

• DDoS防护：在网卡层直接丢弃攻击流量
• 负载均衡：快速重定向数据包到不同后端
• 自定义协议：比如你只关心UDP，不需要TCP

3.5 避坑指南

我在项目中踩过不少坑，分享几个给你：

3.6 本章小结

XDP + eBPF，说白了就是让你在网卡驱动层，用安全的方式写自定义的包处理逻辑。它绕过了内核协议栈，延迟能降低一个数量级。

但要注意，它不是万能的。如果你需要TCP的可靠传输、路由查找、或者复杂的连接跟踪，还是得走内核协议栈。

我个人建议：先用XDP做粗粒度的过滤，剩下的交给内核。这样既降低了延迟，又保留了协议栈的完整性。

---