作為一個(gè)常年跟服務(wù)器性能較勁的人我第一次接觸XDP是在一次深夜壓測。CPU跑滿、軟中斷飆紅網(wǎng)卡卻還在拼了命地往協(xié)議棧里塞包。那會兒我意識到Linux內(nèi)核那套通用處理路徑在真正的海量流量面前確實(shí)有點(diǎn)力不從心。后來聽說XDP能在驅(qū)動層直接處理報(bào)文比傳統(tǒng)iptables和iptables的netfilter路徑快一個(gè)數(shù)量級我立刻動手試了一圈——這篇文章就是我自己從原理到實(shí)測、從踩坑到調(diào)優(yōu)的完整記錄。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么需要XDP這種另類的數(shù)據(jù)路徑傳統(tǒng)的網(wǎng)絡(luò)收包流程基本上是這樣網(wǎng)卡DMA數(shù)據(jù)到內(nèi)核環(huán)形緩沖區(qū)然后觸發(fā)硬中斷緊接著軟中斷ksoftirqd開始處理依次經(jīng)過協(xié)議棧的各層——鏈路層、網(wǎng)絡(luò)層、傳輸層最終把socket掛到用戶態(tài)進(jìn)程的等待隊(duì)列里。這套邏輯設(shè)計(jì)得相當(dāng)通用也相當(dāng)穩(wěn)定問題在于太穩(wěn)了。每收一個(gè)普通TCP小包內(nèi)核要做的事情多達(dá)幾十步從sk_buff分配、路由查找、netfilter鉤子到最終喚醒進(jìn)程每個(gè)環(huán)節(jié)都有鎖、有緩存miss、有內(nèi)存分配。如果你只是平時(shí)訪問個(gè)網(wǎng)頁、傳幾個(gè)文件這套機(jī)制綽綽有余?？梢坏┝髁康搅税偃fPPS以上事情就開始變質(zhì)。所有CPU核的軟中斷占用居高不下但你實(shí)際業(yè)務(wù)處理的包不到一半——絕大多數(shù)數(shù)據(jù)包要么該丟的沒丟要么根本不需要走到應(yīng)用層。當(dāng)我第一次看到XDP的性能數(shù)據(jù)時(shí)確實(shí)被驚到了官方基準(zhǔn)測試中單核處理能力可以輕松超過20M PPS取決于硬件和程序邏輯而在同等硬件上傳統(tǒng)netfilter路徑大概能跑到1M PPS就很吃力了。差距如此懸殊是因?yàn)閄DP把處理點(diǎn)挪到了網(wǎng)卡驅(qū)動剛拿到數(shù)據(jù)、甚至還在DMA緩沖區(qū)里的時(shí)候。XDP的主要思路是盡量少做事。它不分配sk_buff不復(fù)用協(xié)議棧的路徑也不維護(hù)完整的連接狀態(tài)。它只給你一個(gè)xdp_md結(jié)構(gòu)體里面放著數(shù)據(jù)包的起始偏移、結(jié)束偏移和入接口你的eBPF程序就是在這個(gè)極簡的框子上做邏輯判斷。能XDP_DROP掉的就絕不讓它進(jìn)入內(nèi)核更深處能XDP_PASS放行的盡量原封不動交給協(xié)議棧。這個(gè)設(shè)計(jì)思路總結(jié)成一句話就是讓該消失的包在最便宜的地方消失讓真正有價(jià)值的流量走最少的路。1.2 對比傳統(tǒng)內(nèi)核網(wǎng)絡(luò)路徑的效率差距我拿自己測試機(jī)上做過對比用DPDK基準(zhǔn)工具和自寫的eBPF程序看包處理時(shí)延和吞吐。傳統(tǒng)收包模式在單隊(duì)列、單核情況下跑到400K PPS左右CPU就接近滿負(fù)荷。同樣的硬件加載一個(gè)簡單的XDP程序做全量DROP也就是把進(jìn)來的所有包都丟了單核吞吐量能到24M PPS時(shí)延抖動幾乎可以忽略。這個(gè)對比不是說傳統(tǒng)協(xié)議棧一無是處而是說它們出生在不同的年代面對的流量量級完全不同。讓我用一個(gè)生活中的例子解釋一下這個(gè)差距社區(qū)保安亭門口有條主干道所有進(jìn)小區(qū)的車都要停下來登記傳統(tǒng)協(xié)議棧。如果某天來做核酸的隊(duì)伍特別長你只需要看車牌、分流量、能勸返的勸返、該放行的放行XDP而不是把所有車都引導(dǎo)到登記處。這次疫情管控的實(shí)戰(zhàn)就是XDP最擅長的事情——在入口處做快速分流。這個(gè)效率差距不是靠優(yōu)化代碼就能彌平的因?yàn)閭鹘y(tǒng)路徑本身就是為完整性設(shè)計(jì)的它必須保證TCP重傳、分片重組、socket buffer分配、防火墻規(guī)則、路由選擇等全都可追溯可管理。而XDP刻意放棄了這些通用性換取的是極致的速度和確定性。你說XDP能不能做TCP狀態(tài)跟蹤可以但內(nèi)核里早就有conntrack在做這個(gè)事XDP最大的價(jià)值不是替代協(xié)議棧而是在協(xié)議棧之前當(dāng)守門員。1.3 為什么這個(gè)方案的護(hù)城河是eBPF而不是XDP本身我見過不少人對XDP有個(gè)誤解以為它是什么靈丹妙藥裝上就快了。其實(shí)XDP本身只是個(gè)框架真正決定你能做什么的是掛載在XDP鉤子上的eBPF程序。剛接觸eBPF時(shí)它的編程體驗(yàn)非常糟糕——你必須用受限于內(nèi)核verifier的指令集來寫代碼不能任意循環(huán)早期版本甚至不允許有循環(huán)不能訪問任意內(nèi)核內(nèi)存棧大小只有512字節(jié)。這些限制逼著你用最精簡的方式表達(dá)邏輯但也正因?yàn)檫@些限制XDP程序才能在內(nèi)核里安全、高性能地運(yùn)行。eBPF之于XDP有點(diǎn)像是電動賽車和賽道的配合XDP提供了一條直達(dá)終點(diǎn)的快車道而eBPF是決定你在這條車道上怎么打方向的駕駛員。如果你不會eBPFXDP對你來說只是一個(gè)只能丟掉所有包的開關(guān)而會了eBPF你就能在網(wǎng)卡入口處做流量過濾、負(fù)載均衡、流量統(tǒng)計(jì)、DDoS防護(hù)甚至直接修改數(shù)據(jù)包內(nèi)容再轉(zhuǎn)發(fā)出去。所以我把XDPeBPF賦能的高性能網(wǎng)絡(luò)加速這個(gè)項(xiàng)目拆成兩半一半是XDP技術(shù)的理解另一半是eBPF編程的落地。只有把兩者結(jié)合起來才能發(fā)揮出真正的威力。這也是后文所有配置、代碼示例和排錯(cuò)思路的出發(fā)點(diǎn)。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 XDP工作模式與程序掛載方式我們要先把XDP的三種運(yùn)行模式搞明白因?yàn)樗鼈冎苯佑绊懶阅鼙憩F(xiàn)和適用場景。第一種叫native XDP直接掛載在網(wǎng)卡驅(qū)動的NAPI poll循環(huán)里。這種模式不經(jīng)過sk_buff數(shù)據(jù)還在DMA緩沖區(qū)里就能處理速度最快。前提是你的網(wǎng)卡驅(qū)動要支持XDP像Intel的i40e/ice、Mellanox的mlx5、Broadcom的bnxt_en這些都支持得不錯(cuò)。第二種叫offloaded XDP是直接把eBPF程序編譯成網(wǎng)卡固件能識別的微碼下載到網(wǎng)卡硬件里跑。這種模式的性能理論上最強(qiáng)因?yàn)檫BCPU都不需要經(jīng)過但受限于網(wǎng)卡內(nèi)置的處理能力支持的指令和map操作非常有限我在實(shí)際項(xiàng)目中基本沒遇到過需要offload的場景——大部分人的網(wǎng)卡也不支持。第三種叫g(shù)eneric XDP這是最軟的一種。它把XDP的處理點(diǎn)位模擬到協(xié)議棧的入口處不要求網(wǎng)卡驅(qū)動支持。代碼上能寫一樣的eBPF程序性能上卻和native XDP差了一個(gè)數(shù)量級——因?yàn)樗€是會在內(nèi)核里走cache和鎖的路徑只是換了一個(gè)hook點(diǎn)接收數(shù)據(jù)。我強(qiáng)烈建議如果你只是想學(xué)習(xí)XDP程序開發(fā)或者做功能驗(yàn)證generic XDP足夠用了但如果你想解決生產(chǎn)環(huán)境的性能問題還是老老實(shí)實(shí)上支持native XDP的網(wǎng)卡。掛載方式推薦用bpftool簡單直接。# 將編譯好的xdp_prog.o掛載到eth0的XDP鉤子上 bpftool net attach xdp pinned /sys/fs/bpf/xdp_prog dev eth0 # 查看當(dāng)前網(wǎng)卡上的XDP程序 bpftool net show dev eth0 # 卸載XDP程序 bpftool net detach xdp dev eth0掛載完成后如果你用ss -tulnp或者ethtool -S eth0觀察會看到一些計(jì)數(shù)器變化。比如rx_dropped會激增——這正是XDP把包丟掉后的正?，F(xiàn)象千萬別把它當(dāng)成丟包故障。2.2 eBPF程序結(jié)構(gòu)、verifier約束與編程習(xí)慣寫XDP程序時(shí)用的編程語言嚴(yán)格來說不是C而是受限的C。你編譯出來的目標(biāo)文件是ELF格式內(nèi)核加載器會把里面的eBPF指令片段提取出來再由verifier做一堆安全性驗(yàn)證。這個(gè)過程令人又愛又恨它保證了任何情況下內(nèi)核都不會被寫壞的eBPF程序搞崩潰但也意味著你的很多正常C語言寫法根本通不過編譯驗(yàn)證。我整理了一份很實(shí)用的避坑清單禁止循環(huán)。如果你的程序里有for(;;)或者while(;;)verifier會直接reject。早期eBPF甚至不允許跳回指令現(xiàn)在內(nèi)核5.3支持bounded loop但循環(huán)次數(shù)必須是編譯期常量且總指令數(shù)限制在100萬以內(nèi)。所以編程時(shí)要改成逐步展開的邏輯或者用map存儲狀態(tài)來替代循環(huán)。?？臻g只有512字節(jié)。你不能在函數(shù)里聲明一個(gè)1KB的局部數(shù)組否則編譯過不了。處理包內(nèi)容時(shí)要注意使用bpf_skb_load_bytes或者bpf_xdp_load_bytes這種helper來按需讀取數(shù)據(jù)而不是直接解引用指針。禁止任意指針運(yùn)算。只有數(shù)據(jù)包指針的訪問范圍是verifier認(rèn)可的其他指針必須在map中的value值范圍內(nèi)操作。用C語言寫eBPF要去掉很多野路子習(xí)慣。helper函數(shù)數(shù)量有限。不是所有內(nèi)核函數(shù)都能調(diào)用你只能調(diào)bpf開頭的helper比如bpf_map_lookup_elem、bpf_ktime_get_ns、bpf_xdp_adjust_head等等。XDP特有的一部分helper我用熟了之后覺得基本功就是這幾個(gè)。一個(gè)最基本的XDP程序長這樣功能是統(tǒng)計(jì)TCP和UDP包數(shù)量其中UDP直接DROP#include linux/bpf.h #include linux/if_ether.h #include linux/ip.h #include linux/udp.h #include bpf/bpf_helpers.h struct { __uint(type, BPF_MAP_TYPE_ARRAY); __uint(max_entries, 2); __type(key, __u32); __type(value, __u64); } pkt_cnt_map SEC(.maps); SEC(xdp) int xdp_filter_prog(struct xdp_md *ctx) { void *data_end (void *)(long)ctx-data_end; void *data (void *)(long)ctx-data; struct ethhdr *eth data; if ((void *)eth sizeof(*eth) data_end) return XDP_PASS; if (eth-h_proto ! __constant_htons(ETH_P_IP)) return XDP_PASS; struct iphdr *ip (void *)(eth 1); if ((void *)ip sizeof(*ip) data_end) return XDP_PASS; __u32 key 0; if (ip-protocol IPPROTO_TCP) { key 0; __u64 *cnt bpf_map_lookup_elem(pkt_cnt_map, key); if (cnt) __sync_fetch_and_add(cnt, 1); return XDP_PASS; } else if (ip-protocol IPPROTO_UDP) { key 1; __u64 *cnt bpf_map_lookup_elem(pkt_cnt_map, key); if (cnt) __sync_fetch_and_add(cnt, 1); return XDP_DROP; } return XDP_PASS; } char _license[] SEC(license) GPL;這段代碼的每個(gè)判斷都是為了防止越界訪問data_end。這里有一個(gè)很關(guān)鍵的編程習(xí)慣所有對數(shù)據(jù)包字段的訪問都必須先做邊界檢查。verifier要求你證明訪問是安全的否則它會認(rèn)為你存在越界讀取的risk直接拒絕加載。我最早寫的程序因?yàn)橥藱z查IP頭邊界被verifier拒了不下十幾次后來才明白這是它的工作方式——寧可錯(cuò)殺也不放過。2.3 map的作用與高頻路徑設(shè)計(jì)map是eBPF世界里有狀態(tài)的關(guān)鍵載體。你可以在一個(gè)XDP程序里讀取或者更新map里保存的數(shù)據(jù)讓網(wǎng)絡(luò)處理邏輯擁有記憶能力。最常見的map類型有數(shù)組ARRAY、哈希HASH、LRU哈希LRU_HASH、per-CPU數(shù)組PERCPU_ARRAY等等。對你來說一個(gè)很實(shí)用的建議是計(jì)數(shù)器用PERCPU_ARRAY規(guī)則表用HASH或LRU_HASH狀態(tài)追蹤用HASH。原因是per-CPU能避免多核并發(fā)寫同一個(gè)內(nèi)存位置的鎖競爭把更新操作變成每個(gè)CPU各自一份拷貝讀取時(shí)再sum起來這在跑滿多隊(duì)列網(wǎng)卡時(shí)能明顯減少開銷。下面這段代碼演示了如何用per-CPU數(shù)組保存每個(gè)CPU收到的包數(shù)struct { __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); __uint(max_entries, 1); __type(key, __u32); __type(value, __u64); } pkt_percpu_cnt SEC(.maps);在程序里更新的時(shí)候就像操作普通數(shù)組一樣__u32 key 0; __u64 *cnt bpf_map_lookup_elem(pkt_percpu_cnt, key); if (cnt) *cnt 1;然后你通過bpf_map_get_info_by_fd或者bpftool map dump觀察會發(fā)現(xiàn)每個(gè)CPU一個(gè)條目非常便于分析流量分布。如果要在用戶態(tài)匯總?cè)坑?jì)數(shù)掃描一遍map然后逐項(xiàng)相加即可。2.4 XDP_PASS、XDP_DROP、XDP_TX和XDP_REDIRECT的含義返回值是XDP程序的出口決策初學(xué)者常常搞不清它們的具體行為以及性能影響。我拿實(shí)際場景一個(gè)個(gè)說清楚XDP_PASS當(dāng)前包交給內(nèi)核協(xié)議棧繼續(xù)處理。相當(dāng)于我看了但不管你們該干嘛干嘛。這個(gè)返回值的開銷最高因?yàn)樗€要走完整的棧但在不能誤殺流量時(shí)只能這么選。XDP_DROP直接丟棄這個(gè)包。這個(gè)開銷最低非常適合做DDoS防護(hù)、黑名單IP攔截、無效協(xié)議過濾。注意XDP_DROP不會觸發(fā)netfilter的DROP規(guī)則也不會記錄日志完全由你的eBPF程序控制。XDP_TX從入接口直接把這個(gè)包再發(fā)出去。如果你要做透明防火墻的包回射、或者簡單的二層轉(zhuǎn)發(fā)比如把進(jìn)來的廣播包返回這個(gè)用起來很方便。它不需要經(jīng)過ARP、路由等邏輯所以轉(zhuǎn)發(fā)時(shí)延極低。XDP_REDIRECT把包重定向到其他網(wǎng)卡、其他CPU的ring或者用戶態(tài)的AF_XDP套接字。這是XDP生態(tài)里最強(qiáng)也最復(fù)雜的出口。用bpf_redirect_map helper實(shí)現(xiàn)多網(wǎng)卡之間的負(fù)載均衡時(shí)性能和可擴(kuò)展性極其出色。返回值的選擇決定了你的功能邊界也決定了性能天花板。在設(shè)計(jì)階段先把數(shù)據(jù)包分類好黑名單流量直接XDP_DROP白名單流量XDP_PASS需要轉(zhuǎn)發(fā)的流量走XDP_REDIRECT。這比把所有邏輯都塞進(jìn)XDP_TX要清晰得多。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與工具鏈搭建寫XDP的eBPF程序你需要準(zhǔn)備一套完整的編譯環(huán)境。我的建議是基于Ubuntu 22.04 LTS或者Rocky Linux 9內(nèi)核版本最好在5.15以上因?yàn)槲覍?shí)測下來有些老內(nèi)核的verifier對XDP程序的限制太多會卡住很多比較自然的代碼寫法。接著安裝編譯工具鏈# Ubuntu/Debian系 apt-get update apt-get install -y clang llvm libbpf-dev linux-tools-common linux-tools-generic # 如果你用的內(nèi)核自帶bpftool不在包庫里從內(nèi)核源碼編譯 git clone --depth 1 https://github.com/libbpf/bpftool.git cd bpftool/src make make install這里有個(gè)容易踩的坑很多系統(tǒng)自帶一個(gè)老舊的/usr/sbin/bpftool可能是從iproute2中繼承下來的舊版本功能不全。我建議自己編譯一個(gè)最新版并且把庫路徑設(shè)置好export PKG_CONFIG_PATH/usr/lib/x86_64-linux-gnu/pkgconfig然后編譯你的第一個(gè)XDP程序clang -O2 -g -Wall -target bpf -c xdp_filter.c -o xdp_filter.o關(guān)鍵參數(shù)解釋一下-target bpf告訴編譯器生成BPF目標(biāo)代碼-O2是必需的優(yōu)化級別因?yàn)閮?yōu)化后的代碼更容易通過verifier。如果加了-g你能在bpftool prog dump xlated里看到帶行號的指令對應(yīng)調(diào)試體驗(yàn)會好很多。3.2 加載程序并綁定到指定網(wǎng)卡編譯出.o文件后第一階段用bpftool加載測試。我習(xí)慣先看程序是否合法再綁定到網(wǎng)卡# 先加載到內(nèi)核但不綁定網(wǎng)卡加載成功說明verifier校驗(yàn)過了 bpftool prog load ./xdp_filter.o /sys/fs/bpf/xdp_filter # 查看加載的程序和ID bpftool prog show bpftool prog dump xlated id 123 # 確認(rèn)沒問題后再attach到網(wǎng)卡 bpftool net attach xdp pinned /sys/fs/bpf/xdp_filter dev eth0加個(gè)細(xì)節(jié)如果你在/proc/sys/net/core/bpf_jit_enable里開啟了JIT默認(rèn)應(yīng)該就是開啟的eBPF指令會在內(nèi)核里被編譯成原生指令執(zhí)行效率會高很多。你可以檢查一下cat /proc/sys/net/core/bpf_jit_enable # 輸出1表示JIT已開啟如果輸出是0用sysctl臨時(shí)開啟sysctl -w net.core.bpf_jit_enable13.3 用iperf和pktgen驗(yàn)證加速效果測試XDP不能光看理論要用工具量化對比。我常用的組合是前后流量生成器pktgen內(nèi)核自帶在samples/pktgen目錄下和iperf3。先說pktgen它能以極高的速率發(fā)送指定大小的UDP包特別適合壓測純XDP路徑的極限性能。pktgen的使用步驟可以寫成腳本大致邏輯如下modprobe pktgen PG/proc/net/pktgen/kpktgend_0 PGDEV/proc/net/pktgen/eth0 # 清空之前的配置 echo rem_device_all $PG echo add_device eth0 $PG # 配置發(fā)送參數(shù) echo count 10000000 $PGDEV echo pkt_size 64 $PGDEV echo dst 192.168.1.2 $PGDEV echo src_mac 00:11:22:33:44:55 $PGDEV echo dst_mac 00:11:22:33:44:66 $PGDEV # 開始發(fā)送 echo start $PG上面的命令如果寫成一行執(zhí)行記得把文件路徑都替換成你實(shí)際的網(wǎng)卡名和IP。pktgen發(fā)出去的包會擠爆接收端所以你要先在接收端加載好XDP程序并把結(jié)果打出來然后對比不加載時(shí)的狀況。如果你更想看到業(yè)務(wù)可從的帶寬效果用iperf3做TCP/UDP吞吐測試也行# 服務(wù)端接收XDP流量的機(jī)器 iperf3 -s # 客戶端發(fā)送方 iperf3 -c 192.168.1.2 -t 30 -i 1 -u -b 1000M跑了測試之后你會發(fā)現(xiàn)一個(gè)重要現(xiàn)象凡是XDP_DROP的包netstat里的dropped計(jì)數(shù)并不等于實(shí)際丟棄數(shù)因?yàn)閄DP的丟包發(fā)生在驅(qū)動層根本沒有進(jìn)入?yún)f(xié)議棧統(tǒng)計(jì)。這時(shí)候要看ethtool的rx_dropped和rx_missed或者直接用bpftool map dump查看我們程序里的計(jì)數(shù)器。3.4 真實(shí)業(yè)務(wù)場景配置禁IP、限速與統(tǒng)計(jì)一個(gè)比較有實(shí)際參考價(jià)值的場景是利用XDP快速封禁某個(gè)攻擊源IP。傳統(tǒng)做法是在iptables里加一條DROP規(guī)則規(guī)則數(shù)量大了之后netfilter遍歷會消耗不少CPU。用XDP來實(shí)現(xiàn)只需要在map里插入一個(gè)IPXDP程序在入口處直接查表、命中則DROP干凈的思路。封裝一個(gè)哈希mapkey為IP地址32位主機(jī)序value為計(jì)數(shù)struct { __uint(type, BPF_MAP_TYPE_LRU_HASH); __uint(max_entries, 100000); __type(key, __u32); __type(value, __u64); } block_ip_map SEC(.maps);然后在XDP程序里加一個(gè)查表動作__u32 ip ip-saddr; // 注意這里通常需要ntohl轉(zhuǎn)為主機(jī)序 __u64 *cnt bpf_map_lookup_elem(block_ip_map, ip); if (cnt) { *cnt 1; return XDP_DROP; } return XDP_PASS;用戶態(tài)用bpftool直接操作map添加被封禁IP# 阻塞192.168.100.10的流量 bpftool map update name block_ip_map key hex 0a 64 00 0a value hex 00 00 00 00 00 00 00 00這里要注意key的大小端問題。我一開始總是把IP地址搞反后來干脆用htonl轉(zhuǎn)換之后再寫key免去了換算的困擾。限速也能做只是需要配合時(shí)間戳邏輯。一個(gè)相對簡單的上限速實(shí)現(xiàn)用LRU_HASH存每個(gè)源IP的包數(shù)和起始時(shí)間當(dāng)包速率超過閾值時(shí)對超出部分返回XDP_DROP。實(shí)現(xiàn)代碼稍微長一些但原理清晰可讀struct rate_limit_info { __u64 start_ns; __u64 pkt_count; }; struct { __uint(type, BPF_MAP_TYPE_LRU_HASH); __uint(max_entries, 100000); __type(key, __u32); __type(value, struct rate_limit_info); } rate_limit_map SEC(.maps); #define MAX_PKT_RATE 10000 #define WINDOW_NS 1000000000ULL // 1秒 SEC(xdp) int xdp_rate_limit(struct xdp_md *ctx) { void *data_end (void *)(long)ctx-data_end; void *data (void *)(long)ctx-data; struct ethhdr *eth data; if ((void *)eth sizeof(*eth) data_end) return XDP_PASS; struct iphdr *ip (void *)(eth 1); if ((void *)ip sizeof(*ip) data_end) return XDP_PASS; __u32 ip ip-saddr; struct rate_limit_info *info bpf_map_lookup_elem(rate_limit_map, ip); __u64 now bpf_ktime_get_ns(); if (!info) { struct rate_limit_info new_info; new_info.start_ns now; new_info.pkt_count 1; bpf_map_update_elem(rate_limit_map, ip, new_info, BPF_ANY); return XDP_PASS; } if (now - info-start_ns WINDOW_NS) { info-start_ns now; info-pkt_count 1; return XDP_PASS; } info-pkt_count; if (info-pkt_count MAX_PKT_RATE) return XDP_DROP; return XDP_PASS; }這種方案能應(yīng)對比較粗粒度的限速需求。當(dāng)然如果你想做得更精確比如按字節(jié)限速、支持burst等那就需要更復(fù)雜的計(jì)算和更多的map協(xié)同文末我會提一點(diǎn)思路。3.5 AF_XDP從XDP到用戶態(tài)的高性能通道XDP還有一個(gè)重要變化方向是AF_XDP套接字。簡單說它允許你把數(shù)據(jù)包從XDP路徑直接redirect到用戶態(tài)程序的socket接收隊(duì)列里完全繞過內(nèi)核協(xié)議棧卻保留了標(biāo)準(zhǔn)socket的編程接口。這對于想做高性能用戶態(tài)網(wǎng)絡(luò)處理比如私有協(xié)議解析、報(bào)文捕獲、簡單NAT的人來說是個(gè)很好的折中方案不用像DPDK那樣接管整個(gè)網(wǎng)卡、寫PMD驅(qū)動而是只在特定隊(duì)列上做快速通道其他流量照常走協(xié)議棧。AF_XDP的配置過程不復(fù)雜但涉及幾個(gè)組件umem用戶態(tài)內(nèi)存池、fill queue內(nèi)核填充數(shù)據(jù)給用戶態(tài)、rx queue用戶態(tài)接收數(shù)據(jù)包、tx queue發(fā)送和completion queue發(fā)送完成通知。這里的關(guān)鍵教訓(xùn)是確保umem的大小、隊(duì)列深度和網(wǎng)卡隊(duì)列數(shù)量配置協(xié)調(diào)否則會丟包。我踩過的一個(gè)很常見的坑是——把fill queue塞滿后程序一跑發(fā)現(xiàn)rx queue里包越來越多但fill queue空著然后產(chǎn)生丟包。因?yàn)閮?nèi)核沒有可以存放新報(bào)文的buffer了。解決辦法是在用戶態(tài)循環(huán)里及時(shí)refill。AF_XDP的配置示例代碼比較長我摘取核心部分struct xsk_umem_info { struct xdp_umem *umem; void *buffer; struct xsk_ring_prod fq; struct xsk_ring_cons cq; }; struct xsk_socket_info { struct xsk_ring_cons rx; struct xsk_ring_prod tx; struct xsk_socket *xsk; struct xsk_umem_info *umem; }; // 創(chuàng)建UMEM struct xsk_umem_config umem_cfg { .fill_size 1024, .comp_size 1024, .frame_size 2048, .frame_headroom 0, .flags 0 }; void *buffer mmap(NULL, umem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); int umem_fd xsk_umem__create(umem, buffer, umem_size, fq, cq, umem_cfg);然后把socket bind到指定網(wǎng)卡隊(duì)列在XDP程序里用bpf_redirect_map把包指向AF_XDP的map。整套配置下來你會掉進(jìn)一個(gè)新手都會掉進(jìn)的坑網(wǎng)卡的隊(duì)列數(shù)必須大于等于你要綁定的隊(duì)列索引而且想用AF_XDP的隊(duì)列不應(yīng)該再被內(nèi)核協(xié)議棧正常處理否則同一隊(duì)列會有兩份流量。3.6 把多個(gè)XDP程序裝進(jìn)同一張網(wǎng)卡的現(xiàn)代做法內(nèi)核在較新版本里支持了XDP的多程序掛載multi-buffer和multi-prog其實(shí)不是一回事前者是指處理超過單幀大小的包后者是指同一接口上能掛多個(gè)XDP程序。我實(shí)際操作時(shí)最常用的是通過bpftool鏈?zhǔn)綊燧d# 先掛載第一個(gè)程序 bpftool net attach xdp pinned /sys/fs/bpf/prog1 dev eth0 # 再添加第二個(gè)程序此時(shí)內(nèi)核會創(chuàng)建prog chain bpftool net attach xdp pinned /sys/fs/bpf/prog2 dev eth0其實(shí)這種方式還不算特別成熟不同內(nèi)核的行為有差異。生產(chǎn)環(huán)境我更推薦用tc的bpf鉤子做第二道處理或者干脆用libbpf的bpf_xdp_attach帶XDP_FLAGS_REPLACE參數(shù)自己管理。如果你只是簡單測試?yán)侠蠈?shí)實(shí)依法加載一個(gè)綜合的XDP程序把所有邏輯寫在一起反而可控性更強(qiáng)。畢竟XDP程序之間組合時(shí)要考慮調(diào)用棧深度和執(zhí)行順序關(guān)系踩坑成本不比寫一個(gè)長程序低。3.7 高層封裝用bpf_xdp_link的方式管理生命周期你可能已經(jīng)發(fā)現(xiàn)bpftool net attach的方式雖然方便但程序是由netlink管理的退出shell或用systemctl停掉之后程序很可能還留在那里容易造成僵尸附著。更可控的方式是使用bpf_link機(jī)制。bpf_link通過一個(gè)文件描述符管理程序生命周期fd關(guān)閉程序自動detach。在代碼里用libbpf的bpf_program__attach_xdp或者bpftool的bpftool prog attach這個(gè)本質(zhì)上也會創(chuàng)建link取決于你的bpftool版本來管理。舉個(gè)例子用C API來attachstruct bpf_program *prog; struct bpf_link *link; // 省略了bpf_object__open_file等前序步驟 link bpf_program__attach_xdp(prog, ifindex); if (libbpf_get_error(link)) { fprintf(stderr, Failed to attach XDP program\n); return -1; } // 程序退出或清理時(shí) bpf_link__destroy(link);這個(gè)習(xí)慣一旦養(yǎng)成能讓你避免很多線上“開了關(guān)不掉”的坑——我曾經(jīng)為了清理忘掉的XDP程序不得不重啟網(wǎng)卡結(jié)果業(yè)務(wù)中斷了一小會兒教訓(xùn)深刻。4. 常見問題與排查技巧實(shí)錄4.1 verifier提示invalid access to packet——越界訪問這是新手最常遇到的錯(cuò)誤。內(nèi)核verifier會詳細(xì)報(bào)告哪一行訪問越界。舉個(gè)例子invalid access to packet, off34 size2, R4(id0,off34,r0) R4 offset is outside of the packet這種錯(cuò)誤幾乎都是因?yàn)樵L問字段時(shí)沒有先確保data_end足夠大。解決方案是嚴(yán)格按照上面的范式先算出各個(gè)協(xié)議頭的結(jié)束位置做一次if比較再訪問。注意verifier認(rèn)為你只能在代碼的安全分支里訪問數(shù)據(jù)所以邊界檢查不能省略。還有一個(gè)小技巧如果程序的驗(yàn)證失敗可以用bpftool prog load ./xdp_filter.o /sys/fs/bpf/xdp_filter時(shí)有詳細(xì)的verifier log。如果日志不夠長可以用-v參數(shù)調(diào)節(jié)log level。bpftool prog load ./xdp_filter.o /sys/fs/bpf/xdp_filter verbose4.2 編譯成功但attach時(shí)報(bào)No such device或Operation not permitted這種情況多半是網(wǎng)卡驅(qū)動不支持native XDP或者你沒有CAP_NET_ADMIN權(quán)限。針對前者你可以查內(nèi)核對應(yīng)驅(qū)動的文檔也可以用下面的命令驗(yàn)證驅(qū)動是否支持native:ethtool -l eth0如果網(wǎng)卡不支持native你只能回退到generic模式。bpftool網(wǎng)卡attach默認(rèn)嘗試native不確定時(shí)可以先試generic掛載方式測試。generic模式加載時(shí)不要求驅(qū)動支持性能雖然差一些但至少能讓你確認(rèn)程序邏輯沒問題。運(yùn)行bpftool net attach xdp_generic pinned /sys/fs/bpf/xdp_filter dev eth04.3 XDP程序加載后所有ping都不通了這種情況幾乎總有固定原因——程序里遇到了你沒考慮到的包類型而且返回了XDP_DROP。比如你只想處理IPv4 TCP/UDP但I(xiàn)CMP包也命中了某個(gè)DROP分支。排查方法先把程序改成默認(rèn)XDP_PASS只DROP明確目標(biāo)流量。用bpftool map dump查看計(jì)數(shù)器的分布情況對比不同協(xié)議包數(shù)量。如果必須立即恢復(fù)網(wǎng)絡(luò)直接卸載XDP程序bpftool net detach xdp dev eth0另外有個(gè)細(xì)節(jié)XDP對loopback接口lo的支持很糟糕。不要試圖把XDP程序掛到lo上做測試你會看到各種奇怪的表現(xiàn)因?yàn)樗举|(zhì)上沒有驅(qū)動層可供原生XDP工作。想自測用veth對或者物理網(wǎng)卡加一臺對端機(jī)器。4.4 性能指標(biāo)達(dá)不到預(yù)期——看看是不是走了generic路徑很多人會發(fā)現(xiàn)我在虛擬機(jī)里跑XDP程序怎么比官方案例差那么多因?yàn)関irtio-net的XDP支持可能走的是generic路徑。同樣地云上的某些彈性網(wǎng)卡也未必支持native。你可以通過/proc/net/xdp或者bpftool net show查看程序掛載類型bpftool net show dev eth0 # 輸出里有xdp(generic)說明走的是generic # 輸出是xdp(native)說明走的是native # 輸出是xdp(offload)說明程序下發(fā)了硬件如果是generic性能自然不如預(yù)期。這時(shí)別糾結(jié)換驅(qū)動而是考慮優(yōu)化網(wǎng)卡隊(duì)列、使用RSS/flow director讓每個(gè)CPU處理屬于自己的隊(duì)列或者直接換用支持native的物理機(jī)和網(wǎng)卡。4.5 map操作失敗或權(quán)限不足map的創(chuàng)建和訪問受CAP_BPF或CAP_SYS_ADMIN某些老內(nèi)核限制。如果你在非root下運(yùn)行多半會失敗。建議用sudo如果程序要在容器里運(yùn)行需要賦予相應(yīng)的capability。順帶一提Linux內(nèi)核5.8之后統(tǒng)一稱為CAP_BPF容器配置時(shí)需要把cap_add: [BPF]加入白名單。4.6 我的避坑速查表常見問題原因快速解決verifier報(bào)invalid access越界訪問包數(shù)據(jù)按data_end邊界逐頭校驗(yàn)attach報(bào)Operation not permitted缺少CAP_NET_ADMIN用root/sudo或加capability性能只有幾百K PPSgeneric路徑或驅(qū)動不支持檢查bpftool顯示模式換native支持網(wǎng)卡加載后所有網(wǎng)絡(luò)不通誤DROP其他類型流量默認(rèn)XDP_PASS精確匹配DROP條件map更新時(shí)報(bào)Argument list too longkey/value大小與定義不符用bpftool map dump查看格式AF_XDP收不到包fill queue沒有及時(shí)填充增加循環(huán)填充邏輯保證umem有buffer5. 經(jīng)驗(yàn)總結(jié)與踩坑心得回頭看這段經(jīng)歷我覺得XDP最迷人的地方不是快而是它提供了一種極其干凈的思考方式你可以在數(shù)據(jù)進(jìn)入復(fù)雜系統(tǒng)之前用盡可能少的指令解決這個(gè)包值不值得留的問題。做DDoS防護(hù)時(shí)它可以把攻擊流量從入口處擋住業(yè)務(wù)后端感受到的壓力幾乎為零做流量分發(fā)時(shí)它可以替代一部分LVS的轉(zhuǎn)發(fā)邏輯把時(shí)延進(jìn)一步壓低做數(shù)據(jù)采集時(shí)它可以略過協(xié)議棧直接把報(bào)文送到用戶態(tài)分析器里。但也要潑點(diǎn)冷水XDP并不適合所有場景。如果你的流量本身不大傳統(tǒng)內(nèi)核路徑完全夠用加XDP反而增加復(fù)雜度如果你的邏輯極其復(fù)雜比如需要深度DPI、流量重組和大量狀態(tài)機(jī)XDP的512字節(jié)棧和受限指令集會讓你寫得很痛苦。我的建議是從最粗顆粒度的過濾和統(tǒng)計(jì)開始解決當(dāng)前最痛的那個(gè)性能瓶頸再逐步擴(kuò)展eBPF程序的功能。不要一上來就憋一個(gè)大而全的程序又難驗(yàn)證又難調(diào)優(yōu)。給準(zhǔn)備上手的人一個(gè)路線先做好環(huán)境編譯并加載最簡單的XDP_DROP程序用pktgen打滿網(wǎng)卡親眼看看單核能到多少PPS建立真實(shí)的性能感知。然后加上map做IP統(tǒng)計(jì)和IP封禁。等這些都會了再去碰XDP_TX和AF_XDP。按這個(gè)節(jié)奏你踩坑的次數(shù)會明顯變少收獲也會更扎實(shí)。最后分享一個(gè)小技巧調(diào)試XDP時(shí)把bpftool的json輸出和map dump結(jié)合起來用能更快定位問題。比如你懷疑某個(gè)IP被誤封直接dump block_ip_map里的內(nèi)容瞬間就能看出邏輯是否錯(cuò)誤。你不需要一把梭地重啟網(wǎng)卡只要改map里的key就行——這是XDP設(shè)計(jì)給我們留下的最友好的后門。