龍蜥正式開源 Surftrace，協議包解析效率可提升 10 倍

作者 | 龍蜥社區系統運維 SIG

策劃 | 凌敏

Surftrace 是由系統運維 SIG 推出的一個 ftrace 封裝器和開發編譯平臺，讓用戶既能基於 libbpf 快速構建工程進行開發，也能作爲 ftrace 的封裝器進行 trace 命令編寫。

項目包含 Surftrace 工具集和 pylcc、glcc(python or generic C language for libbpf Compiler Collection)，提供遠程和本地 eBPF 的編譯能力。通過對 krobe 和 ftrace 相關功能最大化抽象，同時對各種場景下的追蹤能力增強（比如網絡協議抓包），使得用戶非常快速的上手，對定位問題效率提升 10 倍以上。

另外，現如今火到天際的技術——eBPF，Surftrace 支持通過 libbpf 及 CO-RE 能力，對 bpf 的 map 和 prog 等常用函數進行了封裝和抽象，基於此平臺開發的 libbpf 程序可以無差別運行在各個主流內核版本上，開發、部署和運行效率提升了一個數量級。

Surftrace 最大的優勢在於將當前主流的 trace 技術一併提供給廣大開發者，可以通過 ftrace 也可以使用 eBPF，應用場景覆蓋內存、IO 等 Linux 各個子系統，特別是在網絡協議棧跟蹤上面，對 skb 內部數據結構，網絡字節序處理做到行雲流水。

一、理解 Linux 內核協議棧

定位網絡問題是一個軟件開發者必備一項基礎技能，諸如 ping 連通性、tcpdump 抓包分析等手段，可以對網絡問題進行初步定界。然而，當問題深入內核協議棧內部，如何將網絡報文與內核協議棧清晰關聯起來，精準追蹤到關注的報文行進路徑呢？

1.1 網絡報文分層結構

引用自《TCP/IP 詳解》卷一。

如上圖所示，網絡報文對數據報文數據在不同層進行封裝。不同 OS 均採用一致的報文封裝方式，達到跨軟件平臺通訊的目的。

1.2 sk_buff 結構體

sk_buff 是網絡報文在 Linux 內核中的實際承載者，它在 include/linux/skbuff.h 文件中定義，結構體成員較多，本文不逐一展開。

用戶需要重點關注下面兩個結構體成員：

unsignedchar *head, *data;

其中 head 指向了緩衝區開始，data 指向了當前報文處理所在協議層的起始位置，如當前協議處理位於 tcp 層，data 指針就會指向 struct tcphdr。在 IP 層，則指向了 struct iphdr。因此，data 指針成員，是報文在內核處理過程中的關鍵信標。

1.3 內核網絡協議棧地圖

下圖是協議棧處理地圖，可以保存後放大觀看。

（圖源網絡）

不難發現，上圖中幾乎所有函數都涉及到 skb 結構體處理，因此要想深入瞭解網絡報文在內核的處理過程，skb->data 應該就是最理想的引路蜂。

二、Surftrace 對網絡報文增強處理

Surftrace 基於 ftrace 封裝，採用接近於 C 語言的參數語法風格，將原來繁瑣的配置流程優化到一行命令語句完成，極大簡化了 ftrace 部署步驟，是一款非常方便的內核追蹤工具。但是要追蹤網絡報文，光解析一個 skb->data 指針是遠遠不夠的。存在以下障礙：

• skb->data 指針在不同網絡層指向的協議頭並不固定；

• 除了獲取當前結構內容，還有獲取上一層報文內容的需求，比如一個我們在 udphdr 結構體中，是無法直接獲取到 udp 報文內容；

• 源數據呈現不夠人性化。如 ipv4 報文 IP 是以一個 u32 數據類型，可讀性不佳，過濾器配置困難。

針對上述困難，Surftrace 對 skb 傳參做了相應的特殊處理，以達到方便易用的效果。

2.1 網絡協議層標記處理

以追蹤網協議棧報文接收的入口 __netif_receive_skb_core 函數爲例，函數原型定義：

staticint__netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc,  struct packet_type **ppt_prev);

解析每個 skb 對應報文三層協議成員的方法：

surftrace 'p __netif_receive_skb_core proto=@(struct iphdr *)l3%0->protocol`

協議成員獲取方法爲 @(struct iphdr *)l3%0->protocol。

tips：

• 可以跨協議層向上解析報文結構體，如在 l3 層去分析 struct icmphdr 中的數據成員

• 不可以跨協議層向下解析報文結構體，如在 l4 層去分析 struct iphdr 中的成員

2.2 擴充下一層報文內容獲取方式

surftrace 爲 ethhdr、iphdr、icmphdr、udphdr、tcphdr 結構體添加了 xdata 成員，用於獲取下一層報文內容。xdata 有以下 5 類類型：

數組下標是按照位寬進行對齊的，比如要提取 icmp 報文中的 2~3 字節內容，組成一個 unsigned short 的數據，可以通過以下方法獲取：

data=@(struct icmphdr*)l3%0->sdata[1]

2.3 IP 和字節序模式轉換

網絡報文字節序採取的是大端模式，而我們的操作系統一般採用小端模式。同時，ipv4 採用了一個 unsigned int 數據類型來表示一個 IP，而我們通常習慣採用 1.2.3.4 的方式來表示一個 ipv4 地址。上述差異導致直接去解讀網絡報文內容的時候非常費力。surftrace 通過往變量增加前綴的方式，在數據呈現以及過濾的時候，將原始數據根據前綴命名規則進行轉換，提升可讀性和便利性。

