一文详解用 eBPF 观测 HTTP

随着eBPF推出，由于具有高性能、高扩展、安全性等优势，目前已经在网络、安全、可观察等领域广泛应用，同时也诞生了许多优秀的开源项目，如Cilium、Pixie等，而iLogtail作为阿里内外千万实例可观测数据的采集器，eBPF网络可观测特性也预计会在未来8月发布。下文主要基于eBPF观测HTTP1、以及HTTP2的角度介绍eBPF的针对可观测场景的应用，同时回顾HTTP协议自身的发展。

eBPF是近几年LinuxNetworkworking方面比较火的技术之一，目前在安全、网络以及可观察性方面应用广泛，比如CNCF项目Cilium完全是基于eBPF技术实现，解决了传统Kube-proxy在大集群规模下iptables性能急剧下降的问题。从基本功能上来说eBPF提供了一种兼具性能与灵活性来自定义交互内核态与用户态的新方式，具体表现为eBPF提供了友好的api，使得可以通过依赖libbpf、bcc等SDK，将自定义业务逻辑安全的嵌入内核态执行，同时通过BPFMap机制（不需要多次拷贝）直接在内核态与用户态传递所需数据。

当聚焦在可观测性方面，我们可以将eBPF类比为Javaagent进行介绍。Javaagent的基本功能是程序启动时对于已存在的字节码进行代理字节码织入，从而在无需业务修改代码的情况下，自动为用户程序加入hook点，比如在某函数进入和返回时添加hook点可以计算此函数的耗时。而eBPF类似，提供了一系列内核态执行的切入点函数，无需修改代码，即可观测应用的内部状态，以下为常用于可观测性的切入点类型：

kprobe：动态附加到内核调用点函数，比如在内核exec系统调用前检查参数，可以BPF程序设置SEC("kprobe/sys_exec")头部进行切入。

tracepoints：内核已经提供好的一些切入点，可以理解为静态的kprobe，比如syscall的connect函数。

uprobe：与krobe对应，动态附加到用户态调用函数的切入点称为uprobe，相比如kprobe内核函数的稳定性，uprobe的函数由开发者定义，当开发者修改函数签名时，uprobeBPF程序同样需要修改函数切入点签名。

perf_events：将BPF代码附加到Perf事件上，可以依据此进行性能分析。

由于本文观测协议HTTP1、以及HTTP2都是基于TCP模型，所以先回顾一下TCP建立连接的过程。首先Client端通过3次握手建立通信，从TCP协议上来说，连接代表着状态信息，比如包含seq、ack、窗口/buffer等，而tcp握手就是协商出来这些初始值；而从操作系统的角度来说，建立连接后，TCP创建了INET域的socket，同时也占用了FD资源。对于四次挥手，从TCP协议上来说，可以理解为释放终止信号，释放所维持的状态；而从操作系统的角度来说，四次挥手后也意味着SocketFD资源的回收。

而对于应用层的角度来说，还有一个常用的概念，这就是长连接，但长连接对于TCP传输层来说，只是使用方式的区别：

应用层短连接：三次握手+单次传输数据+四次挥手，代表协议HTTP1

应用层长连接：三次握手+多次传输数据+四次挥手，代表协议、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_smsg")SEC("tracepoint/syscalls/sys_exit_smsg")SEC("tracepoint/syscalls/sys_enter_recvmsg")SEC("tracepoint/syscalls/sys_exit_recvmsg").

结合上述概念，我们以iLogtail的eBPF工作模型为例，介绍一个可观测领域的eBPF程序是如何真正工作的。更多详细内容可以参考此分享：基于eBPF的应用可观测技术实践。如下图所示，iLogtaileBPF程序的工作空间分为KernelSpace与UserSpace。

KernelSpace主要负责数据的抓取与预处理：

抓取：Hook模块会依据KProbe定义拦截网络数据，虚线中为具体的KProbe拦截的内核函数（使用上述描述的SEC进行定义），如connect、accept以及write等。

预处理：预处理模块会根据用户态配置进行数据的拦截丢弃以及数据协议的推断，只有符合需求的数据才会传递给SToUserSpace模块，而其他数据将会被丢弃。其后SToUserSpace模块通过eBPFMap将过滤后的数据由内核态数据传输到用户态。

UserSpace的模块主要负责数据分析、聚合以及管理：

分析：Process模块会不断处理eBPFMap中存储的网络数据，首先由于Kernel已经推断协议类型，Process模块将根据此类型进行细粒度的协议分析，如分析MySQL协议的SQL、分析HTTP协议的状态码等。其次由于Kernel所传递的连接元数据信息只有Pid与

FD等进程粒度元信息，而对于Kubernetes可观测场景来说，Pod、Container等资源定义更有意义，所以CorrelateMeta模块会为Process处理后的数据绑定容器相关的元数据信息。

