一、eBPF CORE及开发模式对比
随着 BPF 技术的发展，开发一个 BPF 程序变得越来越简单，尽管 BPF 提升了便利性，但 BPF 也一直在追求另一个方面：可移植性。BPF 可移植性被定义为成功编写并通过内核验证的一个 BPF 程序，能运行在不同内核版本。
进行 BPF 的移植有两个挑战：
1. 不同内核版本数据的内存布局不同。
2. 内核类型和数据结构不断变化，结构体字段可能被移除或重命名。
BPF CO-RE(Compile Once - Run Everywhere)是实现可移植性的一个手段。
为了支持 CORE，我们提供了以下组件：
① BTF: 描述内核镜像，获取内核及BPF程序类型和代码的关键信息
② Clang释放bpf程序重定位信息到.btf段
③ Libbpf CO-RE根据.btf段重定位bpf程序
需要进行重定位的信息主要有三类：
① 结构体相关重定位，这部分和BTF息息相关。Clang通过__builtin_preserve_access_index()记录成员偏移量。
② map fd 、全局变量（data、bss、rodata）、extern 的变量重定位，主要依赖于 ELF 的重定位机制，来更新 eBPF 指令的 imm 字段。
③ 子函数重定位，是为了将 eBPF 程序调用的子函数同主函数放在一起，便于一起加载到内核。
使用 libbpf 进行 BPF CORE 的开发步骤如下：
第一步：生成带所有内核类型的头文件vmlinux.h，通过bpftool 生成。
第二步：使用Clang(版本10或更新版本)将BPF程序的源代码编译为.o对象文件；
第三步：从编译好的BPF对象文件中生成BPF skeleton 头文件 bpftool gen命令生成；
第四步：在用户空间代码中包含生成的BPF skeleton 头文件；
第五步：编译用户空间代码，则嵌入BPF对象代码无需发布单独的文件。
大致有如下函数调用：
① __open() ：创建并打开 BPF 应用，之后可以设置skel->rodata 变量。
② __load() ：初始化，加载和校验BPF 应用部分。
③ __attach() ：附加所有可以自动附加的BPF程序。 有事件和网络运行报文到达时，会触发运行 bpf 程序。
④ __destroy() :分离所有的 BPF 程序并使用其使用的所有资源。
eBPF的主要开发方式有三种，各有优缺点。
1、内核自带示例代码：基于内核 samples/bpf 示例代码，无 CORE。该方式没有任何基于第三方的开源项目，资源占用量低。但缺点是需要自己完全重新搭建工程，效率较低，且版本兼容性较差。
2、BPF CORE：基于 libbpf 自己编写的 bpf_core_read 代码，开发机生成对应目标机的二进制程序。该方式不依赖在环境中部署 Clang/LLVM ，资源占用少。但是需要搭建编译工程，部分代码相对固定，无法动态配置。
3、BCC：基于应用最广的开源项目，开发效率较高。但是每一次运行都要执行 Clang/LLVM 编译，存在内存、CPU 等资源的争抢；目标环境依赖对应内核头文件。
二、Coolbpf的功能和架构
Coolbpf 提供了远程编译（云编译）。其中远程编译指运行程序的目标机器与编译程序不在同一个机器上，能够解决资源占用问题；提供了本地编译和基础库封装，方便用户调用基础库进行编写；提供了低版本内核的支持；提供了 BTF 的自动生成和发布，用户无需手动适配，下载即可直接使用；提供了自动化测试以及支持 Python/Go/Rust 等高级语言进行应用开发。
Coolbpf 天然支持 BPF 的 CORE 能力，它解决了编译和资源消耗的问题，同时，前面介绍的复杂的 libbpf 开发步骤完全被简化了。用户只需要专注自己的功能开发，不用关注环境搭建和冗余代码开发。
Coolbpf 提供了标准化的 bpf 编译服务。首先将 bpf.c 提交到远程编译服务器时，服务器会根据的内核版本针对不同的语言返回点 bpf.so 或 bpf.o 为高级的应用程序提供服务。因此在你的高级语言代码中，只需加载 bpf.so 即可运行程序，无需再手动触发 Libbpf 的 open()、load()、attach()等函数，而是由高级语言程序的 init()自动完成，这样用户可以快速搭建和部署工程，只需专注于数据输出之后的处理。
Coolbpf 还支持在没有 eBPF 特性的低内核版本上，通过我们提供的 eBPF 驱动，帮助它安全的在低版本上运行。我们将高版本上 eBPF verifier 校验部分实现在一个驱动里，它会进行各种安全校验，保证 eBPF 对比于内核模块的安全性。另外，我们把原来基于 libbpf 的调用都转换为 IOCTL 的系统调用。
之前支持的 helper 函数、创建 map 、加载 program 都会转化成低版本上的 kprobe 或 tracepoint 的实现，另外还支持 perf event 和 jit。这样就使得同一个用户程序，加载这样一个驱动，就能不修改 eBPF 程序代码而安全的运行在低版本内核上。
三、Coolbpf的网络应用实践
Raptor 是基于 Coolbpf 的系统可观测工具，能够运行在低版本内核如 alios、CentOS 3.10 等。它可以作为一个 SDK，提供给第三方使用，进行数据采集。
在这个网络应用观测中，通过监控系统调用中的数据交互、请求和回复等信息，来确定交互的数据内容和五元组等信息，通过 map 的交互方式发送给用户态，做到了无侵入的方式做观测，最终呈现比如流量统计、请求时延等观测结果。
我们来看一个具体的问题，了解 Coolbpf 是如何发现收包阶段的网络抖动问题。我们知道网络收包分为两个阶段：
阶段1：OS通过软中断将数据包送到应用的收包队列并通知进程，完成协议栈的收包工作。
阶段2：应用得到通知后从收包队列取数据。
我们在 Coolbpf 里写一段 BPF 程序，只需监控两个 tracepoint：tcp_probe，tcp_rcv_space_adjust 就能查询到阶段 2 的延迟问题。
在这个案例中，某业务应用收包慢，发现内核侧已经收到了 tcp 包，但是应用侧将近 1s 后才收到。观测方法：部署 eBPF agent，发现阶段 2“收包延迟时间”将近 1 秒。
确定原因：每次发生延迟时间都在某时刻的大致 42 秒处，怀疑跟业务某定时任务相关造成应用自身延时，最终排查到业务有某个任务会定时收集 jvm 的参数，对该业务有 stop 的操作。
解决方法：停掉该任务后，消除了抖动问题。
关于龙蜥峰会 eBPF & Linux 稳定性专场课件获取方式：
【PPT 课件获取】：关注微信公众号（OpenAnolis），回复“龙蜥课件” 即可获取。有任何疑问请随时咨询龙蜥助手—小龙（微信：openanolis_assis)。
【视频回放】：视频回放可前往龙蜥官网https://openanolis.cn/video 查看。
