简介： 随着eBPF推出，因为具备高性能、高扩大、安全性等劣势，目前曾经在网络、平安、可察看等畛域广泛应用，同时也诞生了许多优良的开源我的项目，如Cilium、Pixie等，而iLogtail 作为阿里内外千万实例可观测数据的采集器，eBPF 网络可观测个性也预计会在将来8月公布。下文次要基于eBPF观测HTTP 1、HTTP 1.1以及HTTP2的角度介绍eBPF的针对可观测场景的利用，同时回顾HTTP 协定本身的倒退。

作者 | 少旋起源 | 阿里开发者公众号前言随着eBPF推出，因为具备高性能、高扩大、安全性等劣势，目前曾经在网络、平安、可察看等畛域广泛应用，同时也诞生了许多优良的开源我的项目，如Cilium、Pixie等，而iLogtail 作为阿里内外千万实例可观测数据的采集器，eBPF 网络可观测个性也预计会在将来8月公布。下文次要基于eBPF观测HTTP 1、HTTP 1.1以及HTTP2的角度介绍eBPF的针对可观测场景的利用，同时回顾HTTP 协定本身的倒退。eBPF根本介绍eBPF 是近几年 Linux Networkworking 方面比拟火的技术之一，目前在平安、网络以及可察看性方面利用宽泛，比方CNCF 我的项目Cilium 齐全是基于eBPF 技术实现，解决了传统Kube-proxy在大集群规模下iptables 性能急剧下降的问题。从基本功能上来说eBPF 提供了一种兼具性能与灵活性来自定义交互内核态与用户态的新形式，具体表现为eBPF 提供了敌对的api，使得能够通过依赖libbpf、bcc等SDK，将自定义业务逻辑平安的嵌入内核态执行，同时通过BPF Map 机制（不须要屡次拷贝）间接在内核态与用户态传递所需数据。

当聚焦在可观测性方面，咱们能够将eBPF 类比为Javaagent进行介绍。Javaagent的基本功能是程序启动时对于已存在的字节码进行代理字节码织入，从而在无需业务批改代码的状况下，主动为用户程序退出hook点，比方在某函数进入和返回时增加hook点能够计算此函数的耗时。而eBPF 相似，提供了一系列内核态执行的切入点函数，无需批改代码，即可观测利用的外部状态，以下为罕用于可观测性的切入点类型：kprobe：动静附加到内核调用点函数，比方在内核exec零碎调用前查看参数，能够BPF 程序设置 SEC("kprobe/sys_exec")头部进行切入。tracepoints：内核曾经提供好的一些切入点，能够了解为动态的kprobe，比方syscall 的connect函数。uprobe：与krobe对应，动静附加到用户态调用函数的切入点称为uprobe，相比如kprobe 内核函数的稳定性，uprobe 的函数由开发者定义，当开发者批改函数签名时，uprobe BPF 程序同样须要批改函数切入点签名。perf_events：将BPF 代码附加到Perf事件上，能够根据此进行性能剖析。

TCP与eBPF因为本文观测协定HTTP 1、HTTP1.1以及HTTP2 都是基于TCP 模型，所以先回顾一下 TCP 建设连贯的过程。首先Client 端通过3次握手建设通信，从TCP协定上来说，连贯代表着状态信息，比方蕴含seq、ack、窗口/buffer等，而tcp握手就是协商进去这些初始值；而从操作系统的角度来说，建设连贯后，TCP 创立了INET域的 socket，同时也占用了FD 资源。对于四次挥手，从TCP协定上来说，能够了解为开释终止信号，开释所维持的状态；而从操作系统的角度来说，四次挥手后也意味着Socket FD 资源的回收。而对于应用层的角度来说，还有一个罕用的概念，这就是长连贯，但长连贯对于TCP传输层来说，只是应用形式的区别：应用层短连贯：三次握手+单次传输数据+四次挥手，代表协定HTTP 1应用层长连贯：三次握手+屡次传输数据+四次挥手，代表协定 HTTP 1.1、HTTP2


参考下图TCP 建设连贯过程内核函数的调用，对于eBPF 程序能够很容易的定义好tracepoints/kprobe 切入点。例如建设连贯过程能够切入 accept 以及connect 函数，开释链接过程能够切入close过程，而传输数据能够切入read 或write函数。

