深入理解Linux內核協議棧 Surftrace對網絡報文增強處理
文/系統運維 SIG
通過對 krobe 和 ftrace 相關功能最大化抽象，同時對各種場景下的追蹤能力增強（比如網絡協議抓包），使得用戶非常快速的上手，對定位問題效率提升 10 倍以上。另外，現如今火到天際的技術——eBPF，Surftrace 支持通過 libbpf 及 CO-RE 能力，對 bpf 的 map 和 prog 等常用函數進行了封裝和抽象，基于此平臺開發的 libbpf 程序可以無差別運行在各個主流內核版本上，開發、部署和運行效率提升了一個數量級。
Surftrace 最大的優勢在于將當前主流的 trace 技術一并提供給廣大開發者，可以通過 ftrace 也可以使用 eBPF，應用場景覆蓋內存、IO 等 Linux 各個子系統，特別是在網絡協議棧跟蹤上面，對 skb 內部數據結構，網絡字節序處理做到行云流水，把復雜留給自己，簡單留給你。今天就讓我們來見識一下 Surftrace 在網絡領域的強勁表現吧。
如上圖所示，網絡報文對數據報文數據在不同層進行封裝。不同 OS 均采用一致的報文封裝方式，達到跨軟件平臺通訊的目的。
tips：
數組下標是按照位寬進行對齊的，比如要提取 icmp 報文中的 2~3 字節內容，組成一個 unsigned short 的數據，可以通過以下方法獲取：
通過進一步抓包分析，可以明確報文丟失在實例 B 內部。
通過檢查 /proc/net/snmp 以及分析內核日志，沒有發現可疑的地方。
由于問題復現概率比較高，我們可以將懷疑的重點方向先放在包發送流程中，即從 icmp_echo 函數往上，用 Surftrace 在每一個符號都加一個 trace 點，追蹤下回包到底消失在哪里。
通過 Surftrace 函數內部追蹤功能，結合匯編代碼信息，可以明確丟包點是出在了 qdisc->enqueue 鉤子函數中。
找到鉤子函數存入的寄存名為 bx，然后通過 surftrace 打印出來。
至此可以明確是 htb qdisc 導致丟包。確認相關配置存在問題后，將相關配置回退，網絡性能得以恢復。
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 內部數據結構，網絡字節序處理做到行云流水，把復雜留給自己，簡單留給你。今天就讓我們來見識一下 Surftrace 在網絡領域的強勁表現吧。
一、理解 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 數據類型，可讀性不佳，過濾器配置困難。
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 類類型：| 數據 | 數據類型 | 數據長度（字節） |
| cdata | unsgined char [] | 1 |
| sdata | unsigned short [] | 2 |
| ldata | unsigned int [] | 4 |
| qdata | unsigned long long [] | 8 |
| Sdata | char* [] | 字符串 |
data=@(struct icmphdr*)l3%0->sdata[1]
2.3 IP 和字節序模式轉換
網絡報文字節序采取的是大端模式，而我們的操作系統一般采用小端模式。同時，ipv4 采用了一個 unsigned int 數據類型來表示一個 IP，而我們通常習慣采用 1.2.3.4 的方式來表示一個 ipv4 地址。上述差異導致直接去解讀網絡報文內容的時候非常費力。surftrace 通過往變量增加前綴的方式，在數據呈現以及過濾的時候，將原始數據根據前綴命名規則進行轉換，提升可讀性和便利性。| 前綴名 | 數據輸出形式 | 數據長度(字節) |
| ip_ | a.b.c.d | ip字符串 |
| b16_ | 10 進制 | 2 |
| b32_ | 10 進制 | 4 |
| b64_ | 10 進制 | 8 |
| B16_ | 16 進制 | 2 |
| B32_ | 16 進制 | 4 |
| B64_ | 16 進制 | 8 |
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 內核協議棧代碼、定位深層次網絡問題。
原文標題：龍蜥開源內核追蹤利器 Surftrace：協議包解析效率提升 10 倍！ | 龍蜥技術
文章出處：【微信公眾號：Linux閱碼場】歡迎添加關注！文章轉載請注明出處。
審核編輯：湯梓紅
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。
舉報投訴
-
內核
+關注
關注
3文章
1372瀏覽量
40280 -
Linux
+關注
關注
87文章
11292瀏覽量
209333 -
封裝器
+關注
關注
0文章
7瀏覽量
5866
原文標題：龍蜥開源內核追蹤利器 Surftrace：協議包解析效率提升 10 倍！ | 龍蜥技術
文章出處：【微信號：LinuxDev，微信公眾號：Linux閱碼場】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
相關推薦
Linux內核網絡協議棧技術解讀
Netfilter 是報文在內核協議棧必然會通過的路徑，我們從下面這張圖就可以看到，Netfilter 在內核的 5 個地方設置了 HOOK
發表于 11-16 12:27
?1326次閱讀
深入理解和實現RTOS_連載
臺系統相比較，多任務可以理解為有多個后臺程序的前后臺系統，其中的每個任務都專注自己處理的問題，而這些任務間則需要處理一下彼此的溝通問題......深入理解和實現RTOS_連載3_多任務
發表于 05-29 11:20
深入理解和實現RTOS_連載
，其中的每個任務都專注自己處理的問題，而這些任務間則需要處理一下彼此的溝通問題......深入理解和實現RTOS_連載3_多任務機制設計前面我們已經介紹過了在單核處理器上的多任務機制的
發表于 05-30 01:02
為什么要深入理解棧
[導讀] 從這篇文章開始，將會不定期更新關于嵌入式C語言編程相關的個人認為比較重要的知識點，或者踩過的坑。為什么要深入理解棧？做C語言開發如果棧設置不合理或者使用不對，棧就會溢出，溢出
發表于 02-15 06:09
深入理解LINUX內核（中文版）_ 陳莉君/馮銳/牛欣源譯
電子發燒友網站提供《深入理解LINUX內核（中文版）_ 陳莉君/馮銳/牛欣源譯.txt》資料免費下載
發表于 02-11 11:16
?0次下載
米爾科技Linux網絡技術內幕淺談
Linux如此的流行正是得益于它的特性豐富及有效的網絡協議棧。如果你曾經驚嘆于Linux能夠實現如此復雜的工作，或者你只是想通過現實中的例子
Linux網絡技術中最核心的部分--TCP/IP協議棧
今天給大家介紹Linux網絡技術中最核心的部分--TCP/IP協議棧 。 我們先看一下抽象的網絡協議
STM32編程：是時候深入理解棧了<一>
為什么要深入理解棧？做C語言開發如果棧設置不合理或者使用不對，棧就會溢出，溢出就會遇到無法預測亂飛現象。所以對棧的
發表于 01-26 17:55
?2次下載
工商網監
評論