HTTP2/gRPC 的协议头部使用 HPACK 算法压缩，使得难以从内核系统调用（eBPF kprobe）中获取真实头部字段，因此现有的解决方案通常依赖 eBPF uprobe。本文介绍 DeepFlow 6.4 中基于 eBPF kprobe 的 HTTP2 压缩头高性能解码能力。

01

关于 HPACK

HTTP2 协议头使用了 HPACK 算法进行压缩，以降低头部字段的带宽消耗。如下图所示，HTTP2 的通信双方会向对方共享自己的压缩字典，该字典由两部分组成：编号 1-61 的静态字典（Static table）和编号大于 61 的动态字典（Dynamic table）。在 HTTP2 消息发送之前，发送方会将头部字段中的 Key 或 Key+Value 使用字典中的数字编码替代。当通信中的某一方认为某个不在字典中的头部也值得压缩时，会在发送消息中告知对端向字典中新增表项。除此之外，对于字符串字段，HPACK 算法中规定使用 Huffman 编码算法对字符串进行压缩，也能有效降低长字符串字段的带宽占用。HPACK 的压缩效果显著，例如 Cloudflare 在一篇文章中表示 HPACK 能够对 HTTP2 头部有 3~4 倍的压缩效果。

02

使用 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) 来了解更多信息。

但是，相比 eBPF kprobe，uprobe 的资源开销更高，而且需要适配不同的语言，因此我们收到了一些通过 kprobe 解码的需求，例如腾讯游戏在 DeepFlow 的落地中就面临了此问题（参见：消灭盲点！腾讯游戏真·全栈观测实践）。

03

使用 eBPF kprobe 解码

安排！DeepFlow 6.4 新增了通过 kprobe 解码 HTTP2/gRPC 压缩头的能力。deepflow-agent 通过自动学习通信双方的压缩字典，能够准确的对压缩头部进行还原。于是，即使不开启 uprobe，调用日志中也能看到所有 DeepFlow 需要的字段信息了：

不仅如此，DeepFlow 6.4 也支持了 RedHat/CentOS 3.10 内核下的 eBPF 能力，欢迎在低版本内核下享用基于 eBPF kprobe 的 HPACK 解码。

不仅如此 x2，除了 eBPF kprobe 以外，对于通过 cBPF 采集到的流量数据，DeepFlow 6.4 也支持了对压缩头的解码，因此即使你的内核版本更低，同样也能享用到此项特性。

这里我们也说明一下此项特性的两点限制：

• 对于 deepflow-agent 启动之前就已经存在的 HTTP2 长连接，已存在的动态字典表项无法解码（但新增的动态字典表项无此限制）
• 当使用 cBPF 时，由于网络中可能存在丢包、重传、乱序等因素，因此对压缩头不的还原可能存在误差（但 eBPF kprobe 无此限制），此项限制我们会在未来版本中逐步消除

04

性能压测

读者看到这里，一定会对「自动学习」、「还原」这类操作产生性能上的担忧，它们会使得 deepflow-agent 占用更多的 CPU、内存资源吗？作为一个金融企业级产品，DeepFlow 在实现此特性时经过了一系列硬核的性能优化和严格的性能压测，本节中我们将会对比关闭动态字典还原、开启动态字典还原两种场景，评估压缩头还原的资源开销。

是的，你没有看错，功能更硬核了，性能也更硬核了。在 DeepFlow 6.4 开启动态字典压缩头还原的情况下，CPU、内存开销比 6.3 降低了 30%。并且，当 TPS 从 7,400 增加到 43,000 时，内存消耗没有增长。

此时不得不再次秀出本文的题图：

05

什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

访问 DeepFlow Demo，体验零插桩、全覆盖、全关联的可观测性。