eBPF技术深度解析：从内核可编程到云原生可观测性

3 阅读 0 评论 0 点赞

eBPF技术深度解析：从内核可编程到云原生可观测性

2014年，Linux 3.18 内核引入了一个改变整个系统可观测性版图的技术——Extended Berkeley Packet Filter（eBPF）。从最初简单的数据包过滤，到如今成为内核可编程基础设施的核心支柱，eBPF 正在重新定义我们对网络、安全、可观测性和系统调试的认知。但与此同时，eBPF 也是一门"看得见摸不着"的技术——它运行在内核态，却不需要编写内核模块，这种独特的设计取舍背后隐藏着深刻而优雅的工程哲学。

本文将从 eBPF 的虚拟机架构出发，逐步拆解 Map 机制、验证器安全保证、各类 Hook 点的选择策略、CO-RE 跨平台可移植方案，最终落地到 Cilium 网络策略、可观测性探针、性能优化的完整工程闭环。每一章都配有可直接运行的代码片段，读完你将有能力在生产环境构建 eBPF 驱动的系统级工具。

一、eBPF 虚拟机内核架构

1.1 R10 寄存器与函数调用约定

eBPF 虚拟机是一个精简的 64 位 RISC 架构，拥有 11 个通用 64 位寄存器 (R0–R10)，其中 R0 存放返回值，R1–R5 存放函数调用参数，R6–R9 为调用者保存寄存器，R10 是唯一可读的帧指针（栈帧基址）。与 x86-64 的复杂调用约定相比，这种极简设计使得内核验证器可以在恒定时间内完成寄存器状态追踪。

eBPF 指令集采用 8 字节定长编码，每条指令由opcode、dst_reg、src_reg、off（有符号偏移）、imm（立即数）五个字段组成。64位 BPF_LD/LDX/ST/STX 类的 load/store 指令中， imm 字段编码寻址模式（BPF_IMM/BPF_MEM 等），而非立即数值。编译器的 JIT（即时编译）层将这些指令翻译为宿主架构的原生指令，x86-64 下平均膨胀率在 1.1–1.3 倍之间。

1.2 Helper 函数体系——用户态与内核态的桥梁

eBPF 程序本身不能随意访问内核内存或执行任意操作，唯一的扩展路径是通过 bpf() 系统调用注册的 Helper 函数。截至 Linux 6.x，内核提供了超过 200 个 Helper，涵盖日志输出、 Map 操作、时间获取、随机数、套接字操作、 bpf 程序间跳转等场景。

Helper 的调用使用 BPF_CALL 指令，函数 ID 编码在 imm 字段，参数通过 R1–R5 传递，返回值写入 R0。值得注意的是，Helper 函数列表在编译时通过 enum bpf_func_id 枚举暴露给 LLVM/Clang，而在加载时由内核验证器的 fixup_bpf_calls 步骤做最终链接。如果目标内核不支持某个 Helper，链接阶段会拒绝加载而非运行时崩溃。

1.3 BPF Type Format (BTF)——类型元数据的灵魂

传统 eBPF 程序严重依赖调试信息或内核头文件中的结构体定义。BTF（BPF Type Format）是 ELF 节中的一种紧凑编码的类型信息，它记录了每个内核类型、函数签名和源码行号的完整结构。BTF 使得 eBPF 程序可以在不依赖编译期头文件（vmlinux.h）的情况下，直接引用 struct task_struct->pid 这样的内核字段，且验证器能检查每一次访问的边界和偏移。

BTF 数据通过 BPF_BTF_LOAD 系统调用加载，可被验证器、 bpftool、perf 等多个子系统共享。开启 CONFIG_DEBUG_INFO_BTF=y 编译的 Linux 发行版（自 5.4 起大多数默认开启）会在 /sys/kernel/btf/vmlinux 提供完整的 vmlinux BTF。

二、Map 机制——内核态的高性能数据结构

2.1 Map 类型体系与适用场景

eBPF 的 Map 是驻留在内核空间的有类型键值存储，通过用户态 bpf(BPF_MAP_CREATE, &attr) 创建，获得一个文件描述符（fd）。Map 使用 BPF 系统调用与传统 syscall（read/write/bpf）或 Helper 函数两种方式访问。

常用 Map 类型一览：

