1.BPF起源

BPF源头起源于一篇1992年的论文，这篇论文主要提出一种新的网络数据包的过滤的框架，如下图所示。

image.png

提出bpf的原因其实也很简单，早期我们从网卡中接收到很多的数据包，我们要想从中过滤出我们想要的数据包，我们需要将网卡接收的数据包都要从内核空间拷贝一份到用户空间。然后，用户程序在对这些进行过滤。那么，我们可以从中就能够发现一个问题。数据包必须全部拷贝。然后再过滤出所需的数据包，那么对于那些不需要的数据包，我们拷贝的操作是无效的、浪费的。并且对于内存数据的拷贝是很费cpu系统的资源的。所以，这篇论文，就提出了一种新的框架，在内核中直接过滤，这也可以避免一些无用的、浪费的拷贝。

其背后的思想其实就是：与其把数据包复制到用户空间执行用户态程序过滤，不如把过滤程序灌进内核去。

这种新的框架，其实还是很容易理解的。大概的理解就是，当我们从网卡接收到一个数据包的时候，我们数据链路层，将数据包额外的拷贝一份。然后这个新的数据包就交给BPF程序进行处理，这个BPF根据用户编写的过滤规则对这个新的数据包进行匹配。如果符合此规则就将数据包放到接收队列中，那么用户事后就可以从接收队列中将这个数据包从内核空间拷贝到用户空间，这样就减少了无用的数据包的拷贝。

像tcpdump/wireshark等用户工具就是基于BPF框架实现的。其大概实现的过程就是，编写BPF指令集的过滤规则，然后创建raw/packet类型的套接字socket，将网卡设置为混杂模式。在通过setsockopt函数将BPF代码拷贝到内核，并attach到相关联的socket套接字上。当网卡接收到数据包的时候，因为设置的混杂模式，那么就会额外的拷贝一份新的数据包，然后在根据BPF的代码进行过滤，将符合规则的数据包接收到socket套接字的接收队列里面。最后用户程序就可以从这个接收队列获取到过滤后的数据包了。这类工具的实现流程就是大概这个样子。

2.伪机器码、BPF指令集、JIT

使用过tcpdump工具的应该都见过在tcpdump命令后面会加一些表达式，用来表示过滤规则。

如:sudo tcpdump -d -i lo tcp and dst port 7070

注意不要以为这个表达式就是BPF程序了，其实这不是的。这个表达式是要经过编译过后才会变成BPF程序的。在我们早期是生产这类编译器，那么是如何将这个表达式编译出BPF指令集的呢？

tcpdump的实现是基于libcap库的，tcpdump使用的过滤表达式是使用libcap库进行解析的，生成我们BPF指令集。那为什么没有单独做成一个这类的编译器？究其原因就是但是的BPF框架使用的功能较少，只用在了网络的数据包过滤方面。除此之外，当时的BPF指令集个数很少，所以没有必要花费大量的资源单独做一个编译器。但是随着BPF的发展，指令集的复杂、支持的BPF程序类型越来越多，就急需要一个编译器了。那这个就是我们后面将要提到的eBPF和clang/llvm编译器了。

伪机器码：假的机器码，机器码都是能够在物理机上直接执行的，伪机器码不能够直接执行，需要在虚拟机上执行。

BPF指令集：BPF指令集就是一个伪机器码，是不能够在物理机上直接执行的，需要一个虚拟机才能够执行。我们都知道不同的处理器体系结构有自己的不同指令集，这边的BPF指令集可以理解为在BPF虚拟机上执行的指令集。

JIT：just in time 的缩写，我们将编译好的BPF指令集需要在虚拟机上执行，虚拟机需要一条一条的解析为本机机器码才能够执行，所以这个执行效率会很低，但是如果我们的处理器有了JIT就能够将我们BPF直接直接编译为能够在机器直接执行的机器码，这样大大提高了执行的速度。

3.eBPF介绍

