eBPF（extended BPF）的 verifier 与 JIT 编译是什么？它们如何保证程序安全与性能？
eBPF 程序加载前先经 verifier 静态校验：检查寄存器状态、指针边界、内存访问范围、循环有界性，确保程序不会越界或死循环，从而可安全运行在内核；通过验证后由 JIT 编译器把 eBPF 字节码翻译为原生机器指令，提升执行性能。verifier 保证安全（无越界、无大循环），JIT 保证高性能，两者结合使 eBPF 能在内核安全高效地运行。
本题考察 eBPF 的双重机制。核心是"verifier 保安全、JIT 提性能"。作答时说明校验流程与编译分工。
TLS offload（kTLS）的"加密零拷贝"是什么？它如何提升 TLS 性能？
kTLS（kernel TLS）把 TLS 记录处理（加密、解密、完整性校验）下沉到内核，利用内核的 crypto 引擎与零拷贝路径处理数据，避免用户态与内核态之间的往返拷贝。发送侧用 sendfile 等直接引用页缓存加密，接收侧内核解密后交用户，减少拷贝与上下文切换。kTLS 适合高吞吐 TLS 场景，卸载 CPU 加密开销并向硬件加速演进。
本题考察 kTLS。核心是"内核处理 TLS 记录 + 零拷贝"。作答时说明其免拷贝与加密卸载的收益。
eBPF map 的 hash、array、lru、lpm_trie、ringbuf 等类型各自适合什么场景？bpf_map_type 如何区分？
eBPF map 是内核与用户态共享数据的结构，bpf_map_type 枚举区分类型：hash 适合键值查找、array 适合固定索引访问、lru 适合有容量限制的缓存、lpm_trie 适合最长前缀匹配（路由）、ringbuf 适合按序的高吞吐事件流。各类型在查找复杂度、内存占用与并发访问上权衡，工程按数据结构与查询模式选择。
本题考察 eBPF map 类型。核心是"不同类型对应不同数据结构与查询"。作答时说明各类型适用场景。
eBPF 的 helper 函数与"受限 C"子集是什么？它们如何保证程序可验证、可安全执行？
eBPF 程序不能随意调用内核函数，只能调用受限的 helper 函数（如 bpf_map_lookup_elem、bpf_probe_read），这些函数经 verifier 审查、参数与返回语义明确；同时 eBPF 使用"受限 C"子集，禁止无界循环、指针运算、递归等难验证结构。helper 白名单与受限子集共同保证程序可被 verifier 静态验证，从而安全运行在内核。
本题考察 eBPF 的受限模型。核心是"helper 白名单 + 受限 C 保证可验证"。作答时说明为何不能随意调用内核函数。
eBPF 在 Cilium 的应用（service mesh 数据平面）是什么？它如何提升网络处理？
Cilium 用 eBPF 构建 Kubernetes 的网络数据平面，替代 iptables，在数据包路径上直接执行网络策略、负载均衡、服务发现与可观测性逻辑。eBPF 数据平面运行在内核，无需用户态代理绕行，吞吐与延迟优于传统路径。它支持 socket 级负载均衡、高效转发与细粒度安全策略，是服务网格数据平面的现代实现。
本题考察 Cilium 与 eBPF。核心是"eBPF 内核数据平面替代 iptables"。作答时说明其性能与功能优势。
eBPF 在 Katran 的应用（L4 负载均衡）是什么？它如何实现高性能负载均衡？
Katran 是 Facebook 的 L4 负载均衡器，用 XDP/eBPF 在网卡驱动层处理数据包，实现高性能的 L4 转发与负载均衡，无需进入完整网络栈。它利用 eBPF map 存储后端映射，XDP 在报文到达时直接做关键决策与转发，吞吐极高。Katran 展示了 eBPF/XDP 在超大规模网络基础设施中的应用价值。
本题考察 Katran。核心是"XDP/eBPF 在驱动层做 L4 转发"。作答时说明其高吞吐实现。
eBPF 的安全性如何通过 bounded loops、pointer 校验来保证？
eBPF 程序只允许有界循环（bounded loops），循环次数必须在运行前可证明有界，防止无限循环占用 CPU；verifier 对指针进行严格校验，追踪指针的来源与范围，禁止任意指针运算与未验证的指针访问，防止越界与内核地址泄露。这些限制让 eBPF 程序可静态验证，保证在内核安全运行。
本题考察 eBPF 安全机制。核心是"有界循环 + 指针校验"。作答时说明 verifier 如何保证活性与安全。
AF_XDP（XDP socket）的零拷贝网络接收是什么？它如何减少拷贝？
AF_XDP 是专为 XDP 设计的 socket，让用户态程序直接访问网卡接收的帧缓冲区，数据包经 XDP 后直接交用户态处理，无需拷贝到内核网络栈。用户态通过 AF_XDP 的环形队列获取帧，实现零拷贝接收。它适合需要高性能收包的应用（如 DP 加速、高性能网络），减少内核与用户态之间的数据搬移。
本题考察 AF_XDP。核心是"用户态直接访问帧 + 零拷贝收包"。作答时说明其减少拷贝的机制。
XDP 的三种模式 native、offloaded、generic 有什么区别？各自的适用场景是什么？
XDP 有三种模式：native 把程序挂载到网卡驱动层，在收包最早期处理，性能最高；offloaded 把程序卸载到支持 XDP 的网卡硬件执行，零 CPU 开销；generic 通过软件模拟在非 XDP 驱动上运行，功能兼容但性能最低。工程按硬件支持与性能需求选择模式，native 最常用，offloaded 需特定网卡。
本题考察 XDP 模式。核心是"驱动层/硬件卸载/软件回退"的层次。作答时说明各模式的性能与适用场景。
XDP_DROP、XDP_PASS、XDP_TX、XDP_REDIRECT、XDP_ABORTED 这些返回值分别代表什么动作？
XDP 程序返回的动作决定报文处理：XDP_DROP 丢弃报文；XDP_PASS 放行进入正常内核网络栈；XDP_TX 从原网卡回发；XDP_REDIRECT 把报文重定向到其他网卡或 AF_XDP socket；XDP_ABORTED 表示程序出错，报文被丢弃。这些动作让 XDP 在收包早期直接决定报文去向，实现高性能处理。
本题考察 XDP 动作。核心是"各返回值对应报文去向"。作答时说明丢弃、放行、转发、重定向的语义。
XDP（eXpress Data Path）的网卡驱动层钩子是什么？它在哪里执行？
XDP 的钩子位于网卡驱动接收路径的最早期，在分配 skb、进入内核网络栈之前执行。程序此时直接访问报文缓冲区，可快速决定丢弃、放行或转发，避免后续的分配与协议栈处理开销。因在驱动层执行，XDP 能以极低开销处理报文，是高性能包处理的基石。
本题考察 XDP 钩子位置。核心是"驱动层收包早期、skb 分配前"。作答时说明其位置带来的性能优势。
eBPF 程序类型 XDP、tc、socket、kprobe、tracepoint、perf_event 各挂载在什么位置？适用场景如何区分？
eBPF 程序类型决定挂载位置与可用 helper：XDP 挂载网卡驱动收包层，tc 挂载流量控制 qdisc，socket 挂载 socket 层，kprobe 挂载内核函数入口，tracepoint 挂载静态追踪点，perf_event 挂载性能事件。网络场景用 XDP/tc/socket，内核追踪用 kprobe/tracepoint，性能分析用 perf_event。按目标位置选择类型。
本题考察 eBPF 程序类型。核心是"类型决定挂载点与场景"。作答时说明各类型与用途的对应。
tc（traffic control）的 ingress/egress qdisc 与 clsact 是什么？eBPF 如何挂载到 tc 路径？
tc 的 ingress/egress qdisc 分别处理入站与出站流量，eBPF 程序可挂载到这些路径执行分类与转发。clsact 是专为 eBPF 设计的 classless 分类器，比传统 qdisc 更轻量，可同时挂载 ingress/egress 的 eBPF 程序。tc eBPF（如 BPF_PROG_TYPE_SCHED_CLS）在 skb 构建后处理，适合需要访问完整网络栈信息的场景。
本题考察 tc eBPF。核心是"ingress/egress qdisc + clsact 挂载"。作答时说明 tc 路径的位置与用途。
BPF skeleton 与 libbpf 的高级封装是什么？它如何简化 eBPF 程序开发？
libbpf 提供加载、验证、挂载 eBPF 程序与 map 的管理 API，BPF skeleton 由 bpftool 根据 BPF 源生成 C 结构，自动封装加载、初始化、销毁流程，绑定 map 与程序的访问。开发只需引用 skeleton 结构即可完成加载与数据交换，减少样板代码。libbpf + skeleton 是现代 eBPF 开发的推荐方式，配合 CO-RE 实现可移植。
本题考察 BPF skeleton。核心是"libbpf 加载管理 + skeleton 自动封装"。作答时说明其简化开发的作用。
XDP 与 AF_XDP 的吞吐边界是什么？它们能在什么程度达到线速？
XDP 在驱动层处理报文，AF_XDP 让用户态直接访问帧，二者结合可接近网卡线速收包。吞吐边界受限于网卡硬件、CPU 核心数、XDP 模式（native/offloaded）与用户态处理能力。offloaded 模式由硬件执行可完全线速，native 需多核分担。AF_XDP 免拷贝减少了 CPU 占用，但用户态处理仍是瓶颈。工程上按报文大小与核心数评估。
本题考察 XDP/AF_XDP 吞吐。核心是"驱动层+零拷贝逼近线速，受硬件与核数限制"。作答时说明边界因素。
XDP 在驱动层、skb 分配之前处理报文，TC 在 skb 已构建后处理，两者在网卡加速路径上的位置与性能差异是什么？
XDP 在网卡驱动层、skb 分配之前处理报文，可直接访问原始帧，规避 skb 分配与协议栈开销，性能最高；TC 在 skb 已构建后处理，能访问更多网络栈信息但多出 skb 分配成本。因此 XDP 更快但缺失部分栈信息，TC 更通用但略慢。高性能收包场景优先 XDP，需要栈信息时用 TC。
本题考察 XDP 与 TC 位置。核心是"skb 前 vs skb 后"。作答时说明两者性能差异与信息可用性。
BCC 工具目录中的 biolatency、biosnoop、tcpconnect、execsnoop 等工具分别用于什么诊断？
BCC 的 tools 目录提供大量现成 eBPF 工具：biolatency 统计块 I/O 延迟直方图，biosnoop 实时显示块 I/O 事件，tcpconnect 追踪 TCP 连接建立，execsnoop 追踪进程执行。它们基于 BCC 的 eBPF 程序，用于快速定位 I/O、网络与进程问题。这类工具是 eBPF 可观测性的开箱即用资源。
本题考察 BCC 工具。核心是"各工具对应不同诊断对象"。作答时说明工具用途与 BCC 的价值。
eBPF 程序的"受限 C"编译如何通过 BCC（BPF Compiler Collection）的 LLVM IR 完成？
BCC 把内嵌的受限 C 源码通过 Clang/LLVM 编译为 BPF 目标代码，生成 eBPF 字节码，再经 verifier 验证后加载。LLVM 的 BPF 后端承担受限 C 到 eBPF 指令的翻译与优化。BCC 在运行时用 Python 注入 C 源码并编译，简化开发。LLVM IR 编译是 eBPF 程序从源码到可执行字节码的关键环节。
本题考察 BCC 编译链。核心是"Clang/LLVM 把受限 C 编译为 eBPF 字节码"。作答时说明编译过程。
BCC 在故障诊断（off-CPU 分析）中的应用是什么？它如何定位阻塞原因？
off-CPU 分析用于定位线程长时间不在 CPU 上（被阻塞、等待）的原因，与 on-CPU 采样互补。BCC 的 offcputime 工具通过追踪进程被调度离开 CPU 的时间与栈，聚合出阻塞原因与耗时分布，帮助定位锁等待、I/O 阻塞等性能问题。off-CPU 分析是 BCC 故障诊断的重要应用。
本题考察 off-CPU 分析。核心是"追踪非 CPU 时间定位阻塞原因"。作答时说明 offcputime 的作用。
bpftrace 的"One-Liner"工具（biolatency、tcplife、naptime）是什么？它们如何快速诊断？
bpftrace 的 One-Liner 是单行命令即可完成的 eBPF 追踪，如 biolatency 统计块 I/O 延迟、tcplife 追踪 TCP 连接生命周期、naptime 统计睡眠时长。它们无需编写完整脚本，适合快速诊断。bpftrace 提供简洁的探针语法，One-Liner 让运维人员快速获得性能数据。
本题考察 bpftrace One-Liner。核心是"单行命令快速诊断"。作答时说明其用法与场景。
bpftrace 的"单行命令"模式（如 bpftrace -e 'kprobe:tcp_connect { @start[tid] = nsecs; }'）怎么写？它如何工作？
bpftrace 的 -e 单行模式直接给出探针与动作，如 '@start[tid] = nsecs' 在 kprobe:tcp_connect 触发时记录每个线程的起始时间。语法为 探针 { 动作 }，动作中可用内置变量（tid、nsecs）与 map（@start）聚合数据。单行模式适合快速原型验证，无需创建脚本文件。
本题考察 bpftrace 单行语法。核心是"探针{动作} + 内置变量/map"。作答时说明语法与执行。
bpftrace 的内置变量 pid、tid、cpu、comm、nsecs、kstack、ustack 分别表示什么？如何使用？
bpftrace 内置变量提供追踪上下文：pid 是进程 ID，tid 是线程 ID，cpu 是当前 CPU，comm 是进程名，nsecs 是当前纳秒时间戳，kstack 是内核栈，ustack 是用户栈。它们可在动作中直接使用，用于标识来源、聚合时间与输出栈。内置变量让追踪脚本简洁且信息丰富。
本题考察 bpftrace 内置变量。核心是"各变量含义与用途"。作答时说明变量在追踪中的作用。
bpftrace 的聚合操作 @count、@hist、@lquantize、@stats、@join 分别用于什么统计？
bpftrace 的聚合操作：@count 计数，@hist 输出对数直方图，@lquantize 输出线性直方图，@stats 输出 sum/avg/min/max 等统计，@join 拼接字符串。它们以 map 为键聚合数据，在程序结束时统一打印。聚合操作让追踪脚本能快速得出分布与统计结论。
本题考察 bpftrace 聚合。核心是"各聚合函数对应统计方式"。作答时说明计数、直方图、统计的用途。
bpftrace 在性能诊断（off-CPU、syscall latency）中的实战是什么？如何定位这些问题？
bpftrace 可用 kprobe 追踪 syscall 入口与出口，计算耗时分布，定位慢系统调用；用调度器追踪（sched switch）聚合 off-CPU 时间，定位阻塞。实战中先采样 syscall latency 找出热点，再用 off-CPU 分析定位等待原因，结合栈输出定位代码路径。bpftrace 的灵活探针让这些诊断快速落地。
本题考察 bpftrace 实战。核心是"syscall latency + off-CPU 定位"。作答时说明诊断流程。
perf lock 的锁争用分析是什么？它如何定位锁竞争问题？
perf lock 通过内核锁事件追踪锁的获取与释放，统计锁争用次数、等待时间与持有者，定位高争用锁。它利用 tracepoint 记录锁操作，输出争用热榜与栈，帮助识别自旋锁、互斥锁等瓶颈。perf lock 是锁性能分析的关键工具。
本题考察 perf lock。核心是"追踪锁事件统计争用"。作答时说明其定位锁瓶颈的方法。
perf mem 的内存访问采样与 TLB miss 分析是什么？它如何定位内存性能问题？
perf mem 通过硬件事件采样内存访问，统计访问的内存层级（L1/L2/DRAM）、延迟与地址，定位缓存命中率低与内存访问热点；结合 TLB 事件可分析 TLB miss，识别页表访问开销。perf mem 帮助定位缓存未命中、TLB 未命中等内存性能瓶颈，指导优化数据布局。
本题考察 perf mem。核心是"内存层级采样 + TLB miss 分析"。作答时说明其定位内存瓶颈的方法。
perf report 的符号解析（symbol resolution）与 --symfs 边界是什么？如何保证符号可读？
perf report 把采样地址解析为函数符号，需要符号表或调试信息。若二进制已 strip 或缺少调试信息，符号无法解析，需用 --symfs 指定符号目录，或通过 build-id 关联调试文件。符号解析的边界是"信息是否可用"，缺少符号表时只能显示地址。
本题考察 perf report 符号解析。核心是"符号解析依赖调试信息/符号表"。作答时说明 --symfs 与 strip 的边界。
perf script 的原始事件流输出与 Python 脚本扩展是什么？它如何自定义分析？
perf script 输出采样事件的原始流（时间、pid、栈、字段），供后续分析；perf 支持 Python 脚本扩展，可在事件触发时调用脚本处理数据，实现自定义的可视化与统计。perf script 的原始输出与 Python 扩展让 perf 数据能被灵活加工，满足复杂分析需求。
本题考察 perf script。核心是"原始事件流 + Python 扩展"。作答时说明其自定义分析能力。
perf 的子命令 record、report、stat、script、top、lock、kmem 分别用于什么？
perf 子命令分工：record 采样记录，report 分析采样结果，stat 统计计数事件，script 输出原始事件流，top 实时展示热点，lock 分析锁争用，kmem 分析内核内存。它们组合覆盖性能分析的采样、统计、实时与专项场景，是 Linux 性能分析的主力工具。
本题考察 perf 子命令。核心是"各子命令对应分析类型"。作答时说明 record/report/stat 等用途。
perf c2c 的 cache-to-cache（false sharing）分析是什么？它如何定位缓存一致性开销？
perf c2c 利用硬件缓存一致性事件检测 cache-to-cache 传输，定位因多个 CPU 访问同一缓存行不同字段导致的 false sharing（伪共享）。它汇总各缓存行的访问方与次数，识别频繁的 C2C 传输，帮助定位缓存行竞争带来的性能开销。perf c2c 是识别伪共享与缓存竞争的关键工具。
本题考察 perf c2c。核心是"采样 C2C 传输定位伪共享"。作答时说明其检测缓存竞争的机制。
ftrace 的"trigger"（hist、snapshot、stacktrace、offcpu）是什么？它们如何扩展事件追踪？
ftrace 的 trigger 是挂载到事件上的动作，扩展事件处理：hist 生成事件字段的直方图，snapshot 在事件触发时保存快照，stacktrace 记录内核栈，offcpu 记录离 CPU 时间。它们通过 tracefs 的 trigger 文件配置，无需重编译即可实现聚合与诊断。trigger 让 ftrace 从简单日志升级为可分析工具。
本题考察 ftrace trigger。核心是"trigger 动作扩展事件处理"。作答时说明 hist/snapshot 等用途。
BCC 工具的 USDT（User Statically-Defined Tracing）静态用户态探针是什么？它如何追踪用户态程序？
USDT（User Statically-Defined Tracing）是应用在源码中预埋的静态探针（如 DTRACE_PROBE 宏），编译后探针位置与参数固定。BCC 通过 uprobes 或 USDT 支持追踪这些探针，无需修改应用代码即可采集用户态事件。USDT 稳定、开销可控，适合需要与应用语义绑定的观测，生产可观测性常优先使用。
本题考察 USDT。核心是"静态预埋探针 + 稳定追踪"。作答时说明其与应用语义绑定的价值。
BCC 工具的 kprobe 动态内核函数插桩是什么？它如何追踪内核函数？
kprobe 是动态内核插桩机制，在任意内核函数入口（kprobe）或出口（kretprobe）设置探针，无需重编译内核即可追踪函数调用与返回值。BCC 封装 kprobe 供用户态程序使用，可追踪内核函数、参数与返回。kprobe 灵活但依赖内核内部符号，可能随内核版本变化。
本题考察 kprobe。核心是"动态插桩内核函数 + 灵活性与版本依赖"。作答时说明其追踪与局限。
BCC 工具的 tracepoint 静态内核事件是什么？它如何追踪？
tracepoint 是内核预定义的静态追踪点，分布在关键路径（sched、irq、block、net 等），接口稳定且有文档化参数。BCC 通过 tracepoint 追踪这些事件，相比 kprobe 更稳定、开销可控，适合生产可观测性。tracepoint 不依赖内核内部函数符号，跨版本兼容性更好。
本题考察 tracepoint。核心是"静态追踪点、稳定接口"。作答时说明其与 kprobe 的稳定性差异。
BCC 工具的 uprobes 用户态函数插桩是什么？它如何追踪用户态函数？
uprobe 在用户态进程的指定函数入口（或 uretprobe 出口）动态插桩，无需修改应用源码即可追踪函数调用。BCC 通过 uprobe 结合函数地址或符号追踪用户态函数，用于分析应用内部热点。uprobe 灵活但热路径上有开销，需谨慎使用。
本题考察 uprobe。核心是"动态插桩用户态函数"。作答时说明其用途与开销。
BCC 工具的"BPF map 输出"（hash、histogram、stack）是什么？它如何聚合数据？
BCC 工具在内核用 BPF map 聚合数据，再在用户态读取与展示：hash 存储键值统计，histogram 存储直方图分布，stack 存储调用栈聚合。内核侧更新 map，用户态轮询或定时读取并格式化输出。这种"内核聚合 + 用户态展示"模式是 BCC 工具的核心，减少数据搬运。
本题考察 BPF map 输出。核心是"内核 map 聚合 + 用户态读取"。作答时说明 hash/histogram/stack 的用途。
BCC 的 Python/C++ 双前端（BPF prog 与 perf event 的协同）是什么？它如何工作？
BCC 提供 Python 与 C++ 双前端，用户既可用 Python 快速原型，也可用 C++ 高性能集成。前端加载内嵌 C 的 BPF 程序，并通过 perf event 或 map 获取内核数据。BPF prog 负责内核侧采集，perf event 提供事件流，前端协同处理展示。双前端让 BCC 兼顾易用性与性能。
本题考察 BCC 双前端。核心是"Python/C++ 前端 + BPF prog + perf event"。作答时说明其协同机制。
BCC 的 bpf_trace_printk、bpf_get_current_pid_tgid、bpf_probe_read 这些 helper 各有什么作用？
bpf_trace_printk 用于在 eBPF 程序内打印调试日志；bpf_get_current_pid_tgid 返回当前进程的 pid 与 tgid；bpf_probe_read 用于安全地读取用户态或内核内存（避免直接解引用指针）。这些 helper 是 eBPF 程序常用的基础能力，分别用于输出、获取上下文与安全内存访问。
本题考察 BCC helper。核心是"各 helper 的用途"。作答时说明打印、进程信息与安全读的作用。
BCC 的 bpftrace 兼容语法与工具迁移是什么？两者如何关联？
bpftrace 是更高级的 eBPF 追踪语言，语法简洁，底层也基于 BPF；BCC 则提供更底层的 Python/C++ 接口。许多 BCC 工具与 bpftrace 脚本功能等价，bpftrace 用抽象简化了探针与 map 操作。工具可基于 bpftrace 快速重写原 BCC 逻辑，或反之在复杂场景用 BCC 提供更多控制。两者互补，可迁移。
本题考察 BCC 与 bpftrace。核心是"bpftrace 抽象简化、与 BCC 等价"。作答时说明两者关系与迁移。
BCC 工具的"性能开销"与生产环境适用性如何？使用时应考量什么？
BCC 工具的开销来自探针触发（kprobe/uprobe/tracepoint）与数据采集，高频路径上可能显著。tracepoint 与 USDT 开销较低、可预测，适合生产；kprobe/uprobe 依赖地址解析且热路径开销大，需谨慎。生产环境应选择稳定、低开销的探针，控制采样频率与聚合，避免影响业务性能。
本题考察 BCC 开销。核心是"探针类型决定开销、生产选稳定低开销"。作答时说明适用性考量。
BCC 的 bpf_override_return 修改返回值的能力是什么？它有什么限制？
bpf_override_return 允许 eBPF 程序直接修改被探测内核函数的返回值，甚至跳过原函数逻辑，用于故障注入或快速失败。它有严格限制：只能在 kprobe 上使用，被探测函数须在允许列表，且修改返回值可能影响内核一致性，需谨慎。此能力多用于测试与故障演练。
本题考察 bpf_override_return。核心是"修改内核函数返回值 + 严格限制"。作答时说明其用途与约束。
bpftrace 与 eBPF map 的交互（@map[k] = v）是什么？它如何聚合数据？
bpftrace 用 @map[k] = v 语法操作 map，如 @start[tid] = nsecs 或以 @count[proto] 聚合按键计数。map 以键聚合数据，程序结束时打印。bpftrace map 隐藏了底层 eBPF map 细节，提供简洁的聚合接口。@map[k] = v 是 bpftrace 数据处理的核心。
本题考察 bpftrace map。核心是"@map 键值聚合语法"。作答时说明其聚合与输出机制。
bpftrace 的探针类型 kprobe、kretprobe、uprobe、uretprobe、tracepoint、software、hardware 分别用于什么？
bpftrace 探针类型：kprobe/kretprobe 追踪内核函数入口/出口，uprobe/uretprobe 追踪用户态函数入口/出口，tracepoint 追踪静态内核事件，software 追踪软件事件（如周期、上下文切换），hardware 追踪硬件事件（如 CPU 周期、缓存未命中）。按目标位置与事件类型选择探针，实现分层追踪。
本题考察 bpftrace 探针。核心是"各探针对应追踪目标"。作答时说明内核/用户态/事件探针的分类。
bpftrace 的控制流（if/else、for、while、switch）如何使用？它如何编写复杂逻辑？
bpftrace 支持 if/else、for、while、switch 等控制流，在动作块内实现条件判断与循环处理。它们与内置变量、map 结合，可编写复杂追踪逻辑（如按条件聚合、循环遍历）。控制流受 eBPF 有界循环约束，循环次数需有限。bpftrace 的控制流让追踪脚本可表达更复杂业务。
本题考察 bpftrace 控制流。核心是"条件/循环实现复杂逻辑 + 有界约束"。作答时说明控制流与约束。
bpftrace 的输出格式化 printf、time、strftime 如何使用？它们如何输出数据？
bpftrace 用 printf 按格式输出字段与变量，time 打印当前时间戳，strftime 把时间格式化为人读日期串。三者配合输出结构化、可读的追踪结果。printf 支持 %d、%s 等格式，time 用于标记事件时间，strftime 提供可读时间。输出格式化让追踪数据便于分析。
本题考察 bpftrace 输出。核心是"printf/time/strftime 的格式化"作用。作答时说明三者用途。
bpftrace 的"脚本模式"（直接执行 .bt 文件）如何实现可复用工具？它有什么优势？
bpftrace 的脚本模式（直接执行 .bt 文件）把多个探针与动作写入脚本，便于复用与维护。脚本可定义结构化探针、聚合与输出，构成可共享的追踪工具。相比单行命令，脚本模式支持复杂逻辑与参数化，适合构建可复用的性能诊断工具。
本题考察 bpftrace 脚本。核心是"脚本模式实现可复用工具"。作答时说明其相对单行命令的优势。
bpftrace 与 BCC 的等价性如何体现？bpftrace 的抽象如何简化追踪？
bpftrace 与 BCC 底层都基于 eBPF，功能等价，但 bpftrace 用更高级的脚本语法抽象了探针、map 与聚合，代码更简洁；BCC 提供更底层的 Python/C++ 控制。bpftrace 便于快速原型，BCC 便于需要精细控制或程序化集成的场景。两者等价的能力可互相迁移，选择取决于简洁 vs 控制。
本题考察 bpftrace 抽象。核心是"等价但更抽象、更简洁"。作答时说明抽象简化与选择。
bpftrace 在安全检测（可疑 syscall）中的应用是什么？它如何追踪可疑行为？
bpftrace 可追踪 syscall 事件，检测可疑行为，如异常 execve、文件写入、网络连接等。通过 tracepoint syscalls 或 kprobe 记录进程、参数与时间，聚合异常模式，用于安全审计与行为检测。bpftrace 能快速编写安全探针，发现可疑活动，是安全可观测性的轻量手段。
本题考察 bpftrace 安全检测。核心是"追踪 syscall 检测可疑行为"。作答时说明其安全应用。
bpftrace 的"安全限制"（bounded loops、cap 检查）是什么？它如何保证安全？
bpftrace 生成的 eBPF 程序受 verifier 限制：循环必须可证明有界，防止无限循环；指针与内存访问受校验；加载追踪程序通常需要 CAP_BPF/CAP_SYS_ADMIN 等权限。这些限制保证 bpftrace 追踪在生产环境安全运行，不破坏内核。cap 检查防止非特权用户滥用。
本题考察 bpftrace 安全限制。核心是"有界循环 + 权限检查"。作答时说明限制与安全。
perf annotate 的指令级源码映射是什么？它如何定位热点指令？
perf annotate 把采样结果映射到具体指令与源码行，展示每个函数的指令级热度，标出热点指令。它结合反汇编与源码高亮，帮助定位性能瓶颈的具体代码位置。perf annotate 是"哪条指令最慢"的答案，用于微优化与热点分析。
本题考察 perf annotate。核心是"指令级采样映射定位热点指令"。作答时说明其定位能力。
perf record 的采样方式周期采样（H/W）与事件采样（S/W）有什么区别？各自用于什么？
perf record 支持硬件周期采样（H/W，按 CPU 周期/时钟节拍采样）与软件事件采样（S/W，按特定事件如上下文切换、page fault 采样）。周期采样适合 CPU 热点分析，事件采样适合特定事件归因。硬件采样开销低、精度高，软件采样针对操作系统事件。按分析目标选择。
本题考察 perf 采样方式。核心是"硬件周期 vs 软件事件的差异"。作答时说明各自适用场景。
perf probe 的动态探针添加是什么？它如何为 perf 添加自定义事件？
perf probe 可在内核函数或用户函数上动态添加探针，生成自定义事件供 perf record/stat 使用。它把函数位置和参数转换为可采样事件，无需重编译内核。perf probe 结合 kprobe/uprobe 机制，让 perf 能追踪特定函数，是 perf 扩展事件能力的关键。
本题考察 perf probe。核心是"动态添加探针生成自定义事件"。作答时说明其扩展能力。
perf 与 bpftrace 的协同（perf 提供硬件事件，bpftrace 提供探针）是什么？如何组合使用？
perf 提供丰富的硬件性能事件（CPU 周期、缓存、分支等），bpftrace 提供灵活的探针与追踪逻辑。组合使用：用 perf 获取硬件事件定位热点，用 bpftrace 追踪具体函数与上下文深入分析。二者互补，构成"硬件采样 + 软件追踪"的完整分析链。
本题考察 perf 与 bpftrace 协同。核心是"硬件事件 + 探针互补"。作答时说明组合分析的价值。
perf 在容器内（cgroup-aware）的 events 边界是什么？如何限定采样范围？
perf 支持 cgroup-aware 采样，通过 --cgroup 或 cgroup 过滤限定事件来源，使采样只包含指定 cgroup（容器）的进程。这把性能分析限定在容器边界内，避免混合其他容器的数据。容器内 perf 还需注意权限与命名空间边界。perf 的 cgroup 支持让容器性能分析更精准。
本题考察 perf 容器边界。核心是"cgroup 过滤限定采样范围"。作答时说明容器内分析的限定。
ftrace 的 filter（set_ftrace_filter）与 events 过滤是什么？它们如何控制追踪范围？
ftrace 的 set_ftrace_filter 用于限定只追踪特定函数，events 支持按字段过滤（如进程、pid），从而控制追踪范围与数据量。filter 让追踪聚焦于目标函数/事件，减少无关日志。ftrace 的过滤机制是高效追踪的关键。
本题考察 ftrace filter。核心是"函数/事件过滤控制范围"。作答时说明过滤的作用。
ftrace 的"events"（sched、irq、timer、block、netfs）子目录结构是什么？它如何组织事件？
ftrace 的 events 目录按子系统分类，如 sched、irq、timer、block、netfs 等子目录，每个子目录含对应的事件（如 sched:sched_switch），可单独启用/禁用并配置过滤。这种按子系统组织的结构让事件管理清晰，便于按需开启追踪。用户通过 tracefs 的 events 路径操作。
本题考察 ftrace events 结构。核心是"按子系统目录组织事件"。作答时说明其组织与启用方式。
ftrace 的"function tracer"（function）与"function graph"（function_graph）模式有什么区别？
ftrace 的 function 模式记录函数调用序列（入口），function_graph 模式记录函数调用关系图，包含入口与返回、嵌套深度与时长，能呈现完整的调用树。function_graph 提供更丰富的调用结构信息，但开销更大。按需选择：function 看调用序列，function_graph 看调用图与耗时。
本题考察 ftrace 模式。核心是"function 序列 vs function_graph 调用图"。作答时说明两者差异与开销。
ftrace 的"stack trace"与 function_graph 的递归调用图如何工作？它们如何展示调用栈？
ftrace 的 stack trace 在事件触发时记录当前内核栈，function_graph 的递归调用图通过记录的入口/返回呈现递归调用的嵌套结构。二者都展示调用栈相关信息，stack trace 反映单点栈，function_graph 反映完整调用树。它们帮助定位递归深度与调用路径。
本题考察 stack trace 与 function_graph。核心是"栈记录 vs 调用树"。作答时说明二者展示调用栈的方式。
ftrace 的"tracefs"（/sys/kernel/tracing）与 debugfs 历史是什么？为什么迁移到 tracefs？
ftrace 最初挂载在 debugfs（/sys/kernel/debug/tracing），后来迁移到独立的 tracefs（/sys/kernel/tracing），因为 tracefs 是专为追踪设计的文件系统，权限与挂载更安全、更规范，避免与调试文件混杂。tracefs 提供 trace、trace_pipe、events 等专用文件。迁移后 ftrace 使用更清晰、更安全。
本题考察 tracefs。核心是"从 debugfs 迁移到专用 tracefs"。作答时说明迁移原因与结构。
ftrace 的 function、function_graph、irqsoff、preemptoff、wakeup、wakeup_rt 等 tracer 各用于什么？
ftrace 的 tracer 面向不同分析：function 追踪函数序列，function_graph 追踪调用图，irqsoff 测量中断关闭的最长延迟，preemptoff 测量抢占关闭延迟，wakeup/wakeup_rt 测量任务唤醒延迟。这些延迟 tracer 用于实时性与调度分析，评估系统最坏情况延迟。
本题考察 ftrace tracer。核心是"不同 tracer 面向不同延迟/调用分析"。作答时说明各 tracer 用途。
trace-cmd 的"录制-回放"模式（trace-cmd record / report）是什么？它如何工作？
trace-cmd 的 record 命令录制内核追踪数据到文件，report 命令读取并格式化回放，实现"录制-回放"分析。录制时可用 trace-cmd 配置 ftrace 事件，回放时解析保存的数据，便于离线分析共享。trace-cmd 提供命令行友好接口，是 ftrace 的高层封装工具。
本题考察 trace-cmd。核心是"record 录制 + report 回放"。作答时说明录制-回放工作流。
ftrace 的"trace_printk" 内核内嵌打印是什么？它如何在内核代码中打印？
trace_printk 是内核代码中可用的打印函数，输出直接进入 ftrace 的 trace 缓冲区，格式类似 printk，但写入追踪日志而非内核日志。它适合在内核调试时临时打印，配合 trace 读取。trace_printk 产生的输出可用 trace 文件查看，是 ftrace 调试内核的重要手段。
本题考察 trace_printk。核心是"内核内嵌打印到追踪缓冲区"。作答时说明其与 printk 的差异。
ftrace 在实时系统（PREEMPT_RT）的延迟测量是什么？它如何评估实时性？
在 PREEMPT_RT 实时系统中，ftrace 的 irqsoff、preemptoff、wakeup、wakeup_rt 等 tracer 测量各阶段延迟，评估系统最坏情况延迟，验证实时性。通过追踪中断关闭、抢占关闭与唤醒延迟，定位实时性瓶颈。ftrace 是实时系统延迟分析与调优的关键工具。
本题考察 ftrace 实时性。核心是"延迟 tracer 测量最坏情况延迟"。作答时说明实时性评估方法。
ftrace 的"dynamic events"（dynamic_debug）是什么？它如何动态管理事件？
ftrace 的 dynamic events 允许在运行时动态添加/删除追踪事件（如经 dynamic_debug 与传统 kprobe/uprobe 事件），无需重启或重编译内核。用户通过 tracefs 的 dynamic_events 文件配置探针，实现按需追踪。dynamic events 让 ftrace 追踪更灵活，支持动态的诊断。
本题考察 dynamic events。核心是"运行时动态管理追踪事件"。作答时说明其灵活性。
eBPF verifier 的基本校验流程涵盖哪些检查（寄存器状态、指针边界、内存访问范围与循环限制）？
eBPF verifier 逐指令模拟程序，追踪寄存器的类型与取值范围，校验指针的来源与边界，验证内存访问是否在允许范围内，并检查循环是否有界。这些检查保证程序不越界、不空指针、不死循环。verifier 的校验流程是 eBPF 安全运行的核心保障。
本题考察 verifier 流程。核心是"寄存器/指针/内存/循环四类检查"。作答时说明各检查的作用。
eBPF 程序从编译、验证、JIT 到挂载执行的完整生命周期包含哪些步骤？
eBPF 程序生命周期：编译（Clang/LLVM 把受限 C 编译为 eBPF 字节码）→ 加载（通过 bpf 系统调用）→ 验证（verifier 静态校验）→ JIT 编译（翻译为原生指令）→ 挂载（attach 到指定探针）→ 执行（事件触发时运行）→ 数据通过 map 输出。各步骤保证程序安全地加载并以高性能执行。
本题考察 eBPF 生命周期。核心是"编译-验证-JIT-挂载-执行"流程。作答时说明各阶段作用。
ftrace ring buffer 的 per-CPU buffer 与 cross-CPU 同步的工程价值是什么？
ftrace ring buffer 为每个 CPU 分配独立缓冲区，CPU 写自己的 buffer 无需跨 CPU 锁，实现低开销、无锁的写入。跨 CPU 同步（如汇总）需要额外处理，但写入路径免锁使追踪开销极小。per-CPU buffer 是 ftrace 高性能追踪的关键设计。
本题考察 ring buffer。核心是"per-CPU 无锁写入 + 跨 CPU 同步"。作答时说明其性能价值。
BPF ELF 的 BPF_PROG / BPF_MAP 在 libbpf CO-RE 的工程价值是什么？
BPF 程序编译为 ELF 文件，其中的节（如 SEC 宏标注的 BPF_PROG、BPF_MAP）标识程序与 map 的类型。libbpf 解析 ELF 节，自动加载程序与创建 map，配合 CO-RE 通过 BTF 重定位访问内核结构。BPF ELF 的节组织让 libbpf 能自动化管理加载，是 CO-RE 可移植的基础。
本题考察 BPF ELF。核心是"节标注程序/map + libbpf 解析与 CO-RE"。作答时说明其工程价值。
ringbuf 相比 perf event buffer 在内存共享与多 CPU 事件有序性上做了哪些改进？
ringbuf 相比 perf event buffer 的改进：ringbuf 支持从用户态共享内存直接读取，减少额外拷贝；通过提交机制保证多 CPU 事件按序提交，支持有序性；ringbuf 内存管理更简单，避免 per-CPU 缓冲区的复杂跨 CPU 处理。ringbuf 提供更高效、有序的事件传输，适合可观测性。
本题考察 ringbuf。核心是"共享内存 + 多 CPU 有序性"改进。作答时说明其相对 perf event buffer 的优势。
如何用 eBPF 编写一个统计 TCP 重传或调度延迟分布的工具？数据如何从 map 暴露给用户态？
用 eBPF 程序挂载 tracepoint（如 tcp_retransmit_skb 或 sched_switch），在事件触发时计算延迟或计数，用 BPF map（如 histogram map）聚合分布。内核侧更新 map，用户态通过 bpf_map_lookup 或共享内存读取，格式化输出直方图。方案：内核采集统计 + 用户态轮询读取，实现延迟分布可视化。
本题考察 eBPF 统计工具。核心是"tracepoint 采集 + map 聚合 + 用户态读取"。作答时说明实现流程。
BTF（BPF Type Format）与 CO-RE（Compile Once – Run Everywhere）如何支撑 eBPF 程序跨内核版本可移植？
BTF 提供内核类型与结构布局的元数据，CO-RE 利用 BTF 在加载时对内核结构的字段偏移做重定位，使 eBPF 程序编译一次即可在不同内核版本运行。程序访问内核结构时通过 BTF 重定位到实际偏移，避免硬编码布局。BTF + CO-RE 让 eBPF 程序跨内核可移植，是 libbpf 的关键能力。
本题考察 BTF/CO-RE。核心是"BTF 提供布局 + CO-RE 重定位"。作答时说明可移植机制。
tracepoint 与 kprobe 在稳定性与开销上有何差异？为何生产可观测性更偏好 tracepoint 与 USDT？
tracepoint 是内核预定义的静态追踪点，接口稳定、跨版本兼容、开销可控；kprobe 动态插桩任意内核函数，灵活但依赖内核内部符号，可能随版本变化，热路径开销大。生产可观测性偏好 tracepoint 与 USDT，因为其稳定、文档化、开销可预测，适合长期运行而 kprobe 更适合临时诊断。
本题考察 tracepoint 与 kprobe。核心是"稳定性与开销差异决定生产选择"。作答时说明偏好原因。
eBPF 如何在不修改应用的前提下实现 L4/L7 流量统计、延迟直方图与丢包定位等可观测性能力？
eBPF 通过挂载内核网络路径（XDP、tc、socket、kprobe）在不修改应用的情况下采集流量数据，用 map 聚合 L4/L7 流量统计、延迟直方图与丢包计数。无需应用埋点，eBPF 在内核观测所有流量，结合用户态展示工具实现可观测性。这是 eBPF 零侵入可观测性的核心价值。
本题考察 eBPF 可观测性。核心是"内核探针零侵入采集 + map 聚合"。作答时说明实现方式。
eBPF 辅助函数（helper）的调用约定与返回值语义是什么？为何不能随意调用任意内核函数？
eBPF helper 有严格调用约定，参数与返回值语义明确，如 map 查找返回指针或 NULL，错误返回负错误码。helper 是 verifier 审查过的白名单函数，其行为可验证；任意内核函数可能在 eBPF 上下文中不安全（如睡眠、锁、引用语义未知），故禁止。helper 白名单保证 eBPF 程序可安全验证与执行。
本题考察 helper 约定。核心是"helper 可验证 + 任意函数不安全"。作答时说明调用限制原因。
BPF 程序的尾调用（tail call）如何突破指令数限制？在什么场景下使用？
BPF 尾调用通过 bpf_tail_call 让程序跳转到另一个 eBPF 程序，转移执行且不栈增长，从而把逻辑拆分为多个程序，突破单程序指令数限制。它常用于按需求分派到不同处理程序（如按协议分流），在指令数受限时扩展逻辑。尾调用需程序数组与索引，场景包括协议分发、复杂处理链。
本题考察尾调用。核心是"跳转其他程序突破指令限制"。作答时说明其机制与场景。
eBPF maps 的 HASH、ARRAY、RINGBUF、LRU_HASH、LPM_TRIE 等类型分别适合什么数据结构与查询模式？
eBPF map 类型对应不同数据结构与查询：HASH 适合键值哈希查找，ARRAY 适合固定索引数组访问，RINGBUF 适合按序事件流，LRU_HASH 适合有容量限制的缓存，LPM_TRIE 适合最长前缀匹配（路由/策略）。按数据访问模式与查找复杂度选择，兼顾性能与内存。
本题考察 map 类型匹配。核心是"各类型对应数据结构与查询模式"。作答时说明适用场景。
为何 eBPF 程序默认禁止无界循环与任意指针运算？verifier 的这些限制如何保证内核安全与活性？
无界循环会占用 CPU 导致内核失活（DoS），任意指针运算可能导致越界访问或内核地址泄露，因此 eBPF 禁止。verifier 检查循环有界性、指针来源与边界，保证程序在有限时间内安全终止（活性）且不越界（安全）。这些限制让不可信代码也能安全运行在内核。
本题考察 verifier 限制的意义。核心是"活性（有界循环）与安全（指针校验）"。作答时说明限制的保证。
eBPF 的 XDP、TC、kprobe、tracepoint、uprobe 等程序类型各自挂载在什么位置？适用场景如何区分？
XDP 挂载网卡驱动收包层，TC 挂载流量控制路径，kprobe 挂载内核函数入口，tracepoint 挂载静态追踪点，uprobe 挂载用户态函数。网络快速处理用 XDP/TC，内核追踪用 kprobe/tracepoint，用户态分析用 uprobe。按目标位置与所需信息选择类型。
本题考察程序类型挂载。核心是"位置决定类型、场景区分"。作答时说明各挂载点与场景。
XDP redirect 配合 AF_XDP 如何实现零拷贝收包？相比传统 socket 收包路径省去了哪些开销？
XDP 程序用 XDP_REDIRECT 把报文直接重定向到 AF_XDP socket，用户态经 AF_XDP 队列直接访问帧，无需拷贝到内核网络栈。相比传统 socket 收包，省去了 skb 分配、协议栈处理、数据拷贝到用户态等开销。AF_XDP 零拷贝收包让高性能应用直接获取帧。
本题考察 XDP+AF_XDP 收包。核心是"redirect 到 AF_XDP 免拷贝"。作答时说明省去的开销。
uprobe 挂载到用户态函数入口的开销来自哪里？为何在高频热路径上需谨慎使用？
uprobe 通过替换函数入口指令（断点/跳转）实现插桩，每次调用都触发内核处理，涉及 trap、上下文切换与数据采集，开销相对大。高频热路径上 uprobe 的每次调用开销会显著累计，影响性能。因此热路径需谨慎使用，可改用采样或低开销的静态探针。
本题考察 uprobe 开销。核心是"每次调用触发内核处理开销大"。作答时说明热路径风险。
XDP 的"early hook"零拷贝在网卡到 socket buffer 之间如何实现？
XDP 的 early hook 在网卡驱动收包早期、进入协议栈之前执行，可直接访问原始帧并决定去向。配合 AF_XDP，报文可零拷贝地从网卡到用户态 socket；若放行，则后续构建 skb 进入 socket buffer。early hook 让部分报文在到达 socket buffer 前就被处理或重定向，避免网络栈开销。
本题考察 XDP early hook。核心是"收包早期直接处理/重定向"。作答时说明其零拷贝路径。
ftrace 的"hist" 触发器（基于事件的统计）是什么？它如何聚合事件数据？
ftrace 的 hist trigger 挂在事件上，对事件字段做聚合统计，生成直方图或汇总值（计数、求和、平均值），无需外部工具。用户通过 tracefs 的 trigger 文件配置 hist 键与字段，内核自动聚合。hist trigger 让 ftrace 直接输出事件统计，是轻量的事件分析能力。
本题考察 hist trigger。核心是"事件字段聚合生成统计直方图"。作答时说明其聚合机制。
动态追踪（eBPF、bpftrace、BCC）与 perf、ftrace 的工具链分工是什么？
动态追踪（eBPF、bpftrace、BCC）用于按需动态插入探针，追踪特定函数与事件；perf 用硬件/软件采样做性能分析；ftrace 提供内核追踪与事件。它们分工：perf 采样热点、bpftrace/BCC 动态追踪上下文、ftrace 内核事件追踪。组合使用形成完整分析链。
本题考察工具链分工。核心是"采样、动态追踪、内核事件各司其职"。作答时说明分工协作。
kernelshark 的 GUI 可视化与时间线分析是什么？它如何辅助分析？
kernelshark 是 ftrace 追踪数据的 GUI 工具，以时间线方式可视化事件、进程与 CPU 活动，支持放大、过滤与导航。它把大量追踪事件转化为可读的图形，帮助定位进程调度、中断与延迟问题。kernelshark 是 trace-cmd 数据的主要可视化工具。
本题考察 kernelshark。核心是"GUI 时间线可视化追踪数据"。作答时说明其分析辅助价值。
BPF CO-RE（Compile Once, Run Everywhere）通过 BTF 重定位 kernel struct 的工程价值是什么？
CO-RE 让 eBPF 程序编译一次即可在不同内核版本运行，通过 BTF 在加载时对内核结构字段偏移重定位，避免硬编码。工程价值：无需为每个内核编译专用程序，简化分发与维护，提升可移植性。CO-RE 是生产级 eBPF 工具跨内核部署的关键。
本题考察 CO-RE 价值。核心是"编译一次跨内核 + BTF 重定位"。作答时说明其工程意义。