Map 类型	特性	典型场景
BPF_MAP_TYPE_HASH	哈希表，key 唯一，动态增删	连接跟踪、计数器累加
BPF_MAP_TYPE_PERCPU_HASH	per-CPU 副本，避免写争用	高频统计（丢包计数等）
BPF_MAP_TYPE_ARRAY	固定大小，下标访问，O(1)	配置表、规则集
BPF_MAP_TYPE_LRU_HASH	最近最少使用淘汰，自动驱逐	DNS 缓存、连接状态
BPF_MAP_TYPE_RINGBUF	MPSC 环形缓冲区，高效批量传输	事件流输出（替代 perf buffer）
BPF_MAP_TYPE_PROG_ARRAY	存储 eBPF 程序 fd，bpf_tail_call 跳转	程序链式调度、大型程序拆分

其中 RINGBUF 是较新的推荐机制（自 5.8），相比传统的 BPF_MAP_TYPE_PERF_EVENT_ARRAY（perf buffer），RINGBUF 在内核 5.8+ 上提供零拷贝唤醒、更低的延迟、更精确的采样策略。其内部使用一个共享内存区域 + 消费者/生产者双指针（consumer_offset / producer_offset），用户态通过 poll/epoll 等待 consumer 指针推进，实现完全的事件驱动消费。

2.2 Map 的创建参数调优

创建 Map 时必须指定 max_entries（最大条目数）、key_size 和 value_size。对于 HASH 类型，实际内存占用量约为 max_entries × (key_size + value_size) × 1.1（含哈希桶开销）。而 PERCPU 系列每个 key 有 nr_cpus 个副本，实际占用为 max_entries × value_size × nr_cpus。

map_extra 字段（自 5.13）可实现 HASH 条目内存按需分配，BPF_F_RDONLY_PROG / BPF_F_WRONLY_PROG 标志控制程序对 Map 的读写权限，这些都是生产环境优化和安全化的关键旋钮。

三、验证器——安全执行的守门人

3.1 抽象解释与路径敏感分析

eBPF 验证器（verifier）是整个安全性保证的核心。它通过抽象解释（Abstract Interpretation）对所有可能的执行路径做静态模拟，检查以下关键不变量：

内存安全：所有限制指针的访问都在已验证的合法范围内
无泄漏：程序必须在有限步骤内终止，禁止循环和向后跳转（5.3 之前）；现代验证器支持有限循环，但要求每个循环都有上界证明
寄存器类型正确：每次调用 Helper 前检查参数类型（PTR_TO_MAP_VALUE、CONST 等）和是否 NULL
栈边界：每个 BPF-to-BPF 函数的栈帧限制 512 字节，递归调用被禁止

验证器的路径模拟采用 worklist 算法：从入口基本块开始，对每个可能分支（JMP 指令的两条 outgoing edge）做双路追踪，维护一个 " verifier state " 的优先队列。最多模拟 100万条指令（可调整 BPF_LOG_LEVEL 相关限制），超过此上限则拒绝加载。这相当于内核保证了 eBPF 程序不会因为死循环或复杂分支消耗无限内核资源。

3.2 指针类型追踪系统

验证器为每个寄存器维护一个 bpf_reg_state 类型标记，包括：

NOT_SCALAR、SCALAR_VALUE：未绑定或普通标量（如长度、计数器）
PTR_TO_CTX：指向 Hook 传入的上下文结构（如 xdp_md、sk_buff）
PTR_TO_MAP_KEY / PTR_TO_MAP_VALUE：Map 内数据指针（有效范围严格验证）
PTR_TO_STACK：指向当前栈帧内的变量
PTR_TO_MEM：指向 Map 值或 Packet 区域的通用指针
PTR_TO_BTF_ID：指向内核 BTF 类型（用于直接访问内核字段）

当 eBPF 程序尝试 r1 = *(r2 + offset) 这样的内存读取时，验证器会检查 r2 寄存器的类型标记和偏移量范围。如果是 PTR_TO_MAP_VALUE，则 offset 必须在 [0, map_value_size) 范围内，否则拒绝。这套机制使得"用户态程序不能越界读取内核数据"这一安全属性在编译期即可验证。

四、Hook 与 Attach 机制——内核事件的全景地图

4.1 XDP（eXpress Data Path）—— 最快的包处理

