如何進行eBPF應用分析

今天就跟大家聊聊有關如何進行eBPF應用分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

最近一直在學習eBPF以及當前的應用案例，搜索到這篇文章。這篇文章將目前市面上主流的應用場景描述的很清楚。但是傳播度不夠，關鍵詞的搜索中也不是第一個出現的。所以，我也是簡單的調整了下格式發出來。原文鏈接也找不到了，如果涉及到版權請聯系我。eBPF是當前的網絡開發領域中的熱點，netconf也有多篇相關的topic。后續我會把eBPF/XDP的源碼實現，應用場景，當前現狀也會陸續整理發出來。
 

引子

Linux內核社區最近發布了bpfilter，一個使用Linux BPF提供的高性能網絡過濾內核模塊，用來替代netfilter作為iptables的長期支持的內核底層的實現，實現Linux用戶的無痛向BPF過渡的換心手術。

BPF可能我們比較生疏，但是我說起tcpdump、Wireshark等流行的網絡抓包和分析工具你一定聽說并可能使用過，他們底層的包過濾實現就是用的BPF。所以他不是一個新的技術，也已經陪伴我們很久了。目前，BPF已經成長為一個高度靈活的和豐富功能的框架，它可以以不犧牲系統性能和安全性為前提下，大幅度擴展Linux的功能。BPF強大的靈活性、穩定性和豐富的功能，使得業界翹楚比如谷歌，facebook和Netflix等Linux內核前瞻性大企業用戶紛紛對其伸出橄欖枝，用BPF來實現網絡安全、負載均衡，還有性能監控、故障排查等大量的用途。 Netflix的Brendan Gregg首先稱其為Linux的BPF Superpowers。

下面將介紹這些大企業實踐中由于如何超負荷使用iptables內核子系統，從而導致的冗余、性能低下等問題，以及新內核如何利用新特性優雅地從底層解決這些問題。

在過去15年類，Linux內核社區構建了很多內核子系統，包括TPC/IP棧，iptables(netfiter)等等，在此過程中我們也看到了BPF一步步發展、成長、壯大。現在內核的新轉變讓我們意識到了BPF不僅僅是另一個功能，而是代表了一個根本的技術轉型，它將及時改變Linux從網絡到安全的各個方面。從iptables到bpfilter的轉變,只是BPF為振興Linux網絡棧領域,使其更現代化的重要一步。為了解釋為什么會有這激動人心的一步轉變，首先我們介紹下內核中iptables的歷史演變。

iptables及順序過濾的起源

多年來iptables一直是Linux上實現防火墻和網絡數據包過濾器的最主要的工具。從最初的ipchains，很多linux老司機最初可能都接觸ipchains，他是iptables前身，是在linux 內核 2.2.10引入。然后是在2001年linux內核版本2.4.0開始引入了iptables。從此，多少年一來，iptables一直給用戶帶來了便利和麻煩兩重天。一方面享受的靈活性和快速修復。另一方面，又為了在調試5000條沉沉的過濾規則而犯難，想為此罵娘。

當iptables在20年前取代其前身ipchains時，開始其生命周期時，防火墻功能的范圍還很簡單明確：

1. 保護本地應用程序免受不需要的網絡通信（INPUT鏈）

2. 保護本地應用程序發送不需要的網絡通信（OUTPUT鏈）

3. 過濾由Linux系統（FORWARD鏈）轉發/路由的網絡流量。

那時后網絡速度很慢，日子過的很慢。還記得用宿舍用Modem，201卡撥號情形么？那是iptables最初被設計和開發的時代。用iptables實現訪問控制列表（ACLs）的標準做法是使用連續的規則列表，即每個接收或發送的網絡數據包都要逐一與規則列表進行匹配，直到匹配或者全不匹配。然而，逐行的處理有明顯的缺陷：過濾數據包的成本，隨著添加的規則數量線性增加。

權衡處理：ipset

一段時間過去了，網絡速度開始提高了，iptables的設置規則，也從十幾條增加到數千條規則。從性能和延遲角度來看，遍歷順序的iptables列表已經變得不可忍受。

社區很快發現了瓶頸所在：長長的規則列表要么拒絕，要么允許單獨的IP地址和端口組合。為此引進了ipset對IP地址進行管理。 ipset允許將與IP地址和端口組合存儲到散列表中，在iptables只需引用ipset中的散列的鍵名就可以，極大的減少iptables規則的數量，而且ipset散列中的IP地址信息常駐內存，匹配非常快。但這也只是"頭疼醫頭，腳疼治腳"的治表不治本的暫時權衡之策。

更不幸的是，ipset還不能適用于所有情況。近些年，隨著容器技術的崛起，一個明顯的問題是kube-proxy，他是Kubernetes的一個組件，容器要使用iptables和-j DNAT規則為服務提供負載均衡。它要為為每個后端服務要添加多條iptables規則。對于添加到Kubernetes的每個服務，要遍歷的iptables規則列表呈指數增長。最近的KubeCon議題中詳細研究kube-proxy的性能表現細節。研究結果顯示，隨著服務數量的增長，網絡延遲和性能下降無法估量。還披露了iptables的另一個主要缺點，無法實現增量更新。每次添加新規則時，必須更新整個規則列表。結果是對2萬個Kubernetes服務16萬條的iptables規則，裝配這些規則需要耗時5個小時。

使用基于IP/端口的機制一般還有許多其他明顯的缺點，特別是在容器應用環境下。容器需要經常部署和刪除。這可能導致個別IP地址的使用快速變化。一個IP地址可能被一個容器使用幾秒鐘，然后在幾秒鐘之后會換到一個容器使用。這使得依靠使用IP地址進行安全過濾的系統受到壓力，因為集群中的所有節點都必須始終知道最新的IP到容器的映射。雖然在一個集群內部這幾乎沒有什么難度，但它在如果在分布式的跨集群應用中就會很有挑戰性。關于這些這兒不在贅述，可以參考docker，k8s等相關的官方文檔。

用BPF統一一切

BPF革命性開發的新進展更令人興奮，即通過用戶完全透明的方式用BPF完全替換iptables的內核部分（netfiter），即現有iptables客戶端和庫無需任何改動。

感興趣的同學可以去linux 內核郵件列表中找到相關的討論。該提案由Daniel Borkmann（Covalent），網絡維護部分由David Miller（Red Hat）和Alexei Starovoitov（Facebook）撰寫。

Quentin Monnet在FRnOG 30上提供的以下圖表顯示了與iptables和nftables相比較bpfilter的一些早期測試結果。

這些早期的測試數據展示了令人乍舌的性能優勢，也是BPF強大的一個實例。我們唯一要注意的是bpfilter和BPF本身并不能解決由iptables使用順序過濾引起的性能問題，要徹底解決這個問題必須使用BPF底層內核及原生的BPF應用。

看完上述內容，你們對如何進行eBPF應用分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。