前言 隨著eBPF推出，由于具有高性能、高擴(kuò)展、安全性等優(yōu)勢，目前已經(jīng)在網(wǎng)絡(luò)、安全、可觀察等領(lǐng)域廣泛應(yīng)用，同時也誕生了許多優(yōu)秀的開源項目，如Cilium、Pixie等，而iLogtail作為阿里內(nèi)外千萬實例可觀測數(shù)據(jù)的采集器，eBPF 網(wǎng)絡(luò)可觀測特性也預(yù)計會在未來8月發(fā)布。下文主要基于eBPF觀測HTTP 1、HTTP 1.1以及HTTP2的角度介紹eBPF的針對可觀測場景的應(yīng)用，同時回顧HTTP 協(xié)議自身的發(fā)展。

eBPF基本介紹 eBPF 是近幾年 Linux Networkworking 方面比較火的技術(shù)之一，目前在安全、網(wǎng)絡(luò)以及可觀察性方面應(yīng)用廣泛，比如CNCF 項目Cilium 完全是基于eBPF 技術(shù)實現(xiàn)，解決了傳統(tǒng)Kube-proxy在大集群規(guī)模下iptables 性能急劇下降的問題。從基本功能上來說eBPF 提供了一種兼具性能與靈活性來自定義交互內(nèi)核態(tài)與用戶態(tài)的新方式，具體表現(xiàn)為eBPF 提供了友好的api，使得可以通過依賴libbpf、bcc等SDK，將自定義業(yè)務(wù)邏輯安全的嵌入內(nèi)核態(tài)執(zhí)行，同時通過BPF Map 機(jī)制（不需要多次拷貝）直接在內(nèi)核態(tài)與用戶態(tài)傳遞所需數(shù)據(jù)。 當(dāng)聚焦在可觀測性方面，我們可以將eBPF 類比為Javaagent進(jìn)行介紹。Javaagent的基本功能是程序啟動時對于已存在的字節(jié)碼進(jìn)行代理字節(jié)碼織入，從而在無需業(yè)務(wù)修改代碼的情況下，自動為用戶程序加入hook點，比如在某函數(shù)進(jìn)入和返回時添加hook點可以計算此函數(shù)的耗時。而eBPF 類似，提供了一系列內(nèi)核態(tài)執(zhí)行的切入點函數(shù)，無需修改代碼，即可觀測應(yīng)用的內(nèi)部狀態(tài)，以下為常用于可觀測性的切入點類型：

kprobe：動態(tài)附加到內(nèi)核調(diào)用點函數(shù)，比如在內(nèi)核exec系統(tǒng)調(diào)用前檢查參數(shù)，可以BPF 程序設(shè)置 SEC("kprobe/sys_exec")頭部進(jìn)行切入。

tracepoints：內(nèi)核已經(jīng)提供好的一些切入點，可以理解為靜態(tài)的kprobe，比如syscall 的connect函數(shù)。

uprobe：與krobe對應(yīng)，動態(tài)附加到用戶態(tài)調(diào)用函數(shù)的切入點稱為uprobe，相比如kprobe 內(nèi)核函數(shù)的穩(wěn)定性，uprobe 的函數(shù)由開發(fā)者定義，當(dāng)開發(fā)者修改函數(shù)簽名時，uprobe BPF 程序同樣需要修改函數(shù)切入點簽名。

perf_events：將BPF 代碼附加到Perf事件上，可以依據(jù)此進(jìn)行性能分析。

TCP與eBPF 由于本文觀測協(xié)議HTTP 1、HTTP1.1以及HTTP2 都是基于TCP 模型，所以先回顧一下 TCP 建立連接的過程。首先Client 端通過3次握手建立通信，從TCP協(xié)議上來說，連接代表著狀態(tài)信息，比如包含seq、ack、窗口/buffer等，而tcp握手就是協(xié)商出來這些初始值；而從操作系統(tǒng)的角度來說，建立連接后，TCP 創(chuàng)建了INET域的 socket，同時也占用了FD 資源。對于四次揮手，從TCP協(xié)議上來說，可以理解為釋放終止信號，釋放所維持的狀態(tài)；而從操作系統(tǒng)的角度來說，四次揮手后也意味著Socket FD 資源的回收。 而對于應(yīng)用層的角度來說，還有一個常用的概念，這就是長連接，但長連接對于TCP傳輸層來說，只是使用方式的區(qū)別：

應(yīng)用層短連接：三次握手+單次傳輸數(shù)據(jù)+四次揮手，代表協(xié)議HTTP 1