XDP 运行在网卡驱动层，是 eBPF 在数据包到达内核网络栈之前的最早介入点。这意味着它可以在 sk_buff 分配、协议栈协议解析之前就做出丢包、转发或重定向决策，因此具备业界最高的吞吐能力（单核 24Mpps 以上，取决于 NIC）。

XDP 的 attach 方式与网卡驱动实现相关：

Native XDP：驱动层直接执行 BPF 程序（需要驱动支持：i40、mlx4/5、ixgbe、nfp 等）
Offloaded XDP：BPF 程序下发到网卡 SmartNIC 执行（如 Netronome），CPU 完全不参与
Generic XDP：内核社区为不支持 XDP 的驱动提供通用 fallback（性能介于 native XDP 与 TC 之间）

XDP Hook 的返回码决定了数据包的最终命运：XDP_DROP（立即丢弃）、XDP_PASS（转交协议栈）、XDP_TX（从原网卡发出）、XDP_REDIRECT（转发到另一网卡或 CPU），XDP_ABORTED（异常终止，触发 tracepoint 记录）。一些高性能负载均衡器（如 Katran）就使用 XDP_DROP + Hash 实现四层 DDoS 防护。

4.2 TC（Traffic Control）—— 协议栈内的深度控制

TC eBPF 程序挂载在 Linux 流量控制框架的 ingress 和 egress 钩子，位置在协议栈（L3/L4）处理之后、socket 层之前。相比 XDP，TC 的优势是可以访问完整的 struct __sk_buff（包含数据包元数据、队列映射、优先级等），且支持修改数据包内容、添加/删除包头。

TC 的 attach 方式使用 tc clsact qdisc + BPF_PROG_TYPE_SCHED_CLS 类程序。通过 tc filter add dev eth0 ingress bpf obj prog.o section classifier 这样的命令完成加载。TC 的 eBPF 程序通过 bpf_skb_store_bytes、bpf_l3_csum_replace、bpf_redirect 等 Helper 实现 NAT、隧道封装、流量整形等高级操作。

TC 与 XDP 的选择原则很简单：位置越靠近硬件层，吞吐越高但抽象越弱。纯 L2/L3 DDoS → XDP；协议感知的限流、NAT、QoS → TC；应用层探针 → syscall tracepoint/kprobe。

4.3 Tracepoint / Kprobe / Uprobe

除了网络类别，eBPF 还支持挂载到内核 tracepoint 和动态探针：

Tracepoint：内核开发者预先埋入的静态探针（如 sched_process_exec、net_dev_xmit），稳定性最高
Kprobe：动态绑定到任意内核函数（通过 kallsyms 查找），覆盖率高但跨内核版本不稳定
Uprobe：用户态函数探针（如跟踪 Java 的 JIT 符号表），用于应用层可观测
Fentry / Fexit：基于 BTF 的轻量级函数入口/出口追踪（自 5.5），性能远超 Kprobe，且支持直接参数读取

Fentry/Fexit 是现代 eBPF 工具（BCC/bpftrace）的首选方案，因为它们通过 BPF trampoline 直接调用 eBPF 函数，避免了 Kprobe 的 debug 异常中断路径（开销降低约 80%）。

五、CO-RE 与可移植性——跨越内核碎片化

5.1 问题背景

eBPF 程序通过 Clang 编译为 BPF 字节码（ELF 对象中的 .text 和 maps 节），但结构体字段偏移在不同内核版本之间可能不同（例如 struct tcp_sock->srtt_us 在 4.15 和 5.6 中偏移相差 8 字节）。这导致为某内核编译的 eBPF 字节码不能直接用于另一个内核版本。

5.2 Compile Once – Run Everywhere 方案

CO-RE 的核心理念是将重定位信息（哪个字段、目标类型 ID、期望偏移）编码到 eBPF 对象的 ELF 节中（.BTF 和 .BTF.ext），而不是硬编码偏移或依赖编译期头文件。加载时，libbpf 从 /sys/kernel/btf/vmlinux 获取目标内核的实际类型定义，通过对比 BTF 字段 ID 自动"调整"字节码中的重定位记录，生成针对当前内核的适配代码。

CO-RE 的实现需要：

编译时使用 -g（生成 BTF debug info）+ -O2 优化
通过 vmlinux.h 头文件引用内核类型（系统自带的或 bpftool gen vmlinux 生成）
用户态加载时使用 struct bpf_object_open_opts->kernel_log + libbpf 的 bpf_object__open_skeleton / bpf_object__open_mem 接口完成 CO-RE 重定位

