前言 隨著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 程序可觀測性的挑戰。

GRPC

Simple RPC

Simple 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正式開源后發布此部分功能，歡迎大家關注和互相交流。