基于TCP 大多数切入点曾经被动态化为tracepoints，因而BPF 程序定义如下切入点来笼罩上述提到的TCP 外围函数（sys_enter 代表进入时切入，sys_exit 代表返回时切入）。SEC("tracepoint/syscalls/sys_enter_connect") SEC("tracepoint/syscalls/sys_exit_connect") SEC("tracepoint/syscalls/sys_enter_accept") SEC("tracepoint/syscalls/sys_exit_accept") SEC("tracepoint/syscalls/sys_enter_accept4") SEC("tracepoint/syscalls/sys_exit_accept4") SEC("tracepoint/syscalls/sys_enter_close") SEC("tracepoint/syscalls/sys_exit_close") SEC("tracepoint/syscalls/sys_enter_write") SEC("tracepoint/syscalls/sys_exit_write") SEC("tracepoint/syscalls/sys_enter_read") SEC("tracepoint/syscalls/sys_exit_read") SEC("tracepoint/syscalls/sys_enter_sendmsg") SEC("tracepoint/syscalls/sys_exit_sendmsg") SEC("tracepoint/syscalls/sys_enter_recvmsg") SEC("tracepoint/syscalls/sys_exit_recvmsg") ....联合上述概念，咱们以iLogtail的eBPF 工作模型为例，介绍一个可观测畛域的eBPF 程序是如何真正工作的。更多具体内容能够参考此分享： 基于eBPF的利用可观测技术实际。如下图所示，iLogtaileBPF 程序的工作空间分为Kernel Space与User Space。Kernel Space 次要负责数据的抓取与预处理：抓取：Hook模块会根据KProbe定义拦挡网络数据，虚线中为具体的KProbe 拦挡的内核函数（应用上述形容的SEC进行定义），如connect、accept 以及write 等。预处理：预处理模块会依据用户态配置进行数据的拦挡抛弃以及数据协定的推断，只有合乎需要的数据才会传递给SendToUserSpace模块，而其余数据将会被抛弃。其后SendToUserSpace 模块通过eBPF Map 将过滤后的数据由内核态数据传输到用户态。User Space 的模块次要负责数据分析、聚合以及治理：剖析：Process 模块会一直解决eBPF Map中存储的网络数据，首先因为Kernel 曾经推断协定类型，Process 模块将依据此类型进行细粒度的协定剖析，如剖析MySQL 协定的SQL、剖析HTTP 协定的状态码等。其次因为 Kernel 所传递的连贯元数据信息只有Pid 与FD 等过程粒度元信息，而对于Kubernetes 可观测场景来说，Pod、Container 等资源定义更有意义，所以Correlate Meta 模块会为Process 解决后的数据绑定容器相干的元数据信息。聚合：当绑定元数据信息后，Aggreate 模块会对数据进行聚合操作以防止反复数据传输，比方聚合周期内某SQL 调用1000次，Aggreate 模块会将最终数据抽象为 XSQL：1000 的模式进行上传。治理：整个eBPF 程序交互着大量着过程与连贯数据，因而eBPF 程序中对象的生命周期须要与机器理论状态相符，当过程或链接开释，相应的对象也须要开释，这也正对应着Connection Management 与Garbage Collection 的职责。

eBPF 数据解析HTTP 1 、HTTP1.1以及HTTP2 数据协定都是基于TCP的，参考上文，肯定有以下函数调用:connect 函数：函数签名为int connect(int sockfd, const struct sockaddr addr, socklen_t addrlen), 从函数签名入参能够获取应用的socket 的fd，以及对端地址等信息。accept 函数：函数签名为int accept(int sockfd, struct sockaddr addr, socklen_t addrlen), 从函数签名入参同样能够获取应用的socket 的fd，以及对端地址等信息。sendmsg函数：函数签名为 ssize_t sendmsg(int sockfd, const struct msghdr msg, int flags),从函数签名能够看出，基于此函数能够拿到发送的数据包，以及应用的socket 的fd信息，但无奈间接基于入参通晓对端地址。recvmsg函数：函数签名为 ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags),从函数签名能够看出，基于此函数咱们拿到接管的数据包，以及应用的socket 的fd信息，但无奈间接基于入参通晓对端地址。close 函数：函数签名为 int close(int fd),从函数签名能够看出，基于此函数能够拿到行将敞开的fd信息。HTTP 1 / HTTP 1.1 短连贯模式HTTP 于1996年推出，HTTP 1 在用户层是短连贯模型，也就意味着每一次发送数据，都会随同着connect、accept以及close 函数的调用，这就认为这eBPF程序能够很容易的寻找到connect 的起始点，将传输数据与地址进行绑定，进而构建服务的上下游调用关系。

