企业官网建设流程全解析

深圳集团网站建设公司,北京个人注册公司流程和费用,下载类网站怎么做,wordpress加载慢 2017摘要#xff1a;本文介绍了 DeepFlow 新增的基于 eBPF kprobe 的 HTTP2/gRPC 压缩头部高性能解码能力。针对 HTTP2 协议使用 HPACK 算法压缩头部导致难以通过内核探针直接获取字段的问题#xff0c;DeepFlow 通过自动学习通信双方的动态压缩字典#xff0c;实现了无需依赖 u…摘要本文介绍了 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 压缩头高性能解码能力。一、关于 HPACKHTTP2 协议头使用了 HPACK 算法进行压缩以降低头部字段的带宽消耗。如下图所示HTTP2 的通信双方会向对方共享自己的压缩字典该字典由两部分组成编号 1-61 的静态字典Static table和编号大于 61 的动态字典Dynamic table。在 HTTP2 消息发送之前发送方会将头部字段中的 Key 或 KeyValue 使用字典中的数字编码替代。当通信中的某一方认为某个不在字典中的头部也值得压缩时会在发送消息中告知对端向字典中新增表项。除此之外对于字符串字段HPACK 算法中规定使用 Huffman 编码算法对字符串进行压缩也能有效降低长字符串字段的带宽占用。HPACK 的压缩效果显著例如Cloudflare 在一篇文章中表示 HPACK 能够对 HTTP2 头部有 3~4 倍的压缩效果[2]。HTTP2 Header Compression HPACK (by Ilya Grigorik)二、使用 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 kprobeuprobe 的资源开销更高而且需要适配不同的语言因此我们收到了一些通过 kprobe 解码的需求例如腾讯游戏在 DeepFlow 的落地中就面临了此问题参见消灭盲点腾讯游戏真·全栈观测实践。三、使用 eBPF kprobe 解码安排DeepFlow 6.4 新增了通过 kprobe 解码 HTTP2/gRPC 压缩头的能力。deepflow-agent 通过自动学习通信双方的压缩字典能够准确的对压缩头部进行还原。于是即使不开启 uprobe调用日志中也能看到所有 DeepFlow 需要的字段信息了DeepFlow 中的 HTTP2 调用日志不仅如此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 在实现此特性时经过了一系列硬核的性能优化和严格的性能压测本节中我们将会对比关闭动态字典还原、开启动态字典还原两种场景评估压缩头还原的资源开销。版本测试场景TPSAgent CPUAgent MEM6.3关闭动态字典740022.5%942.8 MB6.4开启动态字典kprobe cBPF740016.3%672.6 MB6.4开启动态字典kprobe cBPF4300090.9%602.2 MB是的你没有看错功能更硬核了性能也更硬核了。在 DeepFlow 6.4 开启动态字典压缩头还原的情况下CPU、内存开销比 6.3 降低了 30%。并且当 TPS 从 7,400 增加到 43,000 时内存消耗没有增长。