應(yīng)用層長連接：三次握手+多次傳輸數(shù)據(jù)+四次揮手，代表協(xié)議 HTTP 1.1、HTTP2

參考下圖TCP 建立連接過程內(nèi)核函數(shù)的調(diào)用，對于eBPF 程序可以很容易的定義好tracepoints/kprobe 切入點。例如建立連接過程可以切入 accept 以及connect 函數(shù)，釋放鏈接過程可以切入close過程，而傳輸數(shù)據(jù)可以切入read 或write函數(shù)。 基于TCP 大多數(shù)切入點已經(jīng)被靜態(tài)化為tracepoints，因此BPF 程序定義如下切入點來覆蓋上述提到的TCP 核心函數(shù)（sys_enter 代表進(jìn)入時切入，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") .... 結(jié)合上述概念，我們以iLogtail的eBPF 工作模型為例，介紹一個可觀測領(lǐng)域的eBPF 程序是如何真正工作的。更多詳細(xì)內(nèi)容可以參考此分享：?基于eBPF的應(yīng)用可觀測技術(shù)實踐。如下圖所示，iLogtaileBPF 程序的工作空間分為Kernel Space與User Space。 Kernel Space 主要負(fù)責(zé)數(shù)據(jù)的抓取與預(yù)處理：

抓取：Hook模塊會依據(jù)KProbe定義攔截網(wǎng)絡(luò)數(shù)據(jù)，虛線中為具體的KProbe 攔截的內(nèi)核函數(shù)（使用上述描述的SEC進(jìn)行定義），如connect、accept 以及write 等。

預(yù)處理：預(yù)處理模塊會根據(jù)用戶態(tài)配置進(jìn)行數(shù)據(jù)的攔截丟棄以及數(shù)據(jù)協(xié)議的推斷，只有符合需求的數(shù)據(jù)才會傳遞給SendToUserSpace模塊，而其他數(shù)據(jù)將會被丟棄。其后SendToUserSpace 模塊通過eBPF Map 將過濾后的數(shù)據(jù)由內(nèi)核態(tài)數(shù)據(jù)傳輸?shù)接脩魬B(tài)。

User Space 的模塊主要負(fù)責(zé)數(shù)據(jù)分析、聚合以及管理：

分析：Process 模塊會不斷處理eBPF Map中存儲的網(wǎng)絡(luò)數(shù)據(jù)，首先由于Kernel 已經(jīng)推斷協(xié)議類型，Process 模塊將根據(jù)此類型進(jìn)行細(xì)粒度的協(xié)議分析，如分析MySQL 協(xié)議的SQL、分析HTTP 協(xié)議的狀態(tài)碼等。其次由于 Kernel 所傳遞的連接元數(shù)據(jù)信息只有Pid 與FD 等進(jìn)程粒度元信息，而對于Kubernetes 可觀測場景來說，Pod、Container 等資源定義更有意義，所以Correlate Meta 模塊會為Process 處理后的數(shù)據(jù)綁定容器相關(guān)的元數(shù)據(jù)信息。

聚合：當(dāng)綁定元數(shù)據(jù)信息后，Aggreate 模塊會對數(shù)據(jù)進(jìn)行聚合操作以避免重復(fù)數(shù)據(jù)傳輸，比如聚合周期內(nèi)某SQL 調(diào)用1000次，Aggreate 模塊會將最終數(shù)據(jù)抽象為 XSQL：1000 的形式進(jìn)行上傳。

管理：整個eBPF 程序交互著大量著進(jìn)程與連接數(shù)據(jù)，因此eBPF 程序中對象的生命周期需要與機(jī)器實際狀態(tài)相符，當(dāng)進(jìn)程或鏈接釋放，相應(yīng)的對象也需要釋放，這也正對應(yīng)著Connection Management 與Garbage Collection 的職責(zé)。

eBPF 數(shù)據(jù)解析 HTTP 1 、HTTP1.1以及HTTP2 數(shù)據(jù)協(xié)議都是基于TCP的，參考上文，一定有以下函數(shù)調(diào)用:

connect 函數(shù)：函數(shù)簽名為int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen), 從函數(shù)簽名入?yún)⒖梢垣@取使用的socket 的fd，以及對端地址等信息。

accept 函數(shù)：函數(shù)簽名為int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen), 從函數(shù)簽名入?yún)⑼瑯涌梢垣@取使用的socket 的fd，以及對端地址等信息。

sendmsg函數(shù)：函數(shù)簽名為ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags),從函數(shù)簽名可以看出，基于此函數(shù)可以拿到發(fā)送的數(shù)據(jù)包，以及使用的socket 的fd信息，但無法直接基于入?yún)⒅獣詫Χ说刂贰?/p>

