为什么 10G 大带宽也怕小包？

很多同行选大带宽服务器时只看带宽数字，以为 10G 就能硬扛 DDoS。但 64 字节小包下，10G 线速是 14.88 Mpps。如果内核协议栈处理不过来，带宽再大也白搭。默认 netfilter 在软中断里逐包匹配，单核跑到 1.5 Mpps 就差不多到顶了，SYN Flood 一来，CPU 全部耗在 ksoftirqd 上，业务直接失联。

测试环境与方法

本次对比使用轻云互联的 10G 不限流量大带宽服务器，配置：Xeon Gold 6248R、64G DDR4、Mellanox ConnectX-4 Lx 双口 10G、CentOS 8、kernel 5.15。打流工具用 TRex，构造 64 字节 SYN Flood，目标端口 80，目的 MAC 为服务器网卡。

# 确认网卡多队列
ethtool -l eth0
# 开启多队列 RSS
ethtool -L eth0 combined 8
# 查看中断分布
cat /proc/interrupts | grep eth0

Baseline：netfilter 到底能扛多少？

先看传统方案。在 nftables 里加一条简单规则，丢弃 SYN：

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0\; }
nft add rule inet filter input tcp flags syn drop

TRex 打到 1.5 Mpps 时，ksoftirqd 已经占满 4 个核心，丢包率开始上升。2 Mpps 时 SSH 无法响应。结论：netfilter 适合做策略，不适合做线速 DDoS 清洗。

方案一：XDP eBPF 驱动层丢弃

XDP 在网卡驱动收包点执行，早于协议栈分配 skb，所以性能极高。写一个最简单的 SYN 丢弃程序：

// xdp_synflood.c
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_synflood_prog(struct xdp_md *ctx) {
    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    struct ethhdr *eth = data;
    if (data + sizeof(*eth) > data_end) return XDP_PASS;
    if (eth->h_proto != htons(ETH_P_IP)) return XDP_PASS;
    struct iphdr *ip = data + sizeof(*eth);
    if (data + sizeof(*eth) + sizeof(*ip) > data_end) return XDP_PASS;
    if (ip->protocol != IPPROTO_TCP) return XDP_PASS;
    struct tcphdr *tcp = (void *)ip + sizeof(*ip);
    if (data + sizeof(*eth) + sizeof(*ip) + sizeof(*tcp) > data_end) return XDP_PASS;
    if (tcp->syn && !tcp->ack) return XDP_DROP;
    return XDP_PASS;
}
char _license[] SEC("license") = "GPL";

编译与加载：

clang -O2 -g -target bpf -c xdp_synflood.c -o xdp_synflood.o
ip link set dev eth0 xdp obj xdp_synflood.o sec xdp
# 查看是否加载
ip link show eth0 | grep xdp

测试数据：单队列 XDP 在 3.0 GHz 核心上可处理约 10 Mpps，CPU 占用 60%。开启 8 队列 RSS 后，整机 14 Mpps 线速无压力，业务延迟无明显抖动。如果配合 bpftool 动态更新黑名单 map，还能实现秒级封禁。

方案二：DPDK 用户态轮询

DPDK 完全绕过内核，独占网卡。先绑定网卡到 vfio-pci，再跑 l2fwd 测试转发/丢弃性能。

# 配置大页
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
# 绑定网卡
modprobe vfio-pci
./dpdk-devbind.py --bind=vfio-pci 0000:01:00.0
# 启动 l2fwd，4 核
./l2fwd -l 0-3 -n 4 -- -p 0x1

测试数据：4 个核跑满 14.88 Mpps，每核约 3.7 Mpps，CPU 100%。延迟比 XDP 略高，且网卡被独占，SSH 和业务无法使用同一张卡。适合专用清洗设备，不适合大带宽服务器上跑业务的同时做清洗。

方案三：SmartNIC 卸载

如果网卡支持 XDP offload，可以把 eBPF 程序直接卸载到网卡。以 NVIDIA BlueField-2 为例：

ip link set dev eth0 xdp obj xdp_synflood.o sec xdp offload

测试数据：CPU 占用几乎为 0，吞吐保持 14.88 Mpps。但硬件成本高，且需要网卡固件和驱动支持。对于大多数业务，XDP native 模式已经够用。

三种方案横向对比

• 吞吐/PPS：DPDK ≈ SmartNIC > XDP native > netfilter
• CPU 占用：SmartNIC 最低，XDP 次之，DPDK 最高
• 部署复杂度：XDP 最简单，DPDK 复杂，SmartNIC 依赖硬件
• 与业务共存：XDP 可在同一网卡上共存，DPDK 独占，SmartNIC 可共存
• 成本：XDP 零成本，DPDK 需要独占核心，SmartNIC 硬件成本高

真实案例：800 万 PPS SYN Flood 的处置

某游戏服在轻云互联 10G 大带宽服务器上被 SYN Flood 打到 800 万 PPS。默认内核下 ksoftirqd 占满所有核心，SSH 卡死。我们加载 XDP 程序后，流量在驱动层被丢弃，CPU 从 100% 降到 15%，业务恢复正常。注意：如果攻击流量超过网卡线速（比如 15 Mpps 以上），XDP 也无力回天，这时必须靠上游清洗中心引流。

结论：大带宽服务器只是起点

大带宽服务器提供了吞吐上限，但 DDoS 防护的瓶颈往往在 PPS 和软中断。netfilter 适合策略，XDP 是性价比最高的本地清洗方案，DPDK 适合专用设备，SmartNIC 是未来方向。如果你的业务需要大带宽且希望本地具备 L3/L4 清洗能力，轻云互联的 10G 大带宽服务器配合 XDP 是一个值得考虑的起点。但记住：任何本地清洗都有上限，真正的 DDoS 防护是分层架构。