1. eBPF tc prog 技术概览
eBPF（extended Berkeley Packet Filter）是一种革命性的内核技术，它允许用户在不修改内核源码或加载内核模块的情况下，安全高效地运行沙盒程序。而tc（Traffic Control）则是Linux内核中用于流量控制的子系统。当这两者结合，就形成了eBPF tc prog——一种在Linux网络栈中实现高性能、可编程流量处理的强大工具。
在实际网络工程中，eBPF tc prog最常见的应用场景包括：
- 高性能网络数据包过滤（替代传统iptables规则）
- 精细化QoS策略实施（如基于应用层的流量分类）
- 自定义流量统计与监控（如特定协议的数据包计数）
- 低延迟网络功能实现（如负载均衡、DDoS防护）
注意：eBPF程序需要内核版本4.1+才能获得完整支持，建议使用5.x以上内核以获得最佳特性支持
2. tc子系统的eBPF钩子解析
2.1 tc的eBPF挂载点
在tc子系统中，eBPF程序主要通过以下挂载点介入网络数据处理流程：
ingress（入口）：处理进入网卡的流量
- 典型应用：入口流量过滤、限速
- 挂载命令示例：
tc qdisc add dev eth0 clsact tc filter add dev eth0 ingress bpf da obj my_prog.o sec ingress
egress（出口）：处理从网卡发出的流量
- 典型应用：出口流量整形、QoS标记
- 挂载命令示例：
tc filter add dev eth0 egress bpf da obj my_prog.o sec egress
2.2 eBPF程序类型选择
针对tc场景，常用的eBPF程序类型包括：
| 程序类型 | 描述 | 适用场景 |
|---|---|---|
| BPF_PROG_TYPE_SCHED_CLS | 分类器程序 | 流量分类、过滤 |
| BPF_PROG_TYPE_SCHED_ACT | 动作程序 | 流量修改（如重定向、丢弃） |
3. 开发eBPF tc prog的完整流程
3.1 开发环境准备
推荐使用以下工具链：
# 必备工具 sudo apt install build-essential clang llvm libelf-dev libbpf-dev bpftool # 可选调试工具 sudo apt install bcc-tools linux-tools-$(uname -r)内核配置检查（/boot/config-*）：
CONFIG_BPF=y CONFIG_BPF_SYSCALL=y CONFIG_NET_CLS_BPF=y CONFIG_NET_ACT_BPF=y CONFIG_BPF_JIT=y3.2 eBPF程序编写示例
以下是一个简单的流量计数器实现（counter.c）：
#include <linux/bpf.h> #include <linux/if_ether.h> #include <linux/ip.h> #define SEC(NAME) __attribute__((section(NAME), used)) struct bpf_map_def SEC("maps") counter_map = { .type = BPF_MAP_TYPE_PERCPU_ARRAY, .key_size = sizeof(u32), .value_size = sizeof(u64), .max_entries = 1, }; SEC("ingress") int count_packets(struct __sk_buff *skb) { u32 key = 0; u64 *value, init_val = 1; value = bpf_map_lookup_elem(&counter_map, &key); if (value) { *value += 1; } else { bpf_map_update_elem(&counter_map, &key, &init_val, BPF_ANY); } return TC_ACT_OK; } char __license[] SEC("license") = "GPL";编译命令：
clang -O2 -target bpf -c counter.c -o counter.o3.3 加载与验证
加载到内核：
# 添加clsact qdisc sudo tc qdisc add dev eth0 clsact # 加载ingress程序 sudo tc filter add dev eth0 ingress bpf da obj counter.o sec ingress # 查看加载状态 sudo tc filter show dev eth0 ingress读取统计信息：
# 使用bpftool查看map内容 sudo bpftool map list sudo bpftool map dump id <MAP_ID>4. 生产环境实践要点
4.1 性能优化技巧
map选择策略：
- 高频更新：使用PERCPU_ARRAY/HASH（避免锁竞争）
- 大容量存储：使用HASH而非ARRAY
- 原子操作：使用__sync_fetch_and_add等内置函数
尾调用（Tail Call）：
struct bpf_map_def SEC("maps") prog_map = { .type = BPF_MAP_TYPE_PROG_ARRAY, .key_size = sizeof(u32), .value_size = sizeof(u32), .max_entries = 10, }; SEC("ingress/sub") int handle_http(struct __sk_buff *skb) { // HTTP处理逻辑 return TC_ACT_OK; } SEC("ingress/main") int classifier(struct __sk_buff *skb) { if (is_http(skb)) { bpf_tail_call(skb, &prog_map, HTTP_PROG_IDX); } return TC_ACT_OK; }
4.2 常见问题排查
验证失败（Verifier Reject）：
- 检查是否有未初始化的指针访问
- 确保所有循环都有可验证的退出条件
- 使用
bpftool prog dump xlated id <PROG_ID>查看验证器日志
性能下降：
# 查看eBPF程序运行时间 sudo bpftool prog tracelog # 检查是否有频繁的map更新冲突 sudo cat /sys/kernel/debug/tracing/trace_pipe兼容性问题：
- 内核版本差异：4.x与5.x的eBPF特性支持不同
- 架构差异：确保使用正确的目标架构编译（如-march=native）
5. 高级应用场景
5.1 与XDP的协同工作
eBPF tc prog可以与XDP程序形成处理流水线：
XDP (驱动层) -> TC ingress (协议栈入口) -> 内核协议栈 -> TC egress (协议栈出口)典型分工：
- XDP：处理早期丢包、粗粒度过滤
- TC：进行更复杂的协议解析和流量处理
5.2 动态配置管理
通过用户空间程序动态更新eBPF逻辑：
使用map存储配置参数
struct config { u32 drop_packets; u32 rate_limit; }; struct bpf_map_def SEC("maps") config_map = { .type = BPF_MAP_TYPE_HASH, .key_size = sizeof(u32), .value_size = sizeof(struct config), .max_entries = 1, };用户空间更新配置
from bcc import BPF b = BPF(src_file="program.c") config_map = b["config_map"] config_map[ct.c_int(0)] = ct.create_string_buffer(b'\x01\x00\x00\x00\x00\x00\x00\x00')
5.3 安全审计实现
示例：记录可疑连接
struct event { u32 saddr; u32 daddr; u16 dport; }; struct bpf_map_def SEC("maps") audit_map = { .type = BPF_MAP_TYPE_RINGBUF, .max_entries = 1 << 24, }; SEC("ingress") int audit_traffic(struct __sk_buff *skb) { struct event *evt; struct iphdr *ip = ip_hdr(skb); if (ip->protocol != IPPROTO_TCP) return TC_ACT_OK; evt = bpf_ringbuf_reserve(&audit_map, sizeof(*evt), 0); if (!evt) return TC_ACT_OK; evt->saddr = ip->saddr; evt->daddr = ip->daddr; evt->dport = tcp_dport(skb); bpf_ringbuf_submit(evt, 0); return TC_ACT_OK; }在实际部署中，我发现几个关键经验：首先，对于高频更新的计数器，PERCPU_ARRAY的性能比普通HASH高出5-8倍；其次，在复杂逻辑处理中，尾调用可以显著降低单个程序的复杂度，但要注意32次调用深度的限制；最后，使用ringbuf代替perf_event输出可以避免用户空间成为性能瓶颈。