recvmsg函數(shù)：函數(shù)簽名為ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags),從函數(shù)簽名可以看出，基于此函數(shù)我們拿到接收的數(shù)據(jù)包，以及使用的socket 的fd信息，但無法直接基于入?yún)⒅獣詫Χ说刂贰?/p>

close 函數(shù)：函數(shù)簽名為int close(int fd),從函數(shù)簽名可以看出，基于此函數(shù)可以拿到即將關(guān)閉的fd信息。

HTTP 1 / HTTP 1.1 短連接模式

HTTP 于1996年推出，HTTP 1 在用戶層是短連接模型，也就意味著每一次發(fā)送數(shù)據(jù)，都會伴隨著connect、accept以及close 函數(shù)的調(diào)用，這就以為這eBPF程序可以很容易的尋找到connect 的起始點，將傳輸數(shù)據(jù)與地址進(jìn)行綁定，進(jìn)而構(gòu)建服務(wù)的上下游調(diào)用關(guān)系。 可以看出HTTP 1 或者HTTP1.1 短連接模式是對于eBPF 是非常友好的協(xié)議，因為可以輕松的關(guān)聯(lián)地址信息與數(shù)據(jù)信息，但回到HTTP 1/HTTP1.1 短連接模式 本身來說，‘友好的代價’不僅意味著帶來每次TCP 連接與釋放連接的消耗，如果兩次傳輸數(shù)據(jù)的HTTP Header 頭相同，Header 頭也存在冗余傳輸問題，比如下列數(shù)據(jù)的頭Host、Accept 等字段。

HTTP 1.1 長連接

HTTP 1.1 于HTTP 1.0 發(fā)布的一年后發(fā)布（1997年），提供了緩存處理、帶寬優(yōu)化、錯誤通知管理、host頭處理以及長連接等特性。而長連接的引入也部分解決了上述HTTP1中每次發(fā)送數(shù)據(jù)都需要經(jīng)過三次握手以及四次揮手的過程，提升了數(shù)據(jù)的發(fā)送效率。但對于使用eBPF 觀察HTTP數(shù)據(jù)來說，也帶來了新的問題，上文提到建立地址與數(shù)據(jù)的綁定依賴于在connect 時進(jìn)行probe，通過connect 參數(shù)拿到數(shù)據(jù)地址，從而與后續(xù)的數(shù)據(jù)包綁定。但回到長連接情況，假如connect 于1小時之前建立，而此時才啟動eBPF程序，所以我們只能探測到數(shù)據(jù)包函數(shù)的調(diào)用，如send或recv函數(shù)。此時應(yīng)該如何建立地址與數(shù)據(jù)的關(guān)系呢？ 首先可以回到探測函數(shù)的定義，可以發(fā)現(xiàn)此時雖然沒有明確的地址信息，但是可以知道此TCP 報文使用的Socket 與FD 信息。因此可以使用 netlink 獲取此Socket 的元信息，進(jìn)行對長連接補(bǔ)充對端地址，進(jìn)而在HTTP 1.1 長連接協(xié)議構(gòu)建服務(wù)拓?fù)渑c分析數(shù)據(jù)明細(xì)。 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 發(fā)布后，由于冗余傳輸以及傳輸模型串行等問題，RPC 框架基本上都是進(jìn)行了私有化協(xié)議定義，如Dubbo 等。而在2015年，HTTP2 的發(fā)布打破了以往對HTTP 協(xié)議的很多詬病，除解決在上述我們提到的Header 頭冗余傳輸問題，還解決TCP連接數(shù)限制、傳輸效率、隊頭擁塞等問題，而 gRPC正式基于HTTP2 構(gòu)建了高性能RPC 框架，也讓HTTP 1 時代層出不窮的通信協(xié)議，也逐漸走向了歸一時代，比如Dubbo3 全面兼容gRPC/HTTP2 協(xié)議。

特性

以下內(nèi)容首先介紹一些HTTP2 與eBPF 可觀察性相關(guān)的關(guān)鍵特性。

多路復(fù)用

HTTP 1 是一種同步、獨占的協(xié)議，客戶端發(fā)送消息，等待服務(wù)端響應(yīng)后，才進(jìn)行新的信息發(fā)送，這種模式浪費(fèi)了TCP 全雙工模式的特性。因此HTTP2 允許在單個連接上執(zhí)行多個請求，每個請求相應(yīng)使用不同的流，通過二進(jìn)制分幀層，為每個幀分配一個專屬的stream 標(biāo)識符，而當(dāng)接收方收到信息時，接收方可以將幀重組為完整消息，提升了數(shù)據(jù)的吞吐。此外可以看到由于Stream 的引入，Header 與Data 也進(jìn)行了分離設(shè)計，每次傳輸數(shù)據(jù)Heaer 幀發(fā)送后為此后Data幀的統(tǒng)一頭部，進(jìn)一步提示了傳輸效率。