5.3 libbpf Skeleton 自动生成

bpftool gen skeleton prog.bpf.o 命令可以从 BPF 对象文件自动生成 C 骨架骨架（skeleton），其中包含封装好的 BPF_OBJECT 结构体、attach/detach 引用计数、Map 字段指针自动绑定。这种方式极大降低了 eBPF 用户态程序的开发复杂度，是现代 eBPF 项目的标准实践。

六、云原生实战——Cilium 与 eBPF 生态

6.1 Cilium 网络架构

Cilium 是当前 eBPF 在 Kubernetes 网络领域最成熟的实践，取代传统的 iptables /kube-proxy 方案提供 CNI 插件和网络策略。核心组件包括：

cilium-agent（用户态 DaemonSet）：通过 eBPF 程序管理 Pod 间路由、服务负载均衡、网络策略
cilium-operator：管理 CRD、同步策略事件、维护节点状态
CNI hook：新建 Pod 时通过 ep-runner 在容器 veth pair 上挂载 TC/XDP eBPF 程序

Cilium 使用 eBPF 实现的 kube-proxy replacement 在 XDP/TC 层完成 ClusterIP、LoadBalancer、NodePort 的服务映射，性能远优于 iptables 的线性规则匹配。实测数据表明，在 1000 Service + 10万 RPM 场景下，Network Policy 的处理延迟中位数从 iptables 的 2.3ms 降低到 eBPF 的 400us，P99 延迟从 15ms 降低到 1.8ms。

6.2 Cilium Network Policy + DNS 过滤

Cilium 的 NetworkPolicy 不只是 CIDR/标签匹配，还集成了：

L7 协议感知：通过 eBPF 解析 DNS query 字段（域名），实现基于 FQDN 的过滤（传统 CNI 只能基于 IP）
HTTP 路径白名单：通过 eBPF + Envoy 的 shared memory 通信，将 HTTP 请求转发到 Envoy 代理做 L7 决策
mTLS 集成：通过 eBPF 在 socket 层标记 Flow ID，配合 WireGuard/IPsec 做透明加密

6.3 eBPF-based Tracing：Pixie / Parca / pyroscope

eBPF 在可观测性领域的应用已经从"是否需要"变成了"如何用好"。基于 eBPF 的 zero-code-instrumentation 追踪方案通过挂载 uprobe/syscall tracepoint 自动捕获：

HTTP/2、gRPC、MySQL、PostgreSQL、Redis、Kafka 等协议的请求/响应延迟与 payload
CPU profiling（通过 perf_event eBPF hook 采栈）
Application memory alloc / free 事件（hook libc malloc/free）

Pixie 项目通过 STB（Stirling To Bpf）架构在 eBPF 模块和应用间建立环形缓冲区，实现微秒级数据采集而不影响应用性能。Parca 利用 eBPF 做连续 profiling，配合 Grafana 面板可实时查看 CPU 火焰图。

七、性能调优与工程最佳实践

7.1 BPF JIT 编译器优化

eBPF 字节码默认由内核 JIT 编译器（CONFIG_BPF_JIT=y）翻译为原生代码，比解释执行（interpreter）快 5–10 倍。通过 bpftool prog show 可以看到每个 BPF 程序的 JITed 状态。某些场景下，主动关闭 JIT（sysctl net.core.bpf_jit_enable=0）有助于排查 JIT 翻译 bug，但会大幅降低吞吐。

JIT 在 x86-64 上使用两级策略：先 greedy 尝试每条指令 1:1 映射（BPF → x86），遇到复杂指令（如 64 位除法）回退到 call 指令跳转到内核辅助函数。arm64 的 JIT 更激进——利用其 31 个通用寄存器做更紧凑的寄存器分配。因此在高通量 eBPF 部署中（如 SmartNIC），选择 arm64 / RISC-V 可能比 x86-64 有更优的代码密度。

7.2 Map 读写的 CPU 争用优化

高频 Map 写入（如 per-packet 流量统计）时，使用 BPF_MAP_TYPE_PERCPU_HASH / BPF_MAP_TYPE_LRU_PERCPU_HASH 可以让每个 CPU 写自己的局部副本，消除自旋锁争用。但读取时需要用户态遍历所有 CPU 做聚合：

