eBPF.party：把 eBPF 编程搬进浏览器沙盒的交互式课程
阅读时间: 大约 9 分钟
eBPF.party：把 eBPF 编程搬进浏览器沙盒的交互式课程
eBPF 是 Linux 内核里最有生产力、也最难入门的技术之一：你要装 clang、libbpf、拿到 root、理解 BTF CO-RE，再找一台内核版本合适的机器，才能写下第一行 trace。eBPF.party 想把这道门拆掉——它是一套完全在浏览器里写、编译、运行 eBPF 程序的交互式课程，不需要你本地搭任何环境。本文基于其官方站点与 how-it-works 说明页，拆解它到底怎么做到的，以及它的口径边界在哪里。
一、为什么需要这样一个东西
传统 eBPF 教学有两个坎。第一是环境：现代 CO-RE 开发依赖 clang、libbpf、bpftool 以及一个够新的内核，Windows/macOS 用户基本只能开虚拟机；第二是反馈循环：改一行 C、重新编译、挂到某个 tracepoint、再看 /sys/kernel/debug/tracing，一次往返成本很高。
eBPF.party 的取舍很明确：不教你如何在自己的生产机上部署，而是把“写一段 eBPF、立刻看到它在内核里跑出来的事件”这件事，压缩成网页里的几次按键。课程按章节递进，从概念到有状态编程再到内核探针。
二、课程是怎么组织的
根据官方站点的目录，内容分为四章：
- 第 0 章 入门：eBPF 简介、平台概览。
- 第 1 章 概念熟悉：进程上下文、读取事件数据、追踪一次系统调用、读取 syscall 数组。
- 第 2 章 有状态 eBPF：Maps 与多程序、读取 syscall 缓冲区、跨系统调用的状态跟踪、跟踪网络连接。
- 第 3 章 内核探针：内核探针介绍、读取 TCP 数据包。
也就是说，它覆盖了 eBPF 最核心的几个心智模型：事件触发、bpf_printk 式输出、Maps 做跨调用状态、以及 kprobe/tracepoint 类探针。这是一条“够用的入门路径”，而不是完整的生产级 eBPF 手册。
三、技术机制：浏览器类型检查 + 一次性微虚拟机
它最巧妙的地方是把“快”和“安全”拆到了两端。
编辑期：你在网页里写 C 代码时，TCC（Tiny C Compiler）通过 WASM 在你的浏览器里运行，提供即时类型检查——这一步不发任何服务器请求，所以改起来几乎无延迟。
运行期：当你点击 Run，代码先存入浏览器 localStorage，再发送到后端。后端用 clang 把它编译成 BPF object，然后拉起一个全新的临时虚拟机去加载执行。
事件从 VM 里出来的路径也值得一说：你的代码必须 #include "ep_platform.h"，它会创建一个 BPF ringbuf map，DEBUG_/SUBMIT_ 宏负责往里写事件；VM 内的自定义 /init 进程轮询这个 ringbuf，通过 vsock 转发到宿主机，后端再用 SSE（Server-Sent Events） 把事件流式推回你的浏览器。
四、关键数字（官方口径）
| 项目 | 数值 | 来源 |
|---|---|---|
| 每 VM vCPU | 0.5 vCPU | 官方 how-it-works |
| 每 VM 内存 | 64 MB RAM | 官方 how-it-works |
| 内核版本 | Kernel 6.18.2（官方标注 latest LTS） | 官方 how-it-works |
| 网络 | 无网络（No network） | 官方 how-it-works |
| 自毁计时器 | 500 ms | 官方 how-it-works |
| VM 启动耗时 | 40~50 ms | 官方 how-it-works |
| 虚拟化 | Firecracker（官方称带了 “some unholy patches”） | 官方 how-it-works |
| 事件通道 | BPF ringbuf → vsock → 后端 → SSE | 官方 how-it-works |
五、评测方法与口径批判
这里必须把官方数字的语境讲清楚，否则容易误读：
- “40~50ms 启动”不是通用 Firecracker 性能。 官方明确说启动快是因为 Firecracker 加上“一些不神圣的补丁（some unholy patches）”和一个极简内核。这是针对教学负载专门优化过的数字，不能外推到你自己的 Firecracker 部署。
- 内核是固定的 6.18.2，不是你的内核。 你在课程里写的 CO-RE 代码跑在这台固定 LTS 内核上；换到别的内核版本，BTF、可用 helper、tracepoint 格式都可能不同。它教的是“怎么写”，不是“怎么在你机器上跑通”。
- VM 只有 64MB、500ms 自毁、无网络。 这是一个刻意做小的沙盒：适合做 trace、计数、ringbuf 输出这类教学操作，但不适合长驻服务、真实网络抓包或复杂依赖。
- 类型检查 ≠ 编译通过。 浏览器里的 TCC-WASM 只做即时类型检查，真正生成 BPF object 的仍是后端 clang；TCC 能查出来的错误和 clang/内核 verifier 的判定并不完全等价。
六、优势与局限
优势：零环境门槛，反馈循环极短；用 Firecracker 一次性 VM 把“让用户跑内核代码”的爆炸半径压到极小（无网络、500ms 自毁）；课程结构覆盖了 eBPF 的核心概念跃迁（从无状态事件到 Maps 有状态再到探针）。仓库（DavidVentura/ebpf.party）采用 MIT 协议，前后端与课程内容都开源。
局限：内容仍在扩充中，偏入门，不覆盖 tail-call、BPF 环形缓冲区调优、多核 perf 等进阶生产话题；因为 VM 无网络且存活极短，“跟踪网络连接”这类练习是在受控注入的环境里演示，不是真实公网流量；它解决的是“第一次上手”，不能替代在真实 Linux 机器上用 bpftool/bpftrace 的实战。需要说明的是，笔者调研期间线上站点一度返回“服务器搬迁中”的占位页，课程内容与 how-it-works 均通过其官方页面文本核对。
七、谁该关注
- 想在不装 Linux 虚拟机的前提下第一次摸 eBPF 的前端/应用开发者；
- 需要给团队做 eBPF 入门 demo 的工程师；
- 对“浏览器内 TCC-WASM + Firecracker 一次性 VM + SSE 流式输出”这套教学沙盒架构本身感兴趣的人。
把它当成 eBPF 的“驾驶模拟器”很合适：练手足够安全，但别拿模拟器成绩去上真路。