佳能|一文详解用 eBPF 观测 HTTP( 四 ) 智能眼镜|数码

。下图展示了使用Uprobe 观测Go gRPC 流量的基本流程，如其中writeHeader 的函数定义为 func (l *loopyWriter) writeHeader(streamID uint32 endStream bool hf [
hpack.HeaderField onWrite func()) 可以看到明确的Header 文本。Kprobe 与Uprobe 对比从上文可以看出Uprobe 实现简单，且不存在数据退化的问题，但Uprobe 真的完美吗？兼容性：上述方案仅仅是基于Golang gRPC 的特定方法进行探测，也就意味着上述仅能覆盖Golang gRPC 流量的观察，对于Golang 其他HTTP2 库无法支持。多语言性：Uprobe 只能基于方法签名进行探测，更适用于C/GO 这种纯编译型语言，而对于Java 这种JVM 语言，因为运行时动态生成符号表，虽然可以依靠一些javaagent 将java 程序用于Uprobe ，但是相对于纯编译型语言，用户使用成本或改造成本还是会更高一些。稳定性：Uprobe 相对于tracepoint/kprobe 来说是不稳定的，假如探测的函数函数签名有改变，这就意味着Uprobe 程序将无法工作，因为函数注册表的改变将使得Uprobe 无法找到切入点。综合下来2种方案对比如下，可以看到2种方案对于HTTP2（有状态）的观测都存在部分取舍：总结上述我们回顾了HTTP1到HTTP2 时代的协议变迁，也看到HTTP2 提升传输效率做的种种努力，而正是HTTP2的巨大效率提升，也让gRPC选择了直接基于HTTP2 协议构建，而也是这种选择，让gRPC 成为了RPC 百家争鸣后是隐形事实协议。但我们也看到了协议的进步意味着更少的数据交互，也让数据可观察变得更加困难，比如HTTP2 使用eBPF目前尚无完美的解决方法，或使用Kprobe 观察，选择的多语言性、流量拓扑分析、但容许了失去流量细节的风险；或使用Uprobe 观察，选择了数据的细节，拓扑，但容许了多语言的兼容性问题。iLogtail致力于打造覆盖Trace、Metrics 以及Logging 的可观测性的统一Agent ，而eBPF 作为目前可观测领域的热门采集技术，提供了无侵入、安全、高效观测流量的能力，预计8月份，我们将在iLogtail Cpp正式开源后发布此部分功能，欢迎大家关注和互相交流。参考： TCP 的几个状态:https://www.s0nnet.com/archives/tcp-status HTTP2.0的总结:https://liyaoli.com/2015-04-18/HTTP-2.0.html Transmission Control Protocol:https://en.wikipedia.org/wiki/Transmission_Control_Protocol Computer Networks:https://www.cse.iitk.ac.in/users/dheeraj/cs425/lec18.html Hypertext_Transfer_Protocol:https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol gRPC: A Deep Dive into the Communication Pattern:https://thenewstack.io/grpc-a-deep-dive-into-the-communication-pattern/ ebpf2-http2-tracing:https://blog.px.dev/ebpf-http2-tracing/ 深入理解Linux socket:https://www.modb.pro/db/153725 基于eBPF的应用可观测技术实践:https://www.bilibili.com/video/BV1Gg411d7tq 作者 | 少旋原文链接：https://click.aliyun.com/m/1000352471/ 本文为阿里云原创内容，未经允许不得转载。