eBPF是extend BPF的简称，扩展的BPF。我们刚了解BPF了，都知道BPF的功能比较单一只能够作用于网路的数据包的过滤上，但是扩展后的BPF的功能得到了很大的丰富，可以这样说基本上可以使用在Linux各个子系统中。除了功能上的扩展，BPF程序的指令集也变得相当复杂了，所以就出现了专门用于编译BPF程序的clang/llvm编译。在框架上BPF的框架也发生了变化，所以扩展后的BPF不再是早期的BPF的可以比拟的。因而，早期的BPF被称为cBPF，扩展后的BPF被称为eBPF。

现在看下扩展后的BPF的框架，如下图所示：

image.png

注意：我们后面说的BPF指的是cBPF和eBPF的统称，除非特别说明。

虽然，框架发生变化，但是其基本的思想还没有发生变化的。都是将BPF程序进行编译后生成字节码，然后将BPF字节码注入到内核中，当发生事件触发的时候，我们就会执行相应的BPF程序。

现在，我们对cBPF和eBPF进行对比：

一、cBPF支持的功能比较单一，只能够作用于网络的数据包的过滤上。而eBPF除了能够支持网络的数据包的过滤上，也支持其他的事件类型，如上图中的XDP、Perf Event、kprobe、tracepoint等等。cBPF的功能在eBPF其实对应的就是Socket的部分。

二、引入Map机制。在cBPF我们通过接收队列将过滤后数据获取出来，但是在eBPF我们可以将数据放到Map空间中。Map空间是用户空间和内核空间共享的，所以一般是在内核中将数据存入到Map空间中，然后在用户空间取出数据。

三、指令集变得更复杂了，与此同时，有了专门的用于编译BPF字节码的编译器clang/llvm。

四、还有在安全机制方面等等一些改变。

4.eBPF类型和Map机制

首先，看下eBPF支持的类型，其中BPF_PROG_TYPE_SOCKET_FILTER对应的就是早期cBPF的功能。只不过在eBPF中使用的框架不再是以前的cBPF的框架了，但是其实现的功能是一样的。

Map机制的优势：

Map机制引入的原因，其中一个最大的原因就是通信。对于Map空间是用户和内核共享的，我们可以在内核中将处理后的数据直接存入Map空间。然后，可以从用户空间中进行获取。这样就是大大方便了通信。除此之外，我们在内核中进行数据处理后，相应的数据的占用的空间就会变小的很多，然后，在将数据存入到Map空间中。想比较于cBPF需要将数据获取到后，在进行处理，这样可以大大节省存储空间。

Map机制下的常见的数据类型：

5.BPF程序编写使用的语言

对于早期的cBPF程序的编写，一般都是直接使用BPF指令集来编写程序。像tcpdump这类工具，提供的使用方法可以类似于高级语言的人性化的表达式的使用，但是其实还是一样的，只不过是让libcap进行解析了。BPF程序的编写难度是极高的。

后来，由于BPF的扩展，急需要一种高级语言来编写BPF程序，就出现了c语言的编程。通过c语言进行编写，然后，通过clang/llvm将c语言编译为BPF字节码，然后在注入到内核中。但是对于注入的方式，还是需要通过自己手动的方式才能够注入。

后来，就出现了BPF Compiler Collection（BCC），BCC 是一个 python 库，但是其中有很大一部分的实现是基于 C 和 C++的，python 只不过实现了对 BCC 应用层接口的封装而已。使用bcc的最大好处是，用户只需要关注BPF程序的设计，对于剩余的工作都不用管，包括编译、解析 ELF、加载 BPF 代码块以及创建 map 等等基本可以由 BCC 一力承担，无需多劳开发者费心。

6.BPF工作原理总结

首先，看下BPF框架图，如下图所示：

image.png

一般我们都是通过c语言编写BPF程序，然后通过clang/llvm编译器，将BPF程序编译为BPF字节码。然后通过bpf系统调用，将BPF字节码注入到内核中，在注入的时候，我们必须要经过BPF程序的验证，来保证我们写的BPF程序没有问题，以防干掉我们的系统。然后，在判断是否开启了JIT，然后开启了，还需要将BPF字节码编译为本机机器码，以加快运行速度。

当我们BPF程序attach的事件触发了，就会执行我们的BPF程序，然如是经过JIT编译过后的就能够直接执行，然后没有开启JIT就需要通过虚拟机进行解析在执行。在执行BPF程序的过程中，会将需要保存的数据存储到map空间中，用户时候可以从map空间读取出数据。BPF程序的大致流程就是这个样子。

