摘要：本文介绍了 DeepFlow 新增的基于 eBPF kprobe 的 HTTP2/gRPC 压缩头部高性能解码能力。针对 HTTP2 协议使用 HPACK 算法压缩头部导致难以通过内核探针直接获取字段的问题，DeepFlow 通过自动学习通信双方的动态压缩字典，实现了无需依赖 uprobe 即可准确还原压缩头部。该方案不仅降低了对多语言应用的适配成本，还显著减少了资源开销，并在性能压测中展示出更低的 CPU 与内存占用。同时，该能力也支持 cBPF 采集的流量，兼容低版本内核环境。
关键词：DeepFlow、HTTP2/gRPC、HPACK压缩、eBPF kprobe、动态字典学习、压缩头解码、可观测性
HTTP2/gRPC 的协议头部使用HPACK[1]算法压缩，使得难以从内核系统调用（eBPF kprobe）中获取真实头部字段，因此现有的解决方案通常依赖 eBPF uprobe。本文介绍 DeepFlow 6.4 中基于 eBPF kprobe 的 HTTP2 压缩头高性能解码能力。
一、关于 HPACK
HTTP2 协议头使用了 HPACK 算法进行压缩，以降低头部字段的带宽消耗。如下图所示，HTTP2 的通信双方会向对方共享自己的压缩字典，该字典由两部分组成：编号 1-61 的静态字典（Static table）和编号大于 61 的动态字典（Dynamic table）。在 HTTP2 消息发送之前，发送方会将头部字段中的 Key 或 Key+Value 使用字典中的数字编码替代。当通信中的某一方认为某个不在字典中的头部也值得压缩时，会在发送消息中告知对端向字典中新增表项。除此之外，对于字符串字段，HPACK 算法中规定使用 Huffman 编码算法对字符串进行压缩，也能有效降低长字符串字段的带宽占用。HPACK 的压缩效果显著，例如Cloudflare 在一篇文章中表示 HPACK 能够对 HTTP2 头部有 3~4 倍的压缩效果[2]。
二、使用 eBPF uprobe 解码
从上图中可以看到，如果直接使用 eBPF kprobe hook 系统调用，得到的实际上是图中最右侧的压缩数据。此时除了可以借助静态字典解码一部分内容以外，大部分业务字段，特别是和追踪相关的 TraceID、SpanID、X-Request-ID 等都无法稳定获取。
因此，无论是 DeepFlow 还是 Pixie 等其他 eBPF 可观测性项目，通常都使用 uprobe 来获取压缩前的头部字段。这种常规的解决方案本文就不再赘述了，大家也可阅读Observing HTTP/2 Traffic is Hard, but eBPF Can Help (by Yaxiong Zhao)[3]来了解更多信息。
但是，相比 eBPF kprobe，uprobe 的资源开销更高，而且需要适配不同的语言，因此我们收到了一些通过 kprobe 解码的需求，例如腾讯游戏在 DeepFlow 的落地中就面临了此问题（参见：消灭盲点！腾讯游戏真·全栈观测实践）。
三、使用 eBPF kprobe 解码
安排！DeepFlow 6.4 新增了通过 kprobe 解码 HTTP2/gRPC 压缩头的能力。deepflow-agent 通过自动学习通信双方的压缩字典，能够准确的对压缩头部进行还原。于是，即使不开启 uprobe，调用日志中也能看到所有 DeepFlow 需要的字段信息了：
不仅如此，DeepFlow 6.4 也支持了 RedHat/CentOS 3.10 内核下的 eBPF 能力[4]，欢迎在低版本内核下享用基于 eBPF kprobe 的 HPACK 解码。
不仅如此 x2，除了 eBPF kprobe 以外，对于通过cBPF采集到的流量数据，DeepFlow 6.4 也支持了对压缩头的解码，因此即使你的内核版本更低，同样也能享用到此项特性。
这里我们也说明一下此项特性的两点限制：
- 对于 deepflow-agent 启动之前就已经存在的 HTTP2 长连接，已存在的动态字典表项无法解码（但新增的动态字典表项无此限制）
- 当使用 cBPF 时，由于网络中可能存在丢包、重传、乱序等因素，因此对压缩头不的还原可能存在误差（但 eBPF kprobe 无此限制），此项限制我们会在未来版本中逐步消除
四、性能压测
读者看到这里，一定会对「自动学习」、「还原」这类操作产生性能上的担忧，它们会使得 deepflow-agent 占用更多的 CPU、内存资源吗？作为一个金融企业级产品，DeepFlow 在实现此特性时经过了一系列硬核的性能优化和严格的性能压测，本节中我们将会对比关闭动态字典还原、开启动态字典还原两种场景，评估压缩头还原的资源开销。
| 版本 | 测试场景 | TPS | Agent CPU | Agent MEM |
|---|---|---|---|---|
| 6.3 | 关闭动态字典 | 7400 | 22.5% | 942.8 MB |
| 6.4 | 开启动态字典（kprobe + cBPF） | 7400 | 16.3% | 672.6 MB |
| 6.4 | 开启动态字典（kprobe + cBPF） | 43000 | 90.9% | 602.2 MB |
是的，你没有看错，功能更硬核了，性能也更硬核了。在 DeepFlow 6.4 开启动态字典压缩头还原的情况下，CPU、内存开销比 6.3 降低了 30%。并且，当 TPS 从 7,400 增加到 43,000 时，内存消耗没有增长。
