手把手教你用XDP和tc打造高性能Linux网络过滤器（附性能测试数据）

手把手教你用XDP和tc打造高性能Linux网络过滤器（附性能测试数据）

最近在优化一个高并发网关服务时，传统的iptables规则在应对每秒百万级数据包时显得力不从心，CPU使用率居高不下。这促使我开始探索Linux内核中更底层的网络数据面加速技术。经过一番折腾，我发现将XDP与tc结合，不仅能实现精细化的流量控制，更能将网络过滤性能提升一个数量级。这篇文章，我就把自己从环境搭建、代码编写到性能压测的完整实战经验分享出来，希望能帮你绕过我踩过的那些坑。

这篇文章主要面向已经熟悉Linux网络基础，并且对性能有极致追求的中高级开发者。无论是想构建自己的高性能防火墙、负载均衡器，还是想对特定流量进行毫秒级的整形与过滤，这套组合拳都能为你提供一个全新的、内核原生的高性能解决方案。我们不会停留在理论层面，而是会深入到代码和命令行，用实际数据说话。

1. 环境准备与内核配置

在开始编写任何代码之前，确保你的Linux内核版本和开发环境支持XDP和tc的高级功能是第一步。我推荐使用5.4及以上版本的内核，这个版本区间对XDP和tc（特别是clsactqdisc）的支持已经相当成熟和稳定。

1.1 内核编译选项检查

首先，你需要确认当前内核是否启用了必要的配置。最直接的方法是检查/boot/config-$(uname -r)文件或使用zcat /proc/config.gz（如果启用）。以下是几个关键的配置项：

# 检查XDP相关配置 grep -E "XDP|BPF" /boot/config-$(uname -r) | grep -E "=y|=m" # 检查 Traffic Control 及 eBPF 支持 grep -E "CLS_BPF|ACT_BPF|NET_CLS_BPF|NET_ACT_BPF|CGROUP_BPF" /boot/config-$(uname -r)

如果这些选项没有内置（=y）或编译为模块（=m），你可能需要重新编译内核。对于大多数主流发行版（如Ubuntu 20.04+， Fedora 33+），这些选项默认是开启的。

提示：如果你在云服务器上操作，部分厂商提供的镜像可能为了精简而关闭了某些BPF特性。这时，考虑更换为官方提供的“通用”或“HVM”镜像通常是更快捷的选择。

1.2 开发工具链安装

接下来，安装编译和开发所需的工具。这包括LLVM/Clang编译器（用于将C代码编译为eBPF字节码）、BPF工具链以及内核头文件。

# 对于 Ubuntu/Debian 系统 sudo apt update sudo apt install -y clang llvm libelf-dev libbpf-dev bpfcc-tools linux-headers-$(uname -r) gcc-multilib # 对于 Fedora/RHEL/CentOS 系统 sudo dnf install -y clang llvm elfutils-libelf-devel libbpf-devel kernel-headers kernel-devel

安装完成后，验证Clang版本（建议使用10.0或更高版本）：

clang --version | head -n 1

1.3 依赖库与示例代码获取

为了便于学习和测试，我强烈建议从Linux内核源码树中获取官方的BPF示例程序。这些示例是极佳的学习起点。

# 下载对应版本的内核源码（以5.15为例） wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.tar.xz tar -xf linux-5.15.tar.xz cd linux-5.15 # 关键的XDP示例位于以下目录 ls samples/bpf/ | grep xdp # 你会看到 xdp1_kern.c, xdp2_kern.c 等，它们对应的用户态程序是 xdp1_user.c, xdp2_user.c

这些示例程序已经包含了完整的Makefile，可以直接编译运行，是理解XDP程序结构的绝佳材料。

2. 理解XDP：内核网络的数据面“快车道”

在深入代码之前，我们需要厘清XDP在整个Linux网络栈中的位置。你可以把它想象成在网卡驱动刚刚收到数据包（RX队列）时，设立的一个最早决策点。此时，数据包还只是一块原始的缓冲区（sk_buff的前身），尚未分配复杂的元数据结构，也远未进入netfilter（iptables）和TCP/IP协议栈。

2.1 XDP的三种操作模式

XDP程序可以以三种模式加载，这决定了它的执行位置和性能上限：

对于我们今天的实践，会先从通用模式开始，因为它无需特殊硬件。在性能测试部分，则会切换到原生模式来展示其真正的威力。

2.2 你的第一个XDP程序：丢弃所有数据包

让我们从一个最简单的程序开始：丢弃所有到达指定网卡的数据包。这相当于一个最粗暴的防火墙。

