在2018年的 Linux Plumber 大会上，eBPF成了亮点，有24个议题提到了 eBPF，可以预计eBPF会成为一大技术热点。
eBPF(Extended Berkeley Packet Filter) 的核心是驻留在 kernel 的高效虚拟机。最初的目的是高效网络过滤框架，前身是 BPF。
Linux kernel 3.18版本开始包含了eBPF，相对于 BPF 做了一些重要改进，首先是效率，这要归功于 JIB 编译 eBPF 代码；其次是应用范围，从网络报文扩展到一般事件处理；最后不再使用socket，使用map进行高效的数据存储。
根据以上的改进，内核开发人员在不到两年半的事件，做出了包括网络监控、限速和系统监控。目前eBPF可以分解为三个过程：
以字节码的形式创建 eBPF 的程序。编写C代码，将LLVM编译成驻留在ELF文件中的eBPF字节码。
将程序加载到内核中，并创建必要的 eBPF-maps。eBPF 具有用作 socket filter，kprobe 处理器，流量控制调度，流量控制操作，tracepoint 处理，eXpress Data Path(XDP)，性能监测，cgroup 限制，轻量级tunnel的程序类型。
将加载的程序attach到系统中。根据不同的程序类型attach到不同的内核系统中。程序运行的时候，启动状态并且开始过滤，分析或者捕获信息。
2016年10月的NetDev 1.2大会上，Netronome的Jakub Kicinski和Nic Viljoen发表了标题为“eBPF / XDP硬件卸载到SmartNIC”。 Nic Viljoen在其中介绍了Netronome SmartNIC上每个FPC每秒达到300万个数据包，每个SmartNIC有72到120个FPC，可能最大支持eBPF吞吐量4.3 Tbps！(理论上)
eBPF 触发了新一代网络、安全性、应用程序配置/跟踪和性能故障排除等领域的工具开发，这些工具不再依赖现有的内核功能，而是在不影响执行效率或安全性的情况下主动重新编程运行时行为。
那我们看看有哪些基于 eBPF 的工程，这些工程或许你已经知道，或是已经经常使用。
基于eBPF的项目
BCC是用于创建基于eBPF的高效内核跟踪和操作程序的工具包，其中包括一些有用的命令行工具和示例。 BCC简化了用C进行内核检测的eBPF程序的编写，包括LLVM的包装器以及Python和Lua的前端。它还提供了用于直接集成到应用程序中的高级库。
bpftrace是Linux eBPF的高级跟踪语言。它的语言受awk和C以及DTrace和SystemTap等以前的跟踪程序的启发。 bpftrace使用LLVM作为后端将脚本编译为eBPF字节码，并利用BCC作为与Linux eBPF子系统以及现有Linux跟踪功能和连接点进行交互的库。
Cilium是一个开源项目，提供基于eBPF的联网，安全性和可观察性。它是从头开始专门设计的，旨在将eBPF的优势带入Kubernetes的世界，并满足容器工作负载的新可伸缩性，安全性和可见性要求。
Falco是一种行为活动监视器，旨在检测应用程序中的异常活动。 Falco在eBPF的帮助下审核Linux内核层的系统。它使用其他输入流(例如容器运行时度量标准和Kubernetes度量标准)丰富了收集的数据，并允许连续监视和检测容器，应用程序，主机和网络活动。
Katran是一个C ++库和eBPF程序，用于构建高性能的第4层负载平衡转发平面。 Katran利用Linux内核中的XDP基础结构来提供用于快速数据包处理的内核功能。它的性能与NIC接收队列的数量成线性比例，并且使用RSS友好的封装转发到L7负载平衡器。
Sysdig是提供深层系统可见性的简单工具，并具有对容器的原生支持。
其他基于eBPF技术的项目还有很多，比如kubectl-trace ，ply 等，这里不再赘述。
如何编写一个eBPF程序？
在很多情况下，不是直接使用eBPF，而是通过Cilium，bcc或bpftrace等项目间接使用eBPF，这些项目在eBPF之上提供了抽象，并且不需要直接编写程序，而是提供了指定基于意图的定义的功能，然后使用eBPF实施。
如果不存在更高级别的抽象，则需要直接编写程序。 Linux内核希望eBPF程序以字节码的形式加载。虽然当然可以直接编写字节码，但更常见的开发实践是利用LLVM之类的编译器套件将伪C代码编译为eBPF字节码。
在编写eBPF程序之前，需要简单了解几个概念。
1)map(映射) ：BPF最令人着迷的方面之一是，内核上运行的代码和加载了该代码的程序可以在运行时使用消息传递相互通信。
BPF映射是驻留在内核中的键/值存储。任何BPF程序都可以访问它们。在用户态中运行的程序也可以使用文件描述符访问这些映射。只要事先正确指定数据大小，就可以在映射中存储任何类型的数据。内核将键和值视为二进制 blobs，它并不关心您在映射中保留的内容。
BPF验证程序包括多种保护措施，以确保您创建和访问映射的方式是安全的。当我们解释如何访问这些映射中的数据时，我们也将解释这些保护措施。
当然BPF映射类型有很多，比如哈希表映射，数组映射，Cgroup 数组映射等，分别满足不同的场景。
2)验证器
BPF验证程序也是在您的系统上运行的程序，因此，对其进行严格审查是确保其正确执行工作的目标。
验证程序执行的第一项检查是对VM即将加载的代码的静态分析。第一次检查的目的是确保程序有预期的结果。为此，验证程序将使用代码创建有向循环图(DAG)。验证程序分析的每个指令将成为图中的一个节点，并且每个节点都链接到下一条指令。验证程序生成此图后，它将执行深度优先搜索(DFS)，以确保程序完成并且代码不包含危险路径。这意味着它将遍历图的每个分支，一直到分支的底部，以确保没有递归循环。
这些是验证器在第一次检查期间可能拒绝您的代码的情形，要求有以下几个方面：
该程序不包含控制循环。为确保程序不会陷入无限循环，验证程序会拒绝任何类型的控制循环。已经提出了在BPF程序中允许循环的建议，但是截至撰写本文时，没有一个被采用。
该程序不会尝试执行超过内核允许的最大指令数的指令。此时，可执行的最大指令数为4,096。此限制是为了防止BPF永远运行。在第3章，我们讨论如何嵌套不同的BPF程序，以安全的方式解决此限制。
该程序不包含任何无法访问的指令，例如从未执行过的条件或功能。这样可以防止在VM中加载无效代码，这也会延迟BPF程序的终止。
该程序不会尝试越界。
验证者执行的第二项检查是BPF程序的空运行。这意味着验证者将尝试分析程序将要执行的每条指令，以确保它不会执行任何无效的指令。此执行还将检查所有内存指针是否均已正确访问和取消引用。最后，空运行向验证程序通知程序中的控制流，以确保无论程序采用哪个控制路径，它都会到达BPF_EXIT指令。为此，验证程序会跟踪堆栈中所有访问过的分支路径，并在采用新路径之前对其进行评估，以确保它不会多次访问特定路径。经过这两项检查后，验证者认为程序可以安全执行。
3) hook ： 由于eBPF是事件驱动的，所以ebpf是作用于具体的hook的。根据不同的作用，常用的有XDP，trace，套接字等。
4)帮助函数：eBPF程序无法调用任意内核功能。允许这样做会将eBPF程序绑定到特定的内核版本，并使程序的兼容性复杂化。取而代之的是，eBPF程序可以调用帮助函数，该函数是内核提供的众所周知且稳定的API。
总结
安全，网络，负载均衡，故障分析，追踪等领域都是eBPF的主战场。对于云原生领域，Cilium 已经使用eBPF 实现了无kube-proxy的容器网络。利用eBPF解决iptables带来的性能问题。
整个eBPF生态发展比较好，社区已经提供了诸多工具方便大家编写自己的eBPF程序。