// eBPF 程序侧：per-CPU 写，无锁
bpf_map_update_elem(&percpu_stats, &key, &value, BPF_ANY);

// 用户态侧：遍历 CPU 聚合
for (int cpu = 0; cpu < num_cpus; cpu++) {
    if (bpf_map_lookup_elem_flags(map_fd, &key, value_batch) == 0) {
        aggregate(values, value_batch[cpu]);
    }
}

替代方案是使用 BPF_MAP_TYPE_HASH 配合 BPF_F_NO_PREALLOC 关闭预分配（减少内存压力但每次有 syscall 开销），或使用 BPF_MAP_TYPE_ARRAY 的 bpf_spin_lock 字段实现 Map 内的细粒度锁——只在真正需要键级原子更新时使用。

7.3 BPF 程序大小与尾调用

内核要求单个 eBPF 程序指令数不超过 100 万条（实际可用约 4096–~8000 条，取决于验证器配置）。当 eBPF 逻辑复杂时，最常用的拆分手段是 尾调用（BPF_MAP_TYPE_PROG_ARRAY + bpf_tail_call()）。

尾调用的本质是原子替换当前程序的栈帧和程序计数器，不产生新的栈帧，因此：

不增加栈深度（避免栈溢出）
无需函数调用返回开销
天然支持"大型流程拆分"——例如将 eBPF 的 L2→L3→L4→L7 协议解析各拆一段，每段程序逻辑独立

每个 bpf_tail_call 可配置最多 33 个目标 slot（BPF_F_TEST_STATE_FREQ 等相关限制），超过后加载时就会失败。良好实践是按功能分层：probe_tail_1 做头匹配过滤，tail_2 做协议解析，tail_3 做数据提取。

7.4 BPF to BPF 函数调用——复用与内联

LLVM 编译器支持 BPF 程序内部定义的辅助函数通过 Call 指令（非尾调用）调用。验证器在入口和出口处检查这些函数的栈帧合法性（512 字节限制），并做路径敏感分析。所有 normal function call 在 JIT 阶段会被内联（inline）为连续指令（-O2 优化），但递归调用仍然被拒绝。

实际写 eBPF 代码时，建议将复杂的数据处理逻辑（如 JSON 序列化、HTTP header 解析）拆出到用户态（libbpf 包装），eBPF 只负责"收集原始数据"（时间戳、指针）并通过 RINGBUF/perf event 发送到用户态处理。这样能显著降低验证器分析复杂度，提高程序加载成功率。

7.5 BPF 程序生命周期与脱离（privilege 降级）

eBPF 程序通过 bpf() 系统调用加载，需要 CAP_SYS_ADMIN（全局 BPF）或 CAP_BPF + CAP_PERFMON（受限 BPF）。加载成功后：

程序引用计数自动化管理（attach 时 +1，detach 时 -1）
Map 有独立生命周期（创建时 refcount，bpf fd 关闭后归零触发销毁，BPF_F_PRESERVE_ELEMS 可控制 Map 数据是否保留）
BPF_LINK 机制（自 5.7）将 BPF 程序与其 attach 的生命周期绑定，link fd 关闭时自动解除 detach，防止"悬浮 Hook"

这也是为什么 cilium-agent 使用 BPF link 而非传统的 TC clsact 接口 attach——即使 agent 崩溃重启，老程序会自动清理，不会有"内核中残留幽灵探针"。

总结与展望

eBPF 正在从"黑客式的内核玩具"演进为"企业级的内核编程平台"。2025–2026 年值得关注的方向包括：

eBPF 安全网关：基于 Cilium Tetragon 的运行时威胁检测，通过 eBPF 在内核层捕获进程执行、文件操作、网络连接等事件，实现零探针入侵检测
eBPF 热加载：无需重启服务即可动态更新 eBPF 程序文件（自 5.15 的 BPF trampoline + link detach/attach 组合），支持"内核热补丁"
eBPF on Windows：Microsoft eBPF for Windows 项目使得 eBPF 框架能原生运行在 Win32 平台，跨 OS 的 eBPF 字节码生态正在形成
User Ring Buffer（URB）：eBPF 程序之间通过环形缓冲区直接通信，跳过用户态和 Map，适合零拷贝遥测流水