能够看出HTTP 1 或者HTTP1.1 短连贯模式是对于eBPF 是十分敌对的协定，因为能够轻松的关联地址信息与数据信息，但回到HTTP 1/HTTP1.1 短连贯模式 自身来说，‘敌对的代价’不仅意味着带来每次TCP 连贯与开释连贯的耗费，如果两次传输数据的HTTP Header 头雷同，Header 头也存在冗余传输问题，比方下列数据的头Host、Accept 等字段。

HTTP 1.1 长连贯HTTP 1.1 于HTTP 1.0 公布的一年后公布（1997年），提供了缓存解决、带宽优化、谬误告诉治理、host头解决以及长连贯等个性。而长连贯的引入也局部解决了上述HTTP1中每次发送数据都须要通过三次握手以及四次挥手的过程，晋升了数据的发送效率。但对于应用eBPF 察看HTTP数据来说，也带来了新的问题，上文提到建设地址与数据的绑定依赖于在connect 时进行probe，通过connect 参数拿到数据地址，从而与后续的数据包绑定。但回到长连贯状况，如果connect 于1小时之前建设，而此时才启动eBPF程序，所以咱们只能探测到数据包函数的调用，如send或recv函数。此时应该如何建设地址与数据的关系呢？

首先能够回到探测函数的定义，能够发现此时尽管没有明确的地址信息，然而能够晓得此TCP 报文应用的Socket 与FD 信息。因而能够应用 netlink 获取此Socket 的元信息，进行对长连贯补充对端地址，进而在HTTP 1.1 长连贯协定构建服务拓扑与剖析数据明细。ssize_t sendmsg(int sockfd, const struct msghdr msg, int flags) ssize_t recvmsg(int sockfd, struct msghdr msg, int flags)

HTTP 2在HTTP 1.1 公布后，因为冗余传输以及传输模型串行等问题，RPC 框架基本上都是进行了私有化协定定义，如Dubbo 等。而在2015年，HTTP2 的公布突破了以往对HTTP 协定的很多诟病，除解决在上述咱们提到的Header 头冗余传输问题，还解决TCP连接数限度、传输效率、队头拥塞等问题，而 gRPC正式基于HTTP2 构建了高性能RPC 框架，也让HTTP 1 时代层出不穷的通信协议，也逐步走向了归一时代，比方Dubbo3 全面兼容gRPC/HTTP2 协定。个性以下内容首先介绍一些HTTP2 与eBPF 可察看性相干的要害个性。多路复用HTTP 1 是一种同步、独占的协定，客户端发送音讯，期待服务端响应后，才进行新的信息发送，这种模式节约了TCP 全双工模式的个性。因而HTTP2 容许在单个连贯上执行多个申请，每个申请相应应用不同的流，通过二进制分帧层，为每个帧调配一个专属的stream 标识符，而当接管方收到信息时，接管方能够将帧重组为残缺音讯，晋升了数据的吞吐。此外能够看到因为Stream 的引入，Header 与Data 也进行了拆散设计，每次传输数据Heaer 帧发送后为尔后Data帧的对立头部，进一步提醒了传输效率。

首部压缩HTTP 首部用于发送与申请和响应相干的额定信息，HTTP2引入首部压缩概念，应用与注释压缩不同的技术，反对跨申请压缩首部，能够防止注释压缩应用算法的平安问题。HTTP2采纳了基于查问表和Huffman编码的压缩形式，应用由事后定义的动态表和会话过程中创立的动静表，没有援用索引表的首部能够应用ASCII编码或者Huffman编码传输。

但随着性能的晋升，也意味着越来越多的数据防止传输，这也同时意味着对eBPF 程序可感知的数据会更少，因而HTTP2协定的可察看性也带来了新的问题，以下咱们应用gRPC不同模式以及Wireshark 剖析HTTP2协定对eBPF 程序可观测性的挑战。GRPCSimple RPCSimple RPC 是GRPC 最简略的通信模式，申请和响应都是一条二进制音讯，如果放弃连贯能够类比为HTTP 1.1 的长连贯模式，每次发送收到响应，之后再持续发送数据。

