标签： 软中断

传统 iptables/Netfilter 在千万级 PPS 场景下必然成为软中断杀手，协议栈过深的遍历路径是高并发网关的性能毒药。本文直接给出基于 eBPF/XDP 的网络防刷与加速方案，在网卡驱动层（甚至硬件卸载）直接丢弃恶意包，将 CPU si 开销降低 80%，并结合 tracepoint:skb:kfree_skb 彻底终结内核丢包“黑盒”排查。

案发现场：Netfilter 成为性能瓶颈

某次生产环境流量突增，某业务 Ingress 网关（Ubuntu 22.04, Kernel 5.15.0-88-generic）QPS 并没有成倍放大，但 P99 延迟直接从 20ms 飙升到了 500ms，部分节点甚至出现 SSH 登录卡顿。

第一反应看负载，直接上 mpstat -P ALL 1，发现网卡队列绑定的几个 CPU 核心 si（SoftIRQ）直接被打满到了 100%。

抓取热点函数 perf top -a，霸榜的调用链异常清晰：

  18.52%  [kernel]  [k] nf_hook_slow
  15.21%  [kernel]  [k] ip_rcv
  12.33%  [kernel]  [k] kmem_cache_alloc
  10.14%  [kernel]  [k] __netif_receive_skb_core

典型的 CC 攻击/恶意扫段特征。大量无效的小包涌入，虽然在 iptables/Netfilter 层面配置了 DROP 规则，但由于 iptables 挂载在 PREROUTING 等 Hook 点，数据包走到这里时，内核已经为每一个包分配了 sk_buff 结构体，并走完了复杂的 L2 和 L3 早期协议栈处理。

在动辄几百万 PPS 的冲击下，频繁的 kmem_cache_alloc 和 Netfilter 规则链遍历直接榨干了 CPU。我们需要在更底层“掐断”这些流量。

为什么 XDP 能在千万级 PPS 下实现防刷降级？

常规的数据包接收路径是：网卡 -> DMA 拷贝到 Ring Buffer -> 触发硬中断 -> NAPI 轮询拉取 -> 分配 sk_buff -> __netif_receive_skb_core -> 网络协议栈 (Netfilter/IP/TCP 等)。

XDP（eXpress Data Path）之所以快，根本原因在于它的 Hook 点位于 网络驱动层分配 sk_buff 之前。 当网卡通过 DMA 将数据放入内存后，XDP BPF 程序直接读取这段连续的原始内存（xdp_md），如果是恶意包，直接返回 XDP_DROP，网卡驱动会原地回收页面。没有 skb 内存分配，没有协议栈解析，没有上下文切换。

XDP 黑名单拦截实战代码

我们使用 BPF Map 来维护一个高频攻击 IP 黑名单，在 XDP 层直接匹配并丢弃。 以下是精简后的核心 C 代码（xdp_drop.c）：

#include <linux/bpf.h>
#include <linux/in.h>
#include <linux/if_ether.h>
#include <linux/if_packet.h>
#include <linux/if_vlan.h>
#include <linux/ip.h>
#include <bpf/bpf_helpers.h>

// 定义一个 BPF Hash Map 存储黑名单 IP
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 10000);
    __type(key, __u32);   // IPv4 Address
    __type(value, __u32); // Drop counter
} blacklist SEC(".maps");

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

    // 边界检查（必须，否则 eBPF 验证器会拒绝加载）
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

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

    __u32 src_ip = iph->saddr;

    // 查询黑名单 Map
    __u32 *value = bpf_map_lookup_elem(&blacklist, &src_ip);
    if (value) {
        __sync_fetch_and_add(value, 1); // 原子递增拦截计数
        return XDP_DROP; // 核心：在驱动层直接丢弃
    }

    return XDP_PASS;
}

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

编译与挂载：

# 使用 clang 编译成 BPF 字节码
clang -O2 -target bpf -c xdp_drop.c -o xdp_drop.o

# 将 XDP 程序挂载到网卡 eth0 (推荐 Native 模式，如果网卡驱动支持)
ip link set dev eth0 xdp obj xdp_drop.o sec xdp

# 查看挂载状态
ip link show eth0
# 输出会包含: prog/xdp id 123 tag xxxxxxx

