hi，大家好，歡迎來到極客重生的世界，今天給大家分享的是Linux 網絡新技術，當前正流行網絡技是什么？那就是eBPF和XDP技術，Cilium+eBPF超級火熱，Google GCP也剛剛全面轉過來。
新技術出現的歷史原因
廉頗老矣，尚能飯否
iptables/netfilter
iptables/netfilter 是上個時代Linux網絡提供的優秀的防火墻技術，擴展性強，能夠滿足當時大部分網絡應用需求，如果不知道iptables/netfilter是什么，請參考之前文章：一個奇葩的網絡問題，把技術磚家"搞蒙了" ，里面對iptables/netfilter技術有詳細介紹。
但該框架也存在很多明顯問題：
路徑太長
netfilter 框架在IP層，報文需要經過鏈路層，IP層才能被處理，如果是需要丟棄報文，會白白浪費很多CPU資源，影響整體性能；
O(N)匹配
如上圖所示，極端情況下，報文需要依次遍歷所有規則，才能匹配中，極大影響報文處理性能；
規則太多
netfilter 框架類似一套可以自由添加策略規則專家系統，并沒有對添加規則進行合并優化，這些都嚴重依賴操作人員技術水平，隨著規模的增大，規則數量n成指數級增長，而報文處理又是0（n）復雜度，最終性能會直線下降。
內核協議棧
隨著互聯網流量越來愈大, 網卡性能越來越強，Linux內核協議棧在10Mbps/100Mbps網卡的慢速時代是沒有任何問題的，那個時候應用程序大部分時間在等網卡送上來數據。
現在到了1000Mbps/10Gbps/40Gbps網卡的時代，數據被很快地收入，協議棧復雜處理邏輯，效率捉襟見肘，把大量報文堵在內核里。
各類鏈表在多CPU環境下的同步開銷。
不可睡眠的軟中斷路徑過長。
sk_buff的分配和釋放。
內存拷貝的開銷。
上下文切換造成的cache miss。
…
于是，內核協議棧各種優化措施應著需求而來：
網卡RSS，多隊列。
中斷線程化。
分割鎖粒度。
Busypoll。
…
但卻都是見招拆招，治標不治本。問題的根源不是這些機制需要優化，而是這些機制需要推倒重構。蒸汽機車剛出來的時候，馬車夫為了保持競爭優勢，不是去換一匹昂貴的快馬，而是賣掉馬去買一臺蒸汽機裝上。基本就是這個意思。
重構的思路很顯然有兩個：
upload方法：別讓應用程序等內核了，讓應用程序自己去網卡直接拉數據。
offload方法：別讓內核處理網絡邏輯了，讓網卡自己處理。
總之，繞過內核就對了，內核協議棧背負太多歷史包袱。
DPDK讓用戶態程序直接處理網絡流，bypass掉內核，使用獨立的CPU專門干這個事。
XDP讓灌入網卡的eBPF程序直接處理網絡流，bypass掉內核，使用網卡NPU專門干這個事。
如此一來，內核協議棧就不再參與數據平面的事了，留下來專門處理諸如路由協議，遠程登錄等控制平面和管理平面的數據流。
改善iptables/netfilter的規模瓶頸，提高Linux內核協議棧IO性能，內核需要提供新解決方案，那就是eBPF/XDP框架，讓我們來看一看，這套框架是如何解決問題的。
eBPF到底是什么?
eBPF的歷史
BPF 是 Linux 內核中高度靈活和高效的類似虛擬機的技術，允許以安全的方式在各個掛鉤點執行字節碼。它用于許多 Linux 內核子系統，最突出的是網絡、跟蹤和安全（例如沙箱）。
BPF架構
BPF 是一個通用目的 RISC 指令集，其最初的設計目標是：用 C 語言的一個子集編 寫程序，然后用一個編譯器后端（例如 LLVM）將其編譯成 BPF 指令，稍后內核再通 過一個位于內核中的（in-kernel）即時編譯器（JIT Compiler）將 BPF 指令映射成處理器的原生指令（opcode ），以取得在內核中的最佳執行性能。
BPF指令
盡管 BPF 自 1992 年就存在，擴展的 Berkeley Packet Filter (eBPF) 版本首次出現在 Kernel3.18中，如今被稱為“經典”BPF (cBPF) 的版本已過時。許多人都知道 cBPF是tcpdump使用的數據包過濾語言。現在Linux內核只運行 eBPF，并且加載的 cBPF 字節碼在程序執行之前被透明地轉換為內核中的eBPF表示。除非指出 eBPF 和 cBPF 之間的明確區別，一般現在說的BPF就是指eBPF。
eBPF總體設計
BPF 不僅通過提供其指令集來定義自己，而且還通過提供圍繞它的進一步基礎設施，例如充當高效鍵/值存儲的映射、與內核功能交互并利用內核功能的輔助函數、調用其他 BPF 程序的尾調用、安全加固原語、用于固定對象（地圖、程序）的偽文件系統，以及允許將 BPF 卸載到網卡的基礎設施。
LLVM 提供了一個 BPF后端，因此可以使用像 clang 這樣的工具將 C 編譯成 BPF 目標文件，然后可以將其加載到內核中。BPF與Linux 內核緊密相連，允許在不犧牲本機內核性能的情況下實現完全可編程。
eBPF總體設計包括以下幾個部分：
eBPF Runtime
安全保障 ： eBPF的verifier 將拒絕任何不安全的程序并提供沙箱運行環境
持續交付： 程序可以更新在不中斷工作負載的情況下
高性能：JIT編譯器可以保證運行性能
eBPF Hooks
內核函數 (kprobes)、用戶空間函數 (uprobes)、系統調用、fentry/fexit、跟蹤點、網絡設備 (tc/xdp)、網絡路由、TCP 擁塞算法、套接字（數據面）
eBPF Maps
Map 類型
- Hash tables, Arrays
- LRU (Least Recently Used)
- Ring Buffer
- Stack Trace
- LPM (Longest Prefix match)
作用
程序狀態
程序配置
程序間共享數據
和用戶空間共享狀態、指標和統計
eBPF Helpers
有哪些Helpers？
隨機數
獲取當前時間
map訪問
獲取進程/cgroup 上下文
處理網絡數據包和轉發
訪問套接字數據
執行尾調用
訪問進程棧
訪問系統調用參數
...
eBPF Tail and Function Calls
尾調用有什么用？
● 將程序鏈接在一起
● 將程序拆分為獨立的邏輯組件
● 使 BPF 程序可組合
函數調用有什么用？
● 重用內部的功能程序
● 減少程序大小（避免內聯）
eBPF JIT Compiler
確保本地執行性能而不需要了解CPU
將 BPF字節碼編譯到CPU架構特定指令集
eBPF可以做什么？
eBPF 開源 Projects
Cilium
Cilium 是開源軟件，用于Linux容器管理平臺（如 Docker 和 Kubernetes）部署的服務之間的透明通信和提供安全隔離保護。
Cilium基于微服務的應用，使用HTTP、gRPC、Kafka等輕量級協議API相互通信。
Cilium 的基于 eBPF 的新 Linux 內核技術，它能夠在 Linux 本身中動態插入強大的安全可見性和控制邏輯。由于 eBPF 在 Linux 內核中運行，因此可以在不更改應用程序代碼或容器配置的情況下應用和更新 Cilium 安全策略。
Cilium在它的 datapath 中重度使用了 BPF 技術
Cilium 是位于 Linux kernel 與容器編排系統的中間層。向上可以為容器配置網絡，向下可以向 Linux 內核生成 BPF 程序來控制容器的安全性和轉發行為。
利用 Linux BPF，Cilium 保留了透明地插入安全可視性 + 強制執行的能力，但這種方式基于服務 /pod/ 容器標識（與傳統系統中的 IP 地址識別相反），并且可以根據應用層進行過濾 （例如 HTTP）。因此，通過將安全性與尋址分離，Cilium 不僅可以在高度動態的環境中應用安全策略，而且除了提供傳統的第 3 層和第 4 層分割之外，還可以通過在 HTTP 層運行來提供更強的安全隔離。
BPF 的使用使得 Cilium 能夠以高度可擴展的方式實現以上功能，即使對于大規模環境也不例外。
對比傳統容器網絡（采用iptables/netfilter）：
eBPF主機路由允許繞過主機命名空間中所有的 iptables 和上層網絡棧，以及穿過Veth對時的一些上下文切換，以節省資源開銷。網絡數據包到達網絡接口設備時就被盡早捕獲，并直接傳送到Kubernetes Pod的網絡命名空間中。在流量出口側，數據包同樣穿過Veth對，被eBPF捕獲后，直接被傳送到外部網絡接口上。eBPF直接查詢路由表，因此這種優化完全透明。
基于eBPF中的kube-proxy網絡技術正在替換基于iptables的kube-proxy技術，與Kubernetes中的原始kube-proxy相比，eBPF中的kuber-proxy替代方案具有一系列重要優勢，例如更出色的性能、可靠性以及可調試性等等。
BCC(BPF Compiler Collection)
BCC 是一個框架，它使用戶能夠編寫嵌入其中的 eBPF 程序的 Python 程序。該框架主要針對涉及應用程序和系統分析/跟蹤的用例，其中 eBPF 程序用于收集統計信息或生成事件，用戶空間中的對應部分收集數據并以人類可讀的形式顯示。運行 python 程序將生成 eBPF 字節碼并將其加載到內核中。
bpftrace
bpftrace 是一種用于 Linux eBPF 的高級跟蹤語言，可在最近的 Linux 內核 (4.x) 中使用。bpftrace 使用 LLVM 作為后端將腳本編譯為 eBPF 字節碼，并利用 BCC 與 Linux eBPF 子系統以及現有的 Linux 跟蹤功能進行交互：內核動態跟蹤 (kprobes)、用戶級動態跟蹤 (uprobes) 和跟蹤點. bpftrace 語言的靈感來自 awk、C 和前身跟蹤器，例如 DTrace 和 SystemTap。
eBPF Go 庫
eBPF Go 庫提供了一個通用的 eBPF 庫，它將獲取 eBPF 字節碼的過程與 eBPF 程序的加載和管理解耦。eBPF 程序通常是通過編寫高級語言創建的，然后使用 clang/LLVM 編譯器編譯為 eBPF 字節碼。
libbpf C/C++ 庫
libbpf 庫是一個基于 C/C++ 的通用 eBPF 庫，它有助于解耦從 clang/LLVM 編譯器生成的 eBPF 目標文件加載到內核中，并通過提供易于使用的庫 API 來抽象與 BPF 系統調用的交互應用程序。
那XDP又是什么?
XDP的全稱是： eXpress Data Path
XDP 是Linux 內核中提供高性能、可編程的網絡數據包處理框架。
XDP整體框架
直接接管網卡的RX數據包（類似DPDK用戶態驅動）處理；
通過運行BPF指令快速處理報文；
和Linux協議棧無縫對接；
XDP總體設計
XDP總體設計包括以下幾個部分：
XDP驅動
網卡驅動中XDP程序的一個掛載點，每當網卡接收到一個數據包就會執行這個XDP程序；XDP程序可以對數據包進行逐層解析、按規則進行過濾，或者對數據包進行封裝或者解封裝，修改字段對數據包進行轉發等；
BPF虛擬機
并沒有在圖里畫出來，一個XDP程序首先是由用戶編寫用受限制的C語言編寫的，然后通過clang前端編譯生成BPF字節碼，字節碼加載到內核之后運行在eBPF虛擬機上，虛擬機通過即時編譯將XDP字節碼編譯成底層二進制指令；eBPF虛擬機支持XDP程序的動態加載和卸載；
BPF maps
存儲鍵值對，作為用戶態程序和內核態XDP程序、內核態XDP程序之間的通信媒介，類似于進程間通信的共享內存訪問；用戶態程序可以在BPF映射中預定義規則，XDP程序匹配映射中的規則對數據包進行過濾等；XDP程序將數據包統計信息存入BPF映射，用戶態程序可訪問BPF映射獲取數據包統計信息；
BPF程序校驗器
XDP程序肯定是我們自己編寫的，那么如何確保XDP程序加載到內核之后不會導致內核崩潰或者帶來其他的安全問題呢？程序校驗器就是在將XDP字節碼加載到內核之前對字節碼進行安全檢查，比如判斷是否有循環，程序長度是否超過限制，程序內存訪問是否越界，程序是否包含不可達的指令；
XDP Action
XDP用于報文的處理，支持如下action：
enum xdp_action {XDP_ABORTED = 0,XDP_DROP,XDP_PASS,XDP_TX,XDP_REDIRECT,};
XDP_DROP：在驅動層丟棄報文，通常用于實現DDos或防火墻
XDP_PASS：允許報文上送到內核網絡棧，同時處理該報文的CPU會分配并填充一個skb，將其傳遞到GRO引擎。之后的處理與沒有XDP程序的過程相同。
XDP_TX：從當前網卡發送出去。
XDP_REDIRECT：從其他網卡發送出去。
XDP_ABORTED：表示程序產生了異常，其行為和 XDP_DROP相同，但 XDP_ABORTED 會經過 trace_xdp_exception tracepoint，因此可以通過 tracing 工具來監控這種非正常行為。
AF_XDP
AF_XDP 是為高性能數據包處理而優化的地址族，AF_XDP 套接字使 XDP 程序可以將幀重定向到用戶空間應用程序中的內存緩沖區。
XDP設計原則
XDP 專為高性能而設計。它使用已知技術并應用選擇性約束來實現性能目標
XDP 還具有可編程性。無需修改內核即可即時實現新功能
XDP 不是內核旁路。它是內核協議棧的快速路徑
XDP 不替代TCP/IP 協議棧。與協議棧協同工作
XDP 不需要任何專門的硬件。它支持網絡硬件的少即是多原則
XDP技術優勢
及時處理
在網絡協議棧前處理，由于 XDP 位于整個 Linux 內核網絡軟件棧的底部，能夠非常早地識別并丟棄攻擊報文，具有很高的性能。可以改善 iptables 協議棧丟包的性能瓶頸
DDIO
Packeting steering
輪詢式
高性能優化
無鎖設計
批量I/O操作
不需要分配skbuff
支持網絡卸載
支持網卡RSS
指令虛擬機
規則優化，編譯成精簡指令，快速執行
支持熱更新，可以動態擴展內核功能
易編程-高級語言也可以間接在內核運行
安全可靠，BPF程序先校驗后執行，XDP程序沒有循環
可擴展模型
支持應用處理（如應用層協議GRO）
支持將BPF程序卸載到網卡
BPF程序可以移植到用戶空間或其他操作系統
可編程性
包檢測，BPF程序發現的動作
靈活（無循環）協議頭解析
可能由于流查找而有狀態
簡單的包字段重寫（encap/decap）
XDP 工作模式
XDP 有三種工作模式，默認是 native（原生）模式，當討論 XDP 時通常隱含的都是指這 種模式。
Native XDP
默認模式，在這種模式中，XDP BPF 程序直接運行在網絡驅動的早期接收路徑上（ early receive path）。
Offloaded XDP
在這種模式中，XDP BPF程序直接 offload 到網卡。
Generic XDP
對于還沒有實現 native 或 offloaded XDP 的驅動，內核提供了一個 generic XDP 選 項，這種設置主要面向的是用內核的 XDP API 來編寫和測試程序的開發者，對于在生產環境使用XDP，推薦要么選擇native要么選擇offloaded模式。
XDP vs DPDK
相對于DPDK，XDP：
優點
無需第三方代碼庫和許可
同時支持輪詢式和中斷式網絡
無需分配大頁
無需專用的CPU
無需定義新的安全網絡模型
缺點
注意XDP的性能提升是有代價的，它犧牲了通用型和公平性
XDP不提供緩存隊列（qdisc），TX設備太慢時直接丟包，因而不要在RX比TX快的設備上使用XDP
XDP程序是專用的，不具備網絡協議棧的通用性
如何選擇？
內核延伸項目，不想bypass內核的下一代高性能方案；
想直接重用內核代碼；
不支持DPDK程序環境；
XDP適合場景
DDoS防御
防火墻
基于XDP_TX的負載均衡
網絡統計
流量監控
棧前過濾/處理
...
XDP例子
下面是一個最小的完整 XDP 程序，實現丟棄包的功能（xdp-example.c）：
#include <linux/bpf.h>
#ifndef __section
# define __section(NAME) \
__attribute__((section(NAME), used))
#endif
__section("prog")
int xdp_drop(struct xdp_md *ctx)
{
return XDP_DROP;
}
char __license[] __section("license") = "GPL";
用下面的命令編譯并加載到內核：
$ clang -O2 -Wall -target bpf -c xdp-example.c -o xdp-example.o
$ ip link set dev em1 xdp obj xdp-example.o
以上命令將一個 XDP 程序 attach 到一個網絡設備，需要是 Linux 4.11 內核中支持 XDP 的設備，或者 4.12+ 版本的內核。
最后
eBPF/XDP 作為Linux網絡革新技術正在悄悄改變著Linux網絡發展模式。
eBPF正在將Linux內核轉變為微內核，越來越多的新內核功能采用eBPF實現，讓新增內核功能更加快捷高效。
總體而言，基于業界基準測試結果，eBPF 顯然是解決具有挑戰性的云原生需求的最佳技術。
參考&延伸閱讀
The eXpress Data Path:
Fast Programmable Packet Processing in the Operating System Kernel
https://docs.cilium.io/en/v1.6/bpf/
bpf-rethinkingthelinuxkernel-200303183208
https://ebpf.io/what-is-ebpf/
https://www.kernel.org/doc/html/latest/networking/af_xdp.html
https://cilium.io/blog/2021/05/11/cni-benchmark
https://blog.csdn.net/dog250/article/details/107243696
- END -
看完一鍵三連在看，轉發，點贊
是對文章最大的贊賞，極客重生感謝你