但与HTTP 1 不同的是首部压缩的引入，如果维持长连贯状态，后续发的数据包Header 信息将只存储索引值，而不是原始值，咱们能够看到下图为Wirshark 抓取的数据包，首次发送是蕴含残缺Header帧数据，而后续Heders 帧长度升高为15，缩小了大量反复数据的传输。


Stream 模式Stream 模式是gRPC 罕用的模式，蕴含Server-side streaming RPC，Client-side streaming RPC，Bidirectional streaming RPC，从传输编码上来说与Simple RPC 模式没有不同，都分为Header 帧、Data帧等。但不同的在于Data 帧的数量，Simple RPC 一次发送或响应只蕴含一个Data帧 模式，而Stream 模式能够蕴含多个。1、Server-side streaming RPC：与Simple RPC 模式不同，在Server-side streaming RPC 中，当从客户端接管到申请时，服务器会发回一系列响应。此响应音讯序列在客户端发动的同一 HTTP 流中发送。如下图所示，服务器收到来自客户端的音讯，并以帧音讯的模式发送多个响应音讯。最初，服务器通过发送带有呼叫状态详细信息的尾随元数据来完结流。

2、Client-side streaming RPC： 在客户端流式 RPC 模式中，客户端向服务器发送多条音讯，而服务器只返回一条音讯。

3、Bidirectional streaming RPC：客户端和服务器都向对方发送音讯流。客户端通过发送标头帧来设置 HTTP 流。建设连贯后，客户端和服务器都能够同时发送音讯，而无需期待对方实现。

tracepoint/kprobe的挑战从上述wirshark 报文以及协定模式能够看出，历史针对HTTP1时代应用的tracepoint/kprobe 会存在以下挑战：Stream 模式: 比方在Server-side stream 下，如果tracepoint/kprobe 探测的点为Data帧，因Data 帧因为无奈关联Header 帧，都将变成有效Data 帧，但对于gRPC 应用场景来说还好，个别RPC 发送数据和承受数据都很快，所以很快就会有新的Header 帧收到，但这时会遇到更大的挑战，长连贯下的首部压缩。

长连贯+首部压缩：当HTTP2 放弃长连贯，connect 后的第一个Stream 传输的Header 会为残缺数据，而后续Header帧如与前置Header帧存在雷同Header 字段，则数据传输的为地址信息，而真正的数据信息会交给Server 或Client 端的应用层SDK 进行保护，而如下图eBPF tracepoints/kprobe 在stream 1 的尾部帧才进行probe，对于后续的Header2 帧大概率不会存在残缺的Header 元数据，如下图Wireshark 截图，蕴含了很多Header 信息的Header 长度仅仅为15，能够看出eBPF tracepoints/kprobe 对于这种状况很难解决。


从上文可知，HTTP2 能够归属于有状态的协定，而Tracepoint/Kprobe 对有状态的协定数据很难解决欠缺，某些场景下只能做到进化解决，以下为应用Tracepoint/Kprobe 解决的根本流程。

Uprobe 可行吗？从上述tracepoint/kprobe 的挑战能够看到，HTTP 2 是一种很难被观测的协定，在HTTP2 的协定标准上，为缩小Header 的传输，client 端以及server 端都须要保护Header 的数据，下图是grpc 实现的HTTP2 客户端保护Header 元信息的截图，所以在应用层能够做到拿到残缺Header数据，也就绕过来首部压缩问题，而针对应用层协定，eBPF 提供的探测伎俩是Uprobe（用户态），而Pixie 我的项目也正是基于Uprobe 实际了gRPC HTTP2 流量的探测，具体内容能够参考此文章[1]。

下图展现了应用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/archiv...的总结:https://liyaoli.com/2015-04-1... Control Protocol:https://en.wikipedia.org/wiki... Networks:https://www.cse.iitk.ac.in/us... A Deep Dive into the Communication Pattern:https://thenewstack.io/grpc-a...深刻了解Linux socket:https://www.modb.pro/db/153725基于eBPF的利用可观测技术实际:https://www.bilibili.com/vide... 重磅来袭！2022上半年阿里云社区最热电子书榜单！ 千万浏览量、百万下载量、上百本电子书，近200位阿里专家参加编写。多元化抉择、全畛域笼罩，汇聚阿里巴巴技术实际精髓，读、学、练一键三连。开发者藏经阁，开发者的工作伴侣~点击这里，查看详情。原文链接：https://click.aliyun.com/m/10...本文为阿里云原创内容，未经容许不得转载。