今天就跟大家聊聊有關(guān)如何進(jìn)行eBPF應(yīng)用分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比河南網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式河南網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋河南地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

最近一直在學(xué)習(xí)eBPF以及當(dāng)前的應(yīng)用案例，搜索到這篇文章。這篇文章將目前市面上主流的應(yīng)用場景描述的很清楚。但是傳播度不夠，關(guān)鍵詞的搜索中也不是第一個(gè)出現(xiàn)的。所以，我也是簡單的調(diào)整了下格式發(fā)出來。原文鏈接也找不到了，如果涉及到版權(quán)請(qǐng)聯(lián)系我。eBPF是當(dāng)前的網(wǎng)絡(luò)開發(fā)領(lǐng)域中的熱點(diǎn)，netconf也有多篇相關(guān)的topic。后續(xù)我會(huì)把eBPF/XDP的源碼實(shí)現(xiàn)，應(yīng)用場景，當(dāng)前現(xiàn)狀也會(huì)陸續(xù)整理發(fā)出來。
 

引子

Linux內(nèi)核社區(qū)最近發(fā)布了bpfilter，一個(gè)使用Linux BPF提供的高性能網(wǎng)絡(luò)過濾內(nèi)核模塊，用來替代netfilter作為iptables的長期支持的內(nèi)核底層的實(shí)現(xiàn)，實(shí)現(xiàn)Linux用戶的無痛向BPF過渡的換心手術(shù)。

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

下面將介紹這些大企業(yè)實(shí)踐中由于如何超負(fù)荷使用iptables內(nèi)核子系統(tǒng)，從而導(dǎo)致的冗余、性能低下等問題，以及新內(nèi)核如何利用新特性優(yōu)雅地從底層解決這些問題。

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

iptables及順序過濾的起源

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

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

1. 保護(hù)本地應(yīng)用程序免受不需要的網(wǎng)絡(luò)通信（INPUT鏈）

2. 保護(hù)本地應(yīng)用程序發(fā)送不需要的網(wǎng)絡(luò)通信（OUTPUT鏈）

3. 過濾由Linux系統(tǒng)（FORWARD鏈）轉(zhuǎn)發(fā)/路由的網(wǎng)絡(luò)流量。

那時(shí)后網(wǎng)絡(luò)速度很慢，日子過的很慢。還記得用宿舍用Modem，201卡撥號(hào)情形么？那是iptables最初被設(shè)計(jì)和開發(fā)的時(shí)代。用iptables實(shí)現(xiàn)訪問控制列表（ACLs）的標(biāo)準(zhǔn)做法是使用連續(xù)的規(guī)則列表，即每個(gè)接收或發(fā)送的網(wǎng)絡(luò)數(shù)據(jù)包都要逐一與規(guī)則列表進(jìn)行匹配，直到匹配或者全不匹配。然而，逐行的處理有明顯的缺陷：過濾數(shù)據(jù)包的成本，隨著添加的規(guī)則數(shù)量線性增加。

權(quán)衡處理：ipset

一段時(shí)間過去了，網(wǎng)絡(luò)速度開始提高了，iptables的設(shè)置規(guī)則，也從十幾條增加到數(shù)千條規(guī)則。從性能和延遲角度來看，遍歷順序的iptables列表已經(jīng)變得不可忍受。

社區(qū)很快發(fā)現(xiàn)了瓶頸所在：長長的規(guī)則列表要么拒絕，要么允許單獨(dú)的IP地址和端口組合。為此引進(jìn)了ipset對(duì)IP地址進(jìn)行管理。 ipset允許將與IP地址和端口組合存儲(chǔ)到散列表中，在iptables只需引用ipset中的散列的鍵名就可以，極大的減少iptables規(guī)則的數(shù)量，而且ipset散列中的IP地址信息常駐內(nèi)存，匹配非?？?。但這也只是"頭疼醫(yī)頭，腳疼治腳"的治表不治本的暫時(shí)權(quán)衡之策。

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

使用基于IP/端口的機(jī)制一般還有許多其他明顯的缺點(diǎn)，特別是在容器應(yīng)用環(huán)境下。容器需要經(jīng)常部署和刪除。這可能導(dǎo)致個(gè)別IP地址的使用快速變化。一個(gè)IP地址可能被一個(gè)容器使用幾秒鐘，然后在幾秒鐘之后會(huì)換到一個(gè)容器使用。這使得依靠使用IP地址進(jìn)行安全過濾的系統(tǒng)受到壓力，因?yàn)榧褐械乃泄?jié)點(diǎn)都必須始終知道最新的IP到容器的映射。雖然在一個(gè)集群內(nèi)部這幾乎沒有什么難度，但它在如果在分布式的跨集群應(yīng)用中就會(huì)很有挑戰(zhàn)性。關(guān)于這些這兒不在贅述，可以參考docker，k8s等相關(guān)的官方文檔。

用BPF統(tǒng)一一切

BPF革命性開發(fā)的新進(jìn)展更令人興奮，即通過用戶完全透明的方式用BPF完全替換iptables的內(nèi)核部分（netfiter），即現(xiàn)有iptables客戶端和庫無需任何改動(dòng)。

感興趣的同學(xué)可以去linux 內(nèi)核郵件列表中找到相關(guān)的討論。該提案由Daniel Borkmann（Covalent），網(wǎng)絡(luò)維護(hù)部分由David Miller（Red Hat）和Alexei Starovoitov（Facebook）撰寫。

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

這些早期的測試數(shù)據(jù)展示了令人乍舌的性能優(yōu)勢(shì)，也是BPF強(qiáng)大的一個(gè)實(shí)例。我們唯一要注意的是bpfilter和BPF本身并不能解決由iptables使用順序過濾引起的性能問題，要徹底解決這個(gè)問題必須使用BPF底層內(nèi)核及原生的BPF應(yīng)用。

看完上述內(nèi)容，你們對(duì)如何進(jìn)行eBPF應(yīng)用分析有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。