注意：BPF是基于事件触发的。这是什么意思呢？

就是如果我们将BPF程序attach到某个事件上，当这个事件触发的时候，就会执行我们这个BPF程序。其实这就是BPF的工作原理。

如，我们将BPF程序attach到kprobe类型的事件上，这个kprobe事件是个函数，当cpu执行到这个函数的时候，就会触发。然后就会执行我们的BPF程序。

7.eBPF的作用

eBPF能够用于内核追踪、应用性能调优/监控、流量控制等方面，是非常有用的。

针对用于监控、跟踪使用的eBPF程序来说，主要是通过在内核运行的过程中，来获取内核运行时的一些参数和统计信息。例如：系统调用的参数值、返回值，然后通过Map空间，将得到的信息传递给用户态的程序，进而可以在用户程序中在进行逻辑处理。

eBPF除了能够获取内核运行的状态信息，也能够改变内核的处理流程，可以在内核某些路径上加入直接的处理逻辑，来改变内核的运行的流程。例如：XDP，就是在网卡驱动中，在进入内核协议栈之前插入eBPF的扩展的网络包的过滤和转发功能。

开发

直接 eBPF 编码比较困难，人们通过框架来使用 eBPF。对于 tracing 来说，主要的框架就是 bcc 和 bpftrace，这两个框架并不在内核代码中，他们在名为 iovisor 的 Linux Foundation project 中维护。

2. eBPF tracing 示例

tcplife是一个基于 eBPF 的工具，可以显示完整的 TCP session, 以及对应的进程号(PID) ，命令(COMM)，收发字节数(TX_KB, RX_KB)，以及时长(MS)：

# tcplife
PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
22597 recordProg 127.0.0.1       46644 127.0.0.1       28527     0     0 0.23
3277  redis-serv 127.0.0.1       28527 127.0.0.1       46644     0     0 0.28
22598 curl       100.66.3.172    61620 52.205.89.26    80        0     1 91.79
22604 curl       100.66.3.172    44400 52.204.43.121   80        0     1 121.38
22624 recordProg 127.0.0.1       46648 127.0.0.1       28527     0     0 0.22
3277  redis-serv 127.0.0.1       28527 127.0.0.1       46648     0     0 0.27
22647 recordProg 127.0.0.1       46650 127.0.0.1       28527     0     0 0.21
3277  redis-serv 127.0.0.1       28527 127.0.0.1       46650     0     0 0.26

并不是 eBPF 才使得这样的工具成为可能，完全可以利用其他内核技术特性重写tcplife。但是如果这么做了，我们将因为性能开销、安全等因素而无法在生产环境中运行这个工具。eBPF 做的恰恰是让这个工具变得实用，tcplife 是高效并且安全的。举例来说，tcplife 并不会像其他内核技术特性一样去追踪每个网络包(packet)，那样会带来太多的性能开销。相反地，tcplife 只追踪 TCP session 事件，这类事件相对来说频率较低。这使得tcplife的负载极低，以至于我们可以在生产环境中24小时持续运行这个工具。

3. 如何使用 eBPF

对于初学者，尝试一下 bcc tools。bcc 的安装很简单，并有详细的说明文档，例如在 Ubuntu 上，效果如下

# sudo apt-get update
# sudo apt-get install bpfcc-tools
# sudo /usr/share/bcc/tools/opensnoop
PID    COMM               FD ERR PATH
25548  gnome-shell        33   0 /proc/self/stat
10190  opensnoop          -1   2 /usr/lib/python2.7/encodings/ascii.x86_64-linux-gnu.so
10190  opensnoop          -1   2 /usr/lib/python2.7/encodings/ascii.so
10190  opensnoop          -1   2 /usr/lib/python2.7/encodings/asciimodule.so
10190  opensnoop          18   0 /usr/lib/python2.7/encodings/ascii.py
10190  opensnoop          19   0 /usr/lib/python2.7/encodings/ascii.pyc
25548  gnome-shell        33   0 /proc/self/stat