首先，编写XDP内核态程序（.c文件）：

// drop_all_kern.c #include <linux/bpf.h> #include <bpf/bpf_helpers.h> SEC("xdp") int xdp_drop_all(struct xdp_md *ctx) { // XDP_DROP 表示直接丢弃数据包，释放其内存 return XDP_DROP; } char _license[] SEC("license") = "GPL";

这个程序定义了一个xdp类型的段（SEC("xdp")），其中只有一个函数xdp_drop_all。它接收一个上下文结构体xdp_md，然后直接返回XDP_DROP。

接下来，使用Clang将其编译为BPF字节码：

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

现在，我们需要一个用户态程序来将这个字节码加载到内核，并附着到网络接口上。这里我们可以使用iproute2工具包中的ip命令，它是最简单直接的方式。

# 将XDP程序加载到网络接口eth0（请替换为你的接口名） sudo ip link set dev eth0 xdp obj drop_all_kern.o sec xdp # 查看加载状态 sudo ip link show eth0

在接口信息中，你应该能看到类似xdp的标识。此时，所有发往eth0的流量都会被静默丢弃。你可以尝试ping这个接口的IP地址，会发现完全不通。

卸载这个XDP程序：

sudo ip link set dev eth0 xdp off

3. 深入tc：流量控制的瑞士军刀

如果说XDP是守门的“快刀”，那么tc就是负责院内交通管制的“精密仪器”。它主要在ingress（入栈前）和egress（出栈后）两个点对数据包进行排队、整形、过滤和重定向。我们这里重点关注其与BPF结合的强大过滤能力。

3.1 clsact qdisc：连接tc与BPF的桥梁

传统的ingressqdisc功能有限。而clsact是一个特殊的无队列qdisc，它专门为在ingress和egress钩子点进行分类和动作而设计，并且完美支持eBPF。

首先，为你的网卡添加clsactqdisc：

sudo tc qdisc add dev eth0 clsact

这个命令本身不会改变流量行为，它只是创建了一个可以挂载BPF分类器的锚点。

3.2 编写并挂载一个tc BPF过滤器

假设我们想实现一个功能：在数据包进入协议栈之前（ingress），丢弃所有目标端口为80的TCP流量（模拟简单的HTTP流量拦截）。

编写BPF程序：

// block_tcp80_kern.c #include <linux/bpf.h> #include <bpf/bpf_helpers.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/tcp.h> SEC("classifier") int cls_ingress(struct __sk_buff *skb) { void *data_end = (void *)(long)skb->data_end; void *data = (void *)(long)skb->data; struct ethhdr *eth = data; struct iphdr *ip; struct tcphdr *tcp; // 1. 检查数据包长度是否足以包含以太网头 if (data + sizeof(*eth) > data_end) return TC_ACT_OK; // 放过畸形包，让上层处理 // 2. 检查是否为IPv4 if (eth->h_proto != __constant_htons(ETH_P_IP)) return TC_ACT_OK; ip = data + sizeof(*eth); if ((void *)ip + sizeof(*ip) > data_end) return TC_ACT_OK; // 3. 检查是否为TCP协议 if (ip->protocol != IPPROTO_TCP) return TC_ACT_OK; tcp = (void *)ip + (ip->ihl * 4); if ((void *)tcp + sizeof(*tcp) > data_end) return TC_ACT_OK; // 4. 检查目标端口是否为80 if (tcp->dest == __constant_htons(80)) { // TC_ACT_SHOT 表示丢弃数据包 return TC_ACT_SHOT; } // 其他所有流量放行 return TC_ACT_OK; } char _license[] SEC("license") = "GPL";

编译它：

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

现在，将这个BPF程序作为分类器（filter）挂载到eth0的ingress路径上：

sudo tc filter add dev eth0 ingress bpf da obj block_tcp80_kern.o sec classifier

• ingress: 指定挂载方向。
• bpf da: 表示直接动作（Direct Action）模式，分类后立即执行返回的动作。
• sec classifier: 指定使用目标文件中SEC("classifier")段。

现在，任何发往该主机eth0接口TCP 80端口的流量都会被丢弃。你可以通过nc -l 80监听，然后从另一台机器尝试连接来验证。

查看已挂载的过滤器：

sudo tc filter show dev eth0 ingress

4. XDP与tc的协同作战实战

单独使用XDP或tc已经很强大了，但将它们组合起来，可以构建出更复杂、更高效的处理流水线。一个常见的模式是：XDP负责高性能、粗粒度的过滤和重定向（如DDoS缓解），而tc负责更复杂、需要协议栈信息的精细处理（如基于连接的限速）。

