eBPF 与 XDP：把逻辑塞进内核路径

一句话：让内核可编程

改内核行为的传统办法只有两条：改内核源码重编译，或者写内核模块。 前者不现实，后者一崩就是整机宕。

eBPF 提供了第三条路：把一小段程序加载进内核、挂在某个钩子上， 由验证器保证它不会崩、不会死循环。

L1 讲的 Cilium、L1 的 kube-proxy 替换、下面要讲的 XDP，底层都是它。

三个组成部分

程序（program）  挂在某个钩子上，事件触发时执行
map              内核与用户态之间共享数据的地方（哈希表、数组、LRU…）
验证器（verifier）加载时静态分析：有界循环、内存访问合法、指令数上限

map 是理解 eBPF 的关键：程序本身不能随意分配内存、不能保存状态， 所有需要"记住"的东西都放在 map 里，用户态程序通过 map 读写它。

# 系统里加载了哪些 eBPF 程序
bpftool prog show
# 有哪些 map
bpftool map show
# dump 某个 map 的内容
bpftool map dump id 42

网络路径上的钩子

按包在路径上出现的先后：

网卡 → [XDP] → 驱动 → [tc ingress] → 协议栈 → [socket ops] → 应用
                                                     ↑
应用 → [cgroup/sock] → 协议栈 → [tc egress] → 驱动 → 网卡

位置越早越快，但可用信息越少——这是选钩子的核心取舍。

XDP：为什么能做到线速

XDP 的程序在驱动收到包、还没分配 sk_buff 之前就执行。省掉的正是最贵的那一步：

常规路径：  DMA → 分配 skb → 协议栈 → netfilter → 判断丢弃
XDP：      DMA → eBPF 判断 → 丢弃        ← skb 都没建

sk_buff 的分配与初始化在小包场景下是主要开销之一。跳过它， 丢包能力可以接近线速——这就是 XDP 被用来扛 DDoS 的原因。

XDP 程序返回一个动作：

三种运行模式

# 看网卡挂了什么 XDP 程序、什么模式
ip link show dev bond0 | grep -o 'xdp.*'
bpftool net show

# 加载与卸载
ip link set dev bond0 xdp obj filter.o sec xdp
ip link set dev bond0 xdp off

ip -d link show dev bond0 | grep -E 'xdp|prog'

典型应用

① DDoS 过滤

在 XDP 层按源 IP、包特征直接丢弃，在协议栈之前：

攻击流量 → 网卡 → XDP 判断 → XDP_DROP
                              ↑ CPU 只花了极小代价
正常流量 → XDP_PASS → 协议栈 → 应用

对比 iptables：iptables 在 netfilter 里过滤，此时 skb 已建、 已经过了一部分协议栈处理，代价高一个量级。

② 负载均衡

XDP_TX / XDP_REDIRECT 可以在网卡层做四层转发，不进协议栈。 大型互联网公司的四层 LB 很多是这么实现的。

③ 容器网络数据平面

Cilium 用 tc 和 socket 钩子替换掉 iptables 与 conntrack （kube-proxy 那节 讲过）。收益不只是快：

• 查找是哈希 map，不随 Service 数线性退化
• socket 层改地址，整条路径不需要 conntrack
• 策略基于身份而不是 IP

④ 可观测性

这是 eBPF 影响最广的一类用途：在不改应用、不重启服务的前提下拿到内核视角的数据。

# 常用工具（bcc / bpftrace）
tcplife            # 每条 TCP 连接的生命周期与字节数
tcpretrans         # 实时看重传发生在哪条连接
tcpconnlat         # 连接建立延迟分布
execsnoop          # 谁在起进程

# bpftrace 单行：统计 TCP 重传的目标地址
bpftrace -e 'kprobe:tcp_retransmit_skb { @[ntop(arg0)] = count(); }'

L0 讲的那套计数器告诉你"有多少重传"，eBPF 工具能告诉你**"是哪条连接、什么时候、为什么"**。

eBPF / XDP / DPDK 怎么选

三者常被放在一起比，但定位完全不同：

选择顺序建议：先看 eBPF/XDP 能不能满足——因为它们不夺走网卡、 不破坏现有工具链。只有确认过不去才上 DPDK。

调试手段

eBPF 程序在内核里跑，不能用常规调试器：

# 程序里 bpf_printk() 的输出
cat /sys/kernel/debug/tracing/trace_pipe

# 程序与 map 的状态
bpftool prog show
bpftool prog dump xlated id 42      # 看验证器处理后的指令
bpftool map dump name my_map

# Cilium 场景的高层视角
cilium-dbg monitor --type drop
cilium-dbg bpf lb list

bpftool prog dump xlated 在排查"为什么验证器拒绝"时特别有用—— 它显示的是内核实际看到的指令序列。

检查点

这节课的落点

• eBPF 让内核可编程，验证器保证不崩不死循环——这是它相对内核模块的根本差异
• 三部分：程序、map（所有状态都放这里）、验证器
• 网络钩子按位置：XDP（最早最快）→ tc（功能最全）→ socket/cgroup（改地址、按 cgroup 策略）
• XDP 快在还没分配 sk_buff；五个返回动作里 XDP_DROP 是 DDoS 防护核心
• generic 模式的性能数据没有参考价值，测试前先确认不是 xdpgeneric
• 四类应用：DDoS 过滤、四层 LB、容器网络数据平面、可观测性
• 可观测性是影响最广的一类：不改应用就能拿到"哪条连接在重传"这种内核视角
• 选型顺序：先 eBPF/XDP，确认不够再上 DPDK——后者会独占网卡并让常规工具失效