如果你还没开始用 eBPF，当前是最佳时机——主线的 libbpf、bpftool、BTF 支持在 Linux 5.15+ 上已经非常稳定，Go 语言的 cilium/ebpf、Rust 的 libbpf-rs、Python 的 bcc 等高级语言绑定也已成熟。从挂载一个 tracepoint/syscalls/sys_enter_write 开始，写几行代码记录进程 I/O，你就已经踏入了 eBPF 的世界。

点赞(0) 打赏

本文分类：eBPF技术
本文标签：eBPF Linux内核云原生 XDP Cilium 可观测性内核编程
浏览次数：3 次浏览
发布日期：2026-10-16 06:59:30
本文链接：https://www.ybb.press/ebpf-tech/17768.html

上一篇 > eBPF技术深度实战：从内核探针到可编程追踪的工程实践
下一篇 > eBPF：Linux内核的可编程革命，从入门到实战

eBPF技术深度解析：从内核可编程到云原生可观测性

eBPF技术深度解析：从内核可编程到云原生可观测性

一、eBPF 虚拟机内核架构

1.1 R10 寄存器与函数调用约定

1.2 Helper 函数体系——用户态与内核态的桥梁

1.3 BPF Type Format (BTF)——类型元数据的灵魂

二、Map 机制——内核态的高性能数据结构

2.1 Map 类型体系与适用场景

2.2 Map 的创建参数调优

三、验证器——安全执行的守门人

3.1 抽象解释与路径敏感分析

3.2 指针类型追踪系统

四、Hook 与 Attach 机制——内核事件的全景地图

4.1 XDP（eXpress Data Path）—— 最快的包处理

4.2 TC（Traffic Control）—— 协议栈内的深度控制

4.3 Tracepoint / Kprobe / Uprobe

五、CO-RE 与可移植性——跨越内核碎片化

5.1 问题背景

5.2 Compile Once – Run Everywhere 方案

5.3 libbpf Skeleton 自动生成

六、云原生实战——Cilium 与 eBPF 生态

6.1 Cilium 网络架构

6.2 Cilium Network Policy + DNS 过滤

6.3 eBPF-based Tracing：Pixie / Parca / pyroscope

七、性能调优与工程最佳实践

7.1 BPF JIT 编译器优化

7.2 Map 读写的 CPU 争用优化

7.3 BPF 程序大小与尾调用

7.4 BPF to BPF 函数调用——复用与内联

7.5 BPF 程序生命周期与脱离（privilege 降级）

总结与展望

评论列表共有 0 条评论

发表评论取消回复

eBPF技术深度解析：从内核可编程到云原生可观测性

eBPF技术深度解析：从内核可编程到云原生可观测性

一、eBPF 虚拟机内核架构

1.1 R10 寄存器与函数调用约定

1.2 Helper 函数体系——用户态与内核态的桥梁

1.3 BPF Type Format (BTF)——类型元数据的灵魂

二、Map 机制——内核态的高性能数据结构

2.1 Map 类型体系与适用场景

2.2 Map 的创建参数调优

三、验证器——安全执行的守门人

3.1 抽象解释与路径敏感分析

3.2 指针类型追踪系统

四、Hook 与 Attach 机制——内核事件的全景地图

4.1 XDP（eXpress Data Path）—— 最快的包处理

4.2 TC（Traffic Control）—— 协议栈内的深度控制

4.3 Tracepoint / Kprobe / Uprobe

五、CO-RE 与可移植性——跨越内核碎片化

5.1 问题背景

5.2 Compile Once – Run Everywhere 方案

5.3 libbpf Skeleton 自动生成

六、云原生实战——Cilium 与 eBPF 生态

6.1 Cilium 网络架构

6.2 Cilium Network Policy + DNS 过滤

6.3 eBPF-based Tracing：Pixie / Parca / pyroscope

七、性能调优与工程最佳实践

7.1 BPF JIT 编译器优化

7.2 Map 读写的 CPU 争用优化

7.3 BPF 程序大小与尾调用

7.4 BPF to BPF 函数调用——复用与内联

7.5 BPF 程序生命周期与脱离（privilege 降级）

总结与展望

Linux内核NAPI网络轮询机制深度剖析：从软中断到XDP/eBPF的现代演进

Linux内核进程调度器深度实战：CFS完全公平调度与实时调度类内核源码剖析

Linux网络协议栈深度实战：从网卡中断到Socket收包全链路内核源码剖析

eBPF：Linux内核的可编程革命，从入门到实战

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复