4.1 案例：构建一个两层流量清洗系统

设想一个场景：我们需要保护后端的Web服务器。

1. 第一层（XDP层）：在网卡驱动层，以线速丢弃明显的攻击流量，例如来自某个IP段的所有UDP包（模拟UDP Flood）。
2. 第二层（tc层）：对通过第一层的TCP流量，进行连接速率限制，防止CC攻击。

第一层 XDP程序 (udp_drop_kern.c):

#include <linux/bpf.h> #include <bpf/bpf_helpers.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/udp.h> SEC("xdp") int xdp_drop_udp_range(struct xdp_md *ctx) { void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct ethhdr *eth = data; struct iphdr *ip; if (data + sizeof(*eth) > data_end) return XDP_PASS; if (eth->h_proto != __constant_htons(ETH_P_IP)) return XDP_PASS; ip = data + sizeof(*eth); if ((void *)ip + sizeof(*ip) > data_end) return XDP_PASS; // 假设我们要丢弃源IP在 192.168.1.100 到 192.168.1.150 之间的UDP包 // 这里简化处理，只检查前两个字节和协议 if (ip->protocol == IPPROTO_UDP) { unsigned int src_ip = ntohl(ip->saddr); // 检查是否在目标IP段 (示例逻辑，需完善) if ((src_ip & 0xFFFFFF00) == 0xC0A80100) { // 192.168.1.0/24 // 更精确的范围判断应在BPF映射中配置，此处为示例 return XDP_DROP; } } return XDP_PASS; } char _license[] SEC("license") = "GPL";

加载到网卡（原生模式）：

sudo ip link set dev eth0 xdp obj udp_drop_kern.o sec xdp

第二层 tc BPF程序 (conn_limit_kern.c):这一层我们实现一个简化的连接计数器。在实际生产中，你会使用BPF映射（如LRU HashMap）来跟踪每个源IP的HTTP请求速率，这里为简化，我们仅展示框架。

#include <linux/bpf.h> #include <bpf/bpf_helpers.h> #include <linux/if_ether.h> #include <linux/ip.h> #include <linux/tcp.h> // 定义一个BPF映射来存储IP地址的请求计数（简化版） struct { __uint(type, BPF_MAP_TYPE_LRU_HASH); __uint(max_entries, 10240); __type(key, __u32); // 源IP地址 __type(value, __u64); // 时间窗口内的请求数 } ip_request_cnt SEC(".maps"); SEC("classifier") int cls_ingress_rate_limit(struct __sk_buff *skb) { // 解析IP和TCP头... // 查找 ip_request_cnt 映射，更新计数 // 如果单位时间内请求数超过阈值（如100次/秒），则返回 TC_ACT_SHOT // 否则，返回 TC_ACT_OK return TC_ACT_OK; } char _license[] SEC("license") = "GPL";

编译并挂载到tc ingress：

sudo tc filter replace dev eth0 ingress prio 1 bpf da obj conn_limit_kern.o sec classifier

这样，一个简单的两层过滤系统就搭建好了。XDP以极低的代价拦掉了大部分无效的UDP洪水，而tc则对漏过的TCP流量进行更智能的、基于状态的速率限制。

5. 性能测试与数据对比

理论再好，不如数据有说服力。我搭建了一个简单的测试环境：两台物理服务器，通过万兆网卡直连。

• 发送端：使用pktgen（内核自带的高性能发包工具）生成64字节小包，模拟压力流量。
• 接收端：运行我们的过滤程序，并监控CPU使用率和丢包率。

5.1 测试场景设计

我们对比四种情况：

1. 基线：不加载任何过滤程序，仅用pktgen接收并丢弃。
2. 传统netfilter：使用一条iptables -A INPUT -p udp -j DROP规则丢弃所有UDP包。
3. XDP丢弃：使用我们编写的udp_drop_kern.o程序（原生模式）。
4. tc BPF丢弃：使用clsact挂载一个功能类似的BPF程序丢弃UDP包。

5.2 测试方法与关键命令

在接收端启动pktgen：

# 加载pktgen内核模块 sudo modprobe pktgen # 这里省略了复杂的pktgen线程配置，通常通过 /proc/net/pktgen/ 接口进行

监控CPU使用率（重点关注软中断si或soft所在的CPU核心）：

# 使用 top 查看每个CPU核心的使用率，关注 %si top -1 -d 1 # 或使用 mpstat mpstat -P ALL 1