这里我通过运行 opensnoop 来验证 bcc tools 是否工作，如果你顺利到这一步，说明你已经在使用 eBPF 了！

Netflix 和 Facebook 等公司已经在服务器上默认安装 bcc ，或许你也想这么做。

4. 初学者入门教程

Brendan Gregg 提供了一个 bcc 入门教程，方便初学者很好地开始 eBPF tracing.

作为初学者，你不必开发 eBPF 代码。bcc 自带超过 70 多个工具可以直接使用。bcc 入门教程里你将接触 其中 11 个工具：execsnoop, opensnoop, ext4slower (or btrfs, xfs, zfs), biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans, runqlat, and profile.

一旦你开始入门，你需要清楚 bcc tracing 工具还有很多：

这些工具都有很详细的文档，包括使用手册和示例。示例文件（xxx_example.txt）展示了屏幕截图和对应的解释：比如 biolatency_example.txt. Brendan Gregg 撰写了许多类似的示例文档、使用手册、工具，都在 bcc repo 中。

生产环境中的 bcc tracing 示例没有提供，Brendan Gregg 在撰写这篇文档时，eBPF 刚发展起来并只在测试机器上可用，因此大多数使用示例都是构造的测试用例。之后这个教程里会提供真实世界的用例，这是初学者可以贡献的方向：如果你通过 bcc 工具解决了一个实际问题，考虑发布一个博客文章来共享屏幕截图，或者添加到 bcc repo 的 examples 文件中。

Intermediate

到这里，你应该已经可以运行 bcc 并尝试了上述工具，然后你肯定会想定制开发自己的 bcc 工具。最佳实践是切换到 bpftrace，bpftrace 提供高级语言可以使得入门开发更简单。坏处就是 bpftrace 不如 bcc 那么拓展友好。因此，你最终还是会遇到瓶颈，继而切换回 bcc。

参考 bpftrace 安装说明，bpftrace 是不同于 bcc 的另一个项目。此时 bpftrace 还没有在各个平台打包发布。在不久的将来，可以很方便地通过类似 apt-get install bpftrace 的方式来安装。

1. bpftrace 教程

Brendan Gregg 开发一个了 bpftrace 教程，通过一系列命令来学习 bpftrace，一共有 12 个示例循序渐进。

其中一个示例的截图如下，这里使用 open syscall tracepoint 来跟踪 PID 和对应的打开文件路径。

# bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%d %s\n", pid, str(args->filename)); }'
Attaching 1 probe...
181 /proc/cpuinfo
181 /proc/stat
1461 /proc/net/dev
1461 /proc/net/if_inet6

2. bpftrace 参考指南

关于 bpftrace 的更多参考信息，Brendan Gregg 整理了一个 参考指南，提供了关于 bpftrace 的语法、探针、内建等的示例。

这个参考指南的目的很简单：Brendan Gregg 尽可能地把主题、摘要、截图都放在一个屏幕上。如果你查找一些东西，需要滚动浏览多页，那就太长了。

3. bpftrace 示例

bpftrace repo 中有 20 多个工具，可以通过这些工具来学习开发。例如：

# cat tools/biolatency.bt
[...]
BEGIN
{
    printf("Tracing block device I/O... Hit Ctrl-C to end.\n");
}
 
kprobe:blk_account_io_start
{
    @start[arg0] = nsecs;
}
 
kprobe:blk_account_io_completion
/@start[arg0]/
 
{
    @usecs = hist((nsecs - @start[arg0]) / 1000);
    delete(@start[arg0]);
}

和 bcc 工具一样，bpftrace 工具也有完整的使用手册和示例文档，例如 biolatency_example.txt。

Advanced

https://github.com/eunomia-bpf/bpf-developer-tutorial
Brendan Gregg 提供了两个帮助文档：

• bcc Python Developer Tutorial
• bcc Reference Guide

在 bcc/tools/*.py 中有很多示例。bcc tools 分为两大部分：1）面向内核的 BPF 代码，用 C 语言开发；2）用户态工具，用 Python (lua, C++) 等语言开发。开发 bcc tools 一定程度来说是高阶的，可能会深入复杂的内核或应用程序的内部。