此时再用 bpftool map 动态向 blacklist 中写入恶意 IP，被拦截的流量完全不会在 CPU si 中泛起波澜，系统 Load 瞬间恢复。

丢包排查：用 bpftrace 追踪 kfree_skb 黑盒

在上述流量清洗的过程中，常会遇到业务方反馈：“我的包明明发过去了，为什么网关没收到？”。此时，如果是协议栈内部某处静默丢包（如 MTU 不匹配、TCP 状态机异常、连接跟踪满），用 tcpdump 是看不出所以然的。

内核丢弃数据包最终都会调用 kfree_skb 或 consume_skb（正常释放）。利用 eBPF 追踪 kfree_skb 是降维打击。

在 Kernel 5.15 下，可以直接使用 bpftrace 一行命令定位丢包的确切内核调用栈：

# 捕获 10 秒内所有因非正常原因丢包的内核栈并统计次数
bpftrace -e '
tracepoint:skb:kfree_skb {
    // args->reason 在 5.1x 较新内核引入，可直接区分丢包原因
    @[kstack] = count();
}
'

如果你的内核支持 skb_drop_reason（Kernel 5.17+ 完善），甚至可以直接打印出人类可读的丢包枚举值。 在我们的排查过程中，通过上述命令输出了如下聚合栈：

@[
    kfree_skb+1
    tcp_v4_rcv+1452
    ip_protocol_deliver_rcu+54
    ip_local_deliver_finish+108
    __netif_receive_skb_one_core+138
    process_backlog+164
    __napi_poll+42
    net_rx_action+582
]: 2450

一针见血，包是在 tcp_v4_rcv 中被丢弃的。结合代码和偏移量，立刻定位到是处于 TIME_WAIT 状态的 socket 堆积，导致 PAWS（Protect Against Wrapped Sequence numbers）校验失败，触发了静默丢包。调整 net.ipv4.tcp_tw_reuse 和时间戳设置后，问题迎刃而解。没有 eBPF，这个问题在海量流量下排查至少需要拔几根头发。

常见问题 (FAQ)

Q1：XDP 有 Native 和 Generic 两种模式，性能差异多大？ Native 模式下，XDP BPF 代码直接嵌入在网卡驱动的 NAPI poll 循环中执行，性能极高（线速丢包可达 10M~20M PPS）。而 Generic 模式（xdpgeneric）是作为回退方案，挂载在 sk_buff 分配之后、协议栈处理之前，性能大打折扣，失去了 XDP “零分配”的核心优势。实战中，如果网卡驱动（如 ixgbe, i40e, mlx5）支持，务必使用 Native 模式（xdpdrv）。

Q2：加载 XDP 字节码时报错 bpf verifier errors，提示越界访问，怎么解决？ eBPF 内核验证器（Verifier）极其严格，采用“防御性加载”策略。如果你在 C 代码中解析 IP 头部，但没有在使用指针前做边界检查（例如 if ((void *)(iph + 1) > data_end) return XDP_PASS;），验证器会认为该程序可能引发 Kernel Panic 并拒绝加载。必须为每一次网络包头部偏移读取增加严格的 data_end 边界校验。

Q3：网关已经部署了 Cilium (基于 eBPF/XDP)，我自己挂载的 XDP 会冲突吗？ 会冲突。一个网卡的 RX 队列在同一时间点通常只能挂载一个 XDP 程序。如果强制挂载，后者的会覆盖前者，导致 Cilium 的网络路由与策略失效。在较新的内核中可以使用 libxdp 提供的多程序链（Multi-prog dispatcher）机制，将多个 XDP 程序按优先级串联（如将你的防刷 XDP 作为优先级最高的程序执行，如果 XDP_PASS，再交由 Cilium 的 XDP 程序处理）。

Q4：为什么不用 TC (Traffic Control) BPF 做拦截？ TC BPF 也是极好的网络控制点（支持 Ingress 和 Egress 双向），且能获取完整的 skb 上下文，功能比 XDP 更丰富（比如修改包长、克隆重定向）。但 TC Hook 点位于 skb 分配之后。如果你的首要目标是应对 L3/L4 层的洪水攻击或极限压榨 CPU 性能，选 XDP；如果是做复杂的流量整形、七层之前的深度负载均衡，选 TC。