2.4  牛刀小試

我們在一個實例上抓到一個非預期的 udp 報文，它會往目標 ip 10.0.1.221 端口號  9988 發送數據，現在想要確定這個報文的發送進程。由於 udp 是一種面向無連接的通訊協議，無法直接通過 netstat 等方式鎖定發送者。

用 Surftrace 可以在 ip_output 函數處中下鉤子：

intip_output(struct net *net, struct sock *sk, struct sk_buff *skb)

追蹤表達式：

surftrace 'p ip_output proto=@(struct iphdr*)l3%2->protocol ip_dst=@(struct iphdr*)l3%2->daddr b16_dest=@(struct udphdr*)l3%2->dest comm=$comm body=@(struct udphdr*)l3%2->Sdata[0] f:proto==17&&ip_dst==10.0.1.221&&b16_dest==9988'

追蹤結果：

surftrace 'p ip_output proto=@(struct iphdr*)l3%2->protocol ip_dst=@(struct iphdr*)l3%2->daddr b16_dest=@(struct udphdr*)l3%2->dest comm=$comm body=@(struct udphdr*)l3%2->Sdata[0] f:proto==17&&ip_dst==10.0.1.221&&b16_dest==9988' echo 'p:f0 ip_output proto=+0x9(+0xe8(%dx)):u8 ip_dst=+0x10(+0xe8(%dx)):u32 b16_dest=+0x16(+0xe8(%dx)):u16 comm=$comm body=+0x1c(+0xe8(%dx)):string' >> /sys/kernel/debug/tracing/kprobe_events echo 'proto==17&&ip_dst==0xdd01000a&&b16_dest==1063' > /sys/kernel/debug/tracing/instances/surftrace/events/kprobes/f0/filter echo 1 > /sys/kernel/debug/tracing/instances/surftrace/events/kprobes/f0/enable echo 0 > /sys/kernel/debug/tracing/instances/surftrace/options/stacktrace echo 1 > /sys/kernel/debug/tracing/instances/surftrace/tracing_on <...>-2733784 [014] .... 12648619.219880: f0: (ip_output+0x0/0xd0) proto=17 ip_dst=10.0.1.221 b16_dest=9988 comm="nc" body="Hello World\!  @"

通過上述命令，可以確定報文的發送的 pid 爲 2733784，進程名爲 nc。

三、實戰：定位網絡問題

接下來我們從一個實際網絡網絡問題出發，講述如何採用 Surftrace 定位網絡問題。

3.1 問題背景

我們有兩個實例通訊存在性能問題，經抓包排查，確認性能上不去的根因是存在丟包導致的。幸運的是，該問題可以通過 ping 對端復現，確認丟包率在 10% 左右。

通過進一步抓包分析，可以明確報文丟失在實例 B 內部。

通過檢查 /proc/net/snmp 以及分析內核日誌，沒有發現可疑的地方。

3.2 surftrace 跟蹤

在 1.1 節的地圖中，我們可以查到網絡報文是內核由 dev_queue_xmit 函數將報文推送到網卡驅動。因此，可以在這個出口先進行 probe，過濾 ping 報文，加上 -s 選項，打出調用棧：

surftrace 'p dev_queue_xmit proto=@(struct iphdr *)l2%0->protocol ip_dst=@(struct iphdr *)l2%0->daddr f:proto==1&&ip_dst==192.168.1.3' -s

可以獲取到以下調用棧：

由於問題復現概率比較高，我們可以將懷疑的重點方向先放在包發送流程中，即從 icmp_echo 函數往上，用 Surftrace 在每一個符號都加一個 trace 點，追蹤下回包到底消失在哪裏。

3.3 鎖定丟包點

問題追蹤到了這裏，對於經驗豐富的同學應該是可以猜出丟包原因。我們不妨純粹從代碼角度出發，再找一下準確的丟包位置。結合代碼分析，我們可以在函數內部找到以下兩處 drop 點：

通過 Surftrace 函數內部追蹤功能，結合彙編代碼信息，可以明確丟包點是出在了 qdisc->enqueue 鉤子函數中。

rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;

此時，可以結合彙編信息：

找到鉤子函數存入的寄存名爲 bx，然後通過 surftrace 打印出來。

surftrace 'p dev_queue_xmit+678 pfun=%bx'

然後將 pfun 值在 /proc/kallsyms 查找匹配。

至此可以明確是 htb qdisc 導致丟包。確認相關配置存在問題後，將相關配置回退，網絡性能得以恢復。

四、總結

Surftrace 在網絡層面的增強，使得用戶只需要有相關的網絡基礎和一定的內核知識儲備，就可以用較低編碼工作量達到精準追蹤網絡報文在 Linux 內核的完整處理過程。適合用於追蹤 Linux 內核協議棧代碼、定位深層次網絡問題。

參考文獻：

【1】《TCP/IP 詳解》

【2】《Linux 內核設計與實現》

【3】《深入理解 Linux 網絡技術內幕》

【4】surftrace readmde：

https://github.com/aliyun/surftrace/blob/master/ReadMe.md

【5】https://lxr.missinglinkelectronics.com

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/2J4hXDTDXdX2p0-3oIipyA