聚合：当绑定元数据信息后，Aggreate模块会对数据进行聚合操作以避免重复数据传输，比如聚合周期内某SQL调用1000次，Aggreate模块会将最终数据抽象为XSQL：1000的形式进行上传。

管理：整个eBPF程序交互着大量着进程与连接数据，因此eBPF程序中对象的生命周期需要与机器实际状态相符，当进程或链接释放，相应的对象也需要释放，这也正对应着ConnectionManagement与GarbageCollection的职责。

HTTP1、以及HTTP2数据协议都是基于TCP的，参考上文，一定有以下函数调用:

connect函数：函数签名为intconnect(intsockfd,conststructsockaddr*addr,socklen_taddrlen),从函数签名入参可以获取使用的socket的fd，以及对端地址等信息。

accept函数：函数签名为intaccept(intsockfd,structsockaddraddr,socklen_taddrlen),从函数签名入参同样可以获取使用的socket的fd，以及对端地址等信息。

smsg函数：函数签名为ssize_tsmsg(intsockfd,conststructmsghdr*msg,intflags),从函数签名可以看出，基于此函数可以拿到发送的数据包，以及使用的socket的fd信息，但无法直接基于入参知晓对端地址。

recvmsg函数：函数签名为ssize_trecvmsg(intsockfd,structmsghdr*msg,intflags),从函数签名可以看出，基于此函数我们拿到接收的数据包，以及使用的socket的fd信息，但无法直接基于入参知晓对端地址。

close函数：函数签名为intclose(intfd),从函数签名可以看出，基于此函数可以拿到即将关闭的fd信息。

HTTP于1996年推出，HTTP1在用户层是短连接模型，也就意味着每一次发送数据，都会伴随着connect、accept以及close函数的调用，这就以为这eBPF程序可以很容易的寻找到connect的起始点，将传输数据与地址进行绑定，进而构建服务的上下游调用关系。

可以看出HTTP1或者短连接模式是对于eBPF是非常友好的协议，因为可以轻松的关联地址信息与数据信息，但回到HTTP1/短连接模式本身来说，‘友好的代价’不仅意味着带来每次TCP连接与释放连接的消耗，如果两次传输数据的HTTPHeader头相同，Header头也存在冗余传输问题，比如下列数据的头Host、Accept等字段。

于发布的一年后发布（1997年），提供了缓存处理、带宽优化、错误通知管理、host头处理以及长连接等特性。而长连接的引入也部分解决了上述HTTP1中每次发送数据都需要经过三次握手以及四次挥手的过程，提升了数据的发送效率。但对于使用eBPF观察HTTP数据来说，也带来了新的问题，上文提到建立地址与数据的绑定依赖于在connect时进行probe，通过connect参数拿到数据地址，从而与后续的数据包绑定。但回到长连接情况，假如connect于1小时之前建立，而此时才启动eBPF程序，所以我们只能探测到数据包函数的调用，如s或recv函数。此时应该如何建立地址与数据的关系呢？

首先可以回到探测函数的定义，可以发现此时虽然没有明确的地址信息，但是可以知道此TCP报文使用的Socket与FD信息。因此可以使用netlink获取此Socket的元信息，进行对长连接补充对端地址，进而在长连接协议构建服务拓扑与分析数据明细。

ssize_tsmsg(intsockfd,conststructmsghdrmsg,intflags)ssize_trecvmsg(intsockfd,structmsghdrmsg,intflags)

在发布后，由于冗余传输以及传输模型串行等问题，RPC框架基本上都是进行了私有化协议定义，如Dubbo等。而在2015年，HTTP2的发布打破了以往对HTTP协议的很多诟病，除解决在上述我们提到的Header头冗余传输问题，还解决TCP连接数限制、传输效率、队头拥塞等问题，而gRPC正式基于HTTP2构建了高性能RPC框架，也让HTTP1时代层出不穷的通信协议，也逐渐走向了归一时代，比如Dubbo3全面兼容gRPC/HTTP2协议。

特性

以下内容首先介绍一些HTTP2与eBPF可观察性相关的关键特性。

多路复用

HTTP1是一种同步、独占的协议，客户端发送消息，等待服务端响应后，才进行新的信息发送，这种模式浪费了TCP全双工模式的特性。因此HTTP2允许在单个连接上执行多个请求，每个请求相应使用不同的流，通过二进制分帧层，为每个帧分配一个专属的stream标识符，而当接收方收到信息时，接收方可以将帧重组为完整消息，提升了数据的吞吐。此外可以看到由于Stream的引入，Header与Data也进行了分离设计，每次传输数据Heaer帧发送后为此后Data帧的统一头部，进一步提示了传输效率。

首部压缩

HTTP首部用于发送与请求和响应相关的额外信息，HTTP2引入首部压缩概念，使用与正文压缩不同的技术，支持跨请求压缩首部，可以避免正文压缩使用算法的安全问题。HTTP2采用了基于查询表和Huffman编码的压缩方式，使用由预先定义的静态表和会话过程中创建的动态表，没有引用索引表的首部可以使用ASCII编码或者Huffman编码传输。

但随着性能的提升，也意味着越来越多的数据避免传输，这也同时意味着对eBPF程序可感知的数据会更少，因此HTTP2协议的可观察性也带来了新的问题，以下我们使用gRPC不同模式以及Wireshark分析HTTP2协议对eBPF程序可观测性的挑战。

GRPC

SimpleRPC

SimpleRPC是GRPC最简单的通信模式，请求和响应都是一条二进制消息，如果保持连接可以类比为的长连接模式，每次发送收到响应，之后再继续发送数据。

但与HTTP1不同的是首部压缩的引入，如果维持长连接状态，后续发的数据包Header信息将只存储索引值，而不是原始值，我们可以看到下图为Wirshark抓取的数据包，首次发送是包含完整Header帧数据，而后续Heders帧长度降低为15，减少了大量重复数据的传输。

Stream模式

Stream模式是gRPC常用的模式，包含Server-sidestreamingRPC，Client-sidestreamingRPC，BidirectionalstreamingRPC，从传输编码上来说与SimpleRPC模式没有不同，都分为Header帧、Data帧等。但不同的在于Data帧的数量，SimpleRPC一次发送或响应只包含一个Data帧模式，而Stream模式可以包含多个。

1、Server-sidestreamingRPC：与SimpleRPC模式不同，在Server-sidestreamingRPC中，当从客户端接收到请求时，服务器会发回一系列响应。此响应消息序列在客户端发起的同一HTTP流中发送。如下图所示，服务器收到来自客户端的消息，并以帧消息的形式发送多个响应消息。最后，服务器通过发送带有呼叫状态详细信息的尾随元数据来结束流。

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

3、BidirectionalstreamingRPC：客户端和服务器都向对方发送消息流。客户端通过发送标头帧来设置HTTP流。建立连接后，客户端和服务器都可以同时发送消息，而无需等待对方完成。

tracepoint/kprobe的挑战

从上述wirshark报文以及协议模式可以看出，历史针对HTTP1时代使用的tracepoint/kprobe会存在以下挑战：

Stream模式:比如在Server-sidestream下，假如tracepoint/kprobe探测的点为Data帧，因Data帧因为无法关联Header帧，都将变成无效Data帧，但对于gRPC使用场景来说还好，一般RPC发送数据和接受数据都很快，所以很快就会有新的Header帧收到，但这时会遇到更大的挑战，长连接下的首部压缩。

长连接+首部压缩：当HTTP2保持长连接，connect后的第一个Stream传输的Header会为完整数据，而后续Header帧如与前置Header帧存在相同Header字段，则数据传输的为地址信息，而真正的数据信息会交给Server或Client端的应用层SDK进行维护，而如下图eBPFtracepoints/kprobe在stream1的尾部帧才进行probe，对于后续的Header2帧大概率不会存在完整的Header元数据，如下图Wireshark截图，包含了很多Header信息的Header长度仅仅为15，可以看出eBPFtracepoints/kprobe对于这种情况很难处理。

从上文可知，HTTP2可以归属于有状态的协议，而Tracepoint/Kprobe对有状态的协议数据很难处理完善，某些场景下只能做到退化处理，以下为使用Tracepoint/Kprobe处理的基本流程。

Uprobe可行吗？

从上述tracepoint/kprobe的挑战可以看到，HTTP2是一种很难被观测的协议，在HTTP2的协议规范上，为减少Header的传输，client端以及server端都需要维护Header的数据，下图是grpc实现的HTTP2客户端维护Header元信息的截图，所以在应用层可以做到拿到完整Header数据，也就绕过来首部压缩问题，而针对应用层协议，eBPF提供的探测手段是Uprobe（用户态），而Pixie项目也正是基于Uprobe实践了gRPCHTTP2流量的探测，详细内容可以参考此文章[1]。

下图展示了使用Uprobe观测GogRPC流量的基本流程，如其中writeHeader的函数定义为func(l*loopyWriter)writeHeader(streamIDuint32,Streambool,hf[],onWritefunc()),可以看到明确的Header文本。

Kprobe与Uprobe对比

从上文可以看出Uprobe实现简单，且不存在数据退化的问题，但Uprobe真的完美吗？

兼容性：上述方案仅仅是基于GolanggRPC的特定方法进行探测，也就意味着上述仅能覆盖GolanggRPC流量的观察，对于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观察，选择了数据的细节，拓扑，但容许了多语言的兼容性问题。

参考：

TCP的几个状态:

的总结:

TransmissionControlProtocol:

ComputerNetworks:

Hypertext_Transfer_Protocol:

gRPC:ADeepDiveintotheCommunicationPattern:

ebpf2-http2-tracing:

深入理解Linuxsocket:

基于eBPF的应用可观测技术实践:

作者|少旋

本文为阿里云原创内容，未经允许不得转载。