go无法直接在用户态实现网络层ddos过滤，因net包工作在socket层，数据包已穿透xdp→tc→ip栈→socket缓冲区，触发sk_buff分配、conntrack等开销；百万pps下go runtime会因系统调用与gc压力崩盘。
go 无法直接在用户态实现网络层 ddos 流量过滤；必须借助 ebpf 程序在内核侧完成高频包级决策，go 只负责控制面逻辑（加载、更新策略、读取统计）。
为什么不能只用 Go 写一个 net.ListenUDP + rate.Limit 就防 DDoS？
因为 Go 的 net 包工作在 socket 层，数据包早已穿过 XDP → TC → IP 栈 → socket 缓冲区。此时：
- 每个恶意 SYN/UDP 包都已触发内核内存分配（sk_buff）、协议解析、连接跟踪（conntrack）等开销；
- 即使 Go 立即 close()，资源泄漏和 CPU 消耗已发生；
- 在百万级 PPS 场景下，Go runtime 会因频繁系统调用和 GC 压力崩盘，根本来不及响应。
Go + eBPF 的真实分工：谁干啥、在哪干
典型分工如下：
- xdp_fw.c（C 编写）：挂载在网卡驱动入口，对每个原始帧做 XDP_DROP/XDP_PASS 判断，不进协议栈；
- goebpf 库（Go 编写）：调用 bpf_load_program() 加载 eBPF 字节码，通过 bpf_map_update_elem() 动态写入黑名单 IP 或速率阈值；
- 用户态 Go 程序：监听 Prometheus metrics 或本地 HTTP API，根据实时流量特征（如每秒新源 IP 数 >5000）自动更新 eBPF Map 中的限速规则。
关键陷阱：eBPF Map 类型选错直接导致丢包或策略失效
常见错误是把限速状态存在 BPF_MAP_TYPE_HASH，但没设足够大的 max_entries：
- 高频攻击下源 IP 碰撞率飙升，旧条目被覆盖，导致合法用户被误杀；
- 正确做法是用 BPF_MAP_TYPE_LRU_HASH，自动淘汰冷条目，且支持高并发更新；
- 若需跨 CPU 统计（如全局 QPS），必须用 BPF_MAP_TYPE_PERCPU_ARRAY + 用户态聚合，否则单 CPU 计数器会溢出；
- 所有 Map key 必须是固定长度（如 struct { __u32 src_ip; __u16 port; }），不能用变长字符串。
Go 加载 XDP 程序时最常遇到的失败原因
运行 go run main.go 后报错 invalid argument 或 permission denied，大概率是：
- 内核未启用 CONFIG_BPF_JIT=y（检查 /proc/sys/net/core/bpf_jit_enable 是否为 1）；
- 网卡不支持 XDP（ip link show dev eth0 中无 XDP 字样，需用 ixgbe、i40e、mlx5 等驱动）；
- Go 进程没 CAP_SYS_ADMIN 权限（用 sudo setcap cap_sys_admin+ep ./main 临时授权，生产环境应走 systemd capability 配置）；
- eBPF 程序里用了不支持的 helper 函数（如 bpf_trace_printk() 在生产 XDP 程序中禁止使用，会导致验证失败）。
真正难的不是写通第一个 XDP_DROP，而是让 eBPF 状态与 Go 控制逻辑在毫秒级抖动、CPU 调度切换、Map 并发更新下保持一致——这里没有“配置完就稳了”的环节，只有持续观测 xdp_stats 和内核日志里的 verifier trace。