首部壓縮

HTTP 首部用于發(fā)送與請求和響應(yīng)相關(guān)的額外信息，HTTP2引入首部壓縮概念，使用與正文壓縮不同的技術(shù)，支持跨請求壓縮首部，可以避免正文壓縮使用算法的安全問題。HTTP2采用了基于查詢表和Huffman編碼的壓縮方式，使用由預(yù)先定義的靜態(tài)表和會話過程中創(chuàng)建的動態(tài)表，沒有引用索引表的首部可以使用ASCII編碼或者Huffman編碼傳輸。 但隨著性能的提升，也意味著越來越多的數(shù)據(jù)避免傳輸，這也同時意味著對eBPF 程序可感知的數(shù)據(jù)會更少，因此HTTP2協(xié)議的可觀察性也帶來了新的問題，以下我們使用gRPC不同模式以及Wireshark 分析HTTP2協(xié)議對eBPF 程序可觀測性的挑戰(zhàn)。

GRPC

Simple RPC

Simple RPC 是GRPC 最簡單的通信模式，請求和響應(yīng)都是一條二進(jìn)制消息，如果保持連接可以類比為HTTP 1.1 的長連接模式，每次發(fā)送收到響應(yīng)，之后再繼續(xù)發(fā)送數(shù)據(jù)。 但與HTTP 1 不同的是首部壓縮的引入，如果維持長連接狀態(tài)，后續(xù)發(fā)的數(shù)據(jù)包Header 信息將只存儲索引值，而不是原始值，我們可以看到下圖為Wirshark 抓取的數(shù)據(jù)包，首次發(fā)送是包含完整Header幀數(shù)據(jù)，而后續(xù)Heders 幀長度降低為15，減少了大量重復(fù)數(shù)據(jù)的傳輸。

Stream 模式

Stream 模式是gRPC 常用的模式，包含Server-side streaming RPC，Client-side streaming RPC，Bidirectional streaming RPC，從傳輸編碼上來說與Simple RPC 模式?jīng)]有不同，都分為Header 幀、Data幀等。但不同的在于Data 幀的數(shù)量，Simple RPC 一次發(fā)送或響應(yīng)只包含一個Data幀 模式，而Stream 模式可以包含多個。 1、Server-side streaming RPC：與Simple RPC 模式不同，在Server-side streaming RPC 中，當(dāng)從客戶端接收到請求時，服務(wù)器會發(fā)回一系列響應(yīng)。此響應(yīng)消息序列在客戶端發(fā)起的同一 HTTP 流中發(fā)送。如下圖所示，服務(wù)器收到來自客戶端的消息，并以幀消息的形式發(fā)送多個響應(yīng)消息。最后，服務(wù)器通過發(fā)送帶有呼叫狀態(tài)詳細(xì)信息的尾隨元數(shù)據(jù)來結(jié)束流。 2、Client-side streaming RPC：?在客戶端流式 RPC 模式中，客戶端向服務(wù)器發(fā)送多條消息，而服務(wù)器只返回一條消息。 3、Bidirectional streaming RPC：客戶端和服務(wù)器都向?qū)Ψ桨l(fā)送消息流。客戶端通過發(fā)送標(biāo)頭幀來設(shè)置 HTTP 流。建立連接后，客戶端和服務(wù)器都可以同時發(fā)送消息，而無需等待對方完成。

tracepoint/kprobe的挑戰(zhàn)

從上述wirshark 報文以及協(xié)議模式可以看出，歷史針對HTTP1時代使用的tracepoint/kprobe 會存在以下挑戰(zhàn)：

Stream 模式: 比如在Server-side stream 下，假如tracepoint/kprobe 探測的點為Data幀，因Data 幀因為無法關(guān)聯(lián)Header 幀，都將變成無效Data 幀，但對于gRPC 使用場景來說還好，一般RPC 發(fā)送數(shù)據(jù)和接受數(shù)據(jù)都很快，所以很快就會有新的Header 幀收到，但這時會遇到更大的挑戰(zhàn)，長連接下的首部壓縮。