5.3 测试结果与分析

以下是在约2 Mpps（每秒百万包）流量冲击下得到的近似数据：

注意：具体数值因硬件、内核版本和配置而异，但数量级关系具有普遍参考意义。

结果解读：

1. XDP展现了压倒性的性能优势：在原生模式下，其性能损耗几乎可以忽略不计，CPU占用仅比基线高一点点。这是因为XDP程序在数据包进入DMA缓冲区后最早点执行，避免了内核网络栈的绝大部分开销。对于需要线速处理的场景（如DDoS防护），XDP是唯一的选择。
2. tc BPF是性能与功能的优秀平衡点：虽然性能不及XDP，但相比传统的netfilter，它带来了数倍的性能提升和大幅降低的CPU占用。更重要的是，clsact的ingress/egress钩子点仍然可以访问到比XDP更丰富的内核网络状态（尽管不如完整的协议栈），适合实现需要一些连接状态感知的、复杂的策略。
3. 传统netfilter成为瓶颈：在高包率场景下，iptables规则遍历带来的CPU开销非常可观，这直接导致了吞吐量下降和处理延迟飙升。对于高性能网关，将其核心数据面规则迁移到XDP/tc BPF，是架构优化的关键一步。

在实际项目中，我将一个网关的防火墙核心规则从iptables迁移到XDP+t组合后，在流量高峰期间，负责过滤的服务器CPU负载从平均70%降到了30%以下，并且完全消除了因防火墙处理不过来而导致的流量抖动。这个改造过程虽然需要深入理解BPF和内核网络，但带来的收益是实实在在的。

6. 调试、监控与生产化考量

将实验性的程序投入生产环境，还需要解决调试、监控和稳定性问题。

6.1 BPF程序的调试与跟踪

BPF程序的调试不如用户态程序直观。bpftool是你的瑞士军刀。

查看系统中已加载的所有BPF程序：

sudo bpftool prog list

获取某个特定程序的详细信息，包括运行时长、指令数和映射引用：

sudo bpftool prog show id <PROG_ID> --pretty

更强大的是，你可以获取BPF程序的JIT编译后的机器码（用于深度分析）：

sudo bpftool prog dump xlated id <PROG_ID> sudo bpftool prog dump jited id <PROG_ID>

对于tc挂载的BPF程序，还可以通过tc命令查看统计信息：

sudo tc -s filter show dev eth0 ingress

输出中会包含该过滤器匹配了多少数据包（direct packets）和字节数。

6.2 性能监控与火焰图

使用bpftool的profile命令可以对运行中的BPF程序进行CPU性能采样，生成火焰图，这是定位BPF程序内部热点函数的终极利器。

首先，安装perf和火焰图生成脚本：

git clone https://github.com/brendangregg/FlameGraph.git

然后，使用bpftool采集性能数据：

# 采样5秒钟 sudo bpftool prog profile id <PROG_ID> duration 5 cycles > out.stacks

最后，使用FlameGraph脚本生成SVG火焰图：

./FlameGraph/stackcollapse.pl < out.stacks | ./FlameGraph/flamegraph.pl > profile.svg

用浏览器打开profile.svg，你就可以清晰地看到BPF程序中哪些函数最耗CPU。

6.3 生产环境部署建议

1. 版本控制与CI/CD：将BPF C代码像普通应用代码一样纳入版本管理。编写自动化脚本，实现编译、加载、回滚的流水线。
2. 资源限制：使用ulimit和cgroup限制BPF程序的内存和CPU使用，防止有bug的程序耗尽系统资源。
3. 优雅降级：在加载XDP程序时，可以考虑先使用xdpdrv（原生模式），如果失败则自动降级为xdpgeneric（通用模式），确保服务可用性。

   # 脚本示例逻辑 if sudo ip link set dev eth0 xdpdrv obj my_prog.o 2>/dev/null; then echo "Loaded in native mode." else sudo ip link set dev eth0 xdpgeneric obj my_prog.o echo "Loaded in generic mode." fi

4. 监控告警：持续监控bpftool prog show中的run_time_ns和run_cnt，如果某个程序的运行次数异常激增或单次运行时间过长，可能意味着逻辑问题或攻击，应触发告警。

从实验到生产，最大的挑战往往不是技术本身，而是如何建立一套与之配套的运维体系。建议从小规模、非核心的业务流量开始灰度，逐步积累经验和信心。一旦跑顺，这套基于XDP和tc的高性能网络数据面，将成为你基础设施中坚实而高效的一层。