長連接+首部壓縮：當(dāng)HTTP2 保持長連接，connect 后的第一個Stream 傳輸?shù)腍eader 會為完整數(shù)據(jù)，而后續(xù)Header幀如與前置Header幀存在相同Header 字段，則數(shù)據(jù)傳輸?shù)臑榈刂沸畔ⅲ嬲臄?shù)據(jù)信息會交給Server 或Client 端的應(yīng)用層SDK 進(jìn)行維護(hù)，而如下圖eBPF tracepoints/kprobe 在stream 1 的尾部幀才進(jìn)行probe，對于后續(xù)的Header2 幀大概率不會存在完整的Header 元數(shù)據(jù)，如下圖Wireshark 截圖，包含了很多Header 信息的Header 長度僅僅為15，可以看出eBPF tracepoints/kprobe 對于這種情況很難處理。

從上文可知，HTTP2 可以歸屬于有狀態(tài)的協(xié)議，而Tracepoint/Kprobe 對有狀態(tài)的協(xié)議數(shù)據(jù)很難處理完善，某些場景下只能做到退化處理，以下為使用Tracepoint/Kprobe 處理的基本流程。

Uprobe 可行嗎？

從上述tracepoint/kprobe 的挑戰(zhàn)可以看到，HTTP 2 是一種很難被觀測的協(xié)議，在HTTP2 的協(xié)議規(guī)范上，為減少Header 的傳輸，client 端以及server 端都需要維護(hù)Header 的數(shù)據(jù)，下圖是grpc 實現(xiàn)的HTTP2 客戶端維護(hù)Header 元信息的截圖，所以在應(yīng)用層可以做到拿到完整Header數(shù)據(jù)，也就繞過來首部壓縮問題，而針對應(yīng)用層協(xié)議，eBPF 提供的探測手段是Uprobe（用戶態(tài)），而Pixie 項目也正是基于Uprobe 實踐了gRPC HTTP2 流量的探測，詳細(xì)內(nèi)容可以參考此文章[1]。 下圖展示了使用Uprobe 觀測Go gRPC 流量的基本流程，如其中writeHeader 的函數(shù)定義為 func (l *loopyWriter) writeHeader(streamID uint32, endStream bool, hf []hpack.HeaderField, onWrite func()), 可以看到明確的Header 文本。

Kprobe 與Uprobe 對比

從上文可以看出Uprobe 實現(xiàn)簡單，且不存在數(shù)據(jù)退化的問題，但Uprobe 真的完美嗎？

兼容性：上述方案僅僅是基于Golang gRPC 的 特定方法進(jìn)行探測，也就意味著上述僅能覆蓋Golang gRPC 流量的觀察，對于Golang 其他HTTP2 庫無法支持。

多語言性：Uprobe 只能基于方法簽名進(jìn)行探測，更適用于C/GO 這種純編譯型語言，而對于Java 這種JVM 語言，因為運(yùn)行時動態(tài)生成符號表，雖然可以依靠一些javaagent 將java 程序用于Uprobe，但是相對于純編譯型語言，用戶使用成本或改造成本還是會更高一些。

穩(wěn)定性：Uprobe 相對于tracepoint/kprobe 來說是不穩(wěn)定的，假如探測的函數(shù)函數(shù)簽名有改變，這就意味著Uprobe 程序?qū)o法工作，因為函數(shù)注冊表的改變將使得Uprobe 無法找到切入點。

綜合下來2種方案對比如下，可以看到2種方案對于HTTP2（有狀態(tài)）的觀測都存在部分取舍：

總結(jié) 上述我們回顧了HTTP1到HTTP2 時代的協(xié)議變遷，也看到HTTP2 提升傳輸效率做的種種努力，而正是HTTP2的巨大效率提升，也讓gRPC選擇了直接基于HTTP2 協(xié)議構(gòu)建，而也是這種選擇，讓gRPC 成為了RPC 百家爭鳴后是隱形事實協(xié)議。但我們也看到了協(xié)議的進(jìn)步意味著更少的數(shù)據(jù)交互，也讓數(shù)據(jù)可觀察變得更加困難，比如HTTP2 使用eBPF目前尚無完美的解決方法，或使用Kprobe 觀察，選擇的多語言性、流量拓?fù)浞治觥⒌菰S了失去流量細(xì)節(jié)的風(fēng)險；或使用Uprobe 觀察，選擇了數(shù)據(jù)的細(xì)節(jié)，拓?fù)洌菰S了多語言的兼容性問題。 iLogtail致力于打造覆蓋Trace、Metrics 以及Logging 的可觀測性的統(tǒng)一Agent，而eBPF 作為目前可觀測領(lǐng)域的熱門采集技術(shù)，提供了無侵入、安全、高效觀測流量的能力，預(yù)計8月份，我們將在iLogtail Cpp正式開源后發(fā)布此部分功能，歡迎大家關(guān)注和互相交流。