前言
在網(wǎng)絡(luò)安全領(lǐng)域中數(shù)據(jù)包捕獲技術(shù)的應(yīng)用十分廣 泛，在當(dāng)前高速網(wǎng)絡(luò)環(huán)境中，如何實(shí)時(shí)、高效、完整、快速捕獲數(shù)據(jù)包是能否準(zhǔn)確分析網(wǎng)絡(luò)數(shù)據(jù)的基礎(chǔ)和網(wǎng)絡(luò)安全防護(hù)系統(tǒng)的關(guān)鍵技術(shù)。目前已經(jīng)有從硬件/軟件/軟硬結(jié)合多種解決方案被不斷的提出，用于提升數(shù)據(jù)包轉(zhuǎn)發(fā)與捕獲的性能。
本文主要目的從原理上分析比較目前主流的數(shù)據(jù)包捕獲技術(shù)。寫作思路：
- 介紹傳統(tǒng)數(shù)據(jù)包捕獲技術(shù)-->分析其原理-->指出其存在的問題
- 針對(duì)傳統(tǒng)數(shù)據(jù)包捕獲技術(shù)存在的問題給出解決方法-->介紹幾種改善的數(shù)據(jù)包捕獲技術(shù)
傳統(tǒng)Linux數(shù)據(jù)包捕獲技術(shù)流程和性能分析
傳統(tǒng)Linux數(shù)據(jù)包捕獲技術(shù)流程
傳統(tǒng)的數(shù)據(jù)包捕獲技術(shù)（典型的libpcap）是利用linux協(xié)議棧在數(shù)據(jù)鏈路層增加一個(gè)旁路處理，不干擾系統(tǒng)自身的網(wǎng)路協(xié)議棧的處理，對(duì)發(fā)送和接收的數(shù)據(jù)包通過Linux內(nèi)核做過濾和緩沖處理，最后直接傳遞給上層應(yīng)用程序。
流程：
數(shù)據(jù)包到達(dá)網(wǎng)卡設(shè)備。網(wǎng)卡設(shè)備（NIC）依據(jù)配置進(jìn)行DMA操作。（ 「第1次拷貝」 ：網(wǎng)卡寄存器->內(nèi)核為網(wǎng)卡分配的緩沖區(qū)ring buffer）
第一次cpy完成后，網(wǎng)卡發(fā)送中斷，喚醒處理器。網(wǎng)卡驅(qū)動(dòng)程序通過 NAPI機(jī)制 從ring buffer中讀取，填充內(nèi)核skbuff結(jié)構(gòu)（ 「第2次拷貝」 ：內(nèi)核網(wǎng)卡緩沖區(qū)ring buffer->內(nèi)核專用數(shù)據(jù)結(jié)構(gòu)skbuff）
網(wǎng)卡驅(qū)動(dòng)觸發(fā)軟中斷調(diào)用netif_receive_skb來處理數(shù)據(jù)包：
3.1 遍歷嗅探器ptype_all，如果有注冊(cè)抓包程序，由網(wǎng)絡(luò)分接口進(jìn)入BPF過濾器，將規(guī)則匹配的報(bào)文拷貝到系統(tǒng)內(nèi)核緩存 （ 「第3次拷貝」 ）。BPF為每一個(gè)要求服務(wù)的抓包程序關(guān)聯(lián)一個(gè)filter和兩個(gè)buffer。BPF分配buffer 且通常情況下它的額度是4KB the store buffer 被使用來接收來自適配器的數(shù)據(jù)；the hold buffer被使用來拷貝包到應(yīng)用程序。
3.2 調(diào)用handle_bridge處理網(wǎng)橋。
3.3 調(diào)用handle_macvlan處理vlan。
3.4 根據(jù)skb->protocol字段確定上層協(xié)議并提交給網(wǎng)絡(luò)層處理，進(jìn)入網(wǎng)絡(luò)協(xié)議棧，進(jìn)行高層處理。libpcap繞過了Linux內(nèi)核收包流程中協(xié)議棧部分的處理，使得用戶空間API可以直接調(diào)用套接字PF_PACKET從鏈路層驅(qū)動(dòng)程序中獲得數(shù)據(jù)報(bào)文的拷貝，將其從內(nèi)核緩沖區(qū)拷貝至用戶空間緩沖區(qū)（ 「第4次拷貝」 ）
傳統(tǒng)Linux數(shù)據(jù)包捕獲技術(shù)性能分析
研究者們發(fā)現(xiàn)，Linux內(nèi)核協(xié)議棧在數(shù)據(jù)包的收發(fā)過程中，內(nèi)存拷貝操作的時(shí)間開銷占了整個(gè)處理過程時(shí)間開銷的65%，此外層間傳遞的系統(tǒng)調(diào)用時(shí)間也占據(jù)了8%～10%。
協(xié)議棧的主要問題:
針對(duì)單個(gè)數(shù)據(jù)包級(jí)別的頻繁的資源分配和釋放。
每當(dāng)一個(gè)數(shù)據(jù)包到達(dá)網(wǎng)卡，系統(tǒng)就會(huì)分配一個(gè)分組描述符用于存儲(chǔ)數(shù)據(jù)包的信息和頭部，直到分組傳送到用戶態(tài)空間，其描述符才被釋放。此外，sk_buff龐大的數(shù)據(jù)結(jié)構(gòu)中的大部分信息對(duì)于大多數(shù)網(wǎng)絡(luò)任務(wù)而言都是無用的。分配和釋放描述符的過程在高達(dá) 14.88Mpps 環(huán)境下是一個(gè)顯著的時(shí)間上的開銷。此外，ｓｋ＿ｂｕｆｆ龐大的數(shù)據(jù)結(jié)構(gòu)中的大部分信息對(duì)于大多數(shù)網(wǎng)絡(luò) 任務(wù)而言都 是無用的。每個(gè)分組的ｓｋ＿ｂｕｆｆ的分配消耗近1200個(gè)ＣＰＵ 周期，而釋放需要1100個(gè)周期。事實(shí)上，對(duì)于一個(gè)大小為６４Ｂ的分組，ｓｋ＿ｂｕｆｆ相關(guān)操作消耗了整個(gè)接收處理的 ＣＰＵ 利用率的６３％。-
流量的串行訪問。
現(xiàn)代網(wǎng)卡包括多個(gè)硬件的接收端擴(kuò)展(receiver-side scaling, RSS)隊(duì)列可以將分組按照五元組散列函數(shù)分配到不同的接收隊(duì)列。使用這種技術(shù)，分組的捕獲過程可以被并行化，因?yàn)槊總€(gè)RSS隊(duì)列可以映射到一個(gè)特定的CPU核，并且可以對(duì)應(yīng)相應(yīng)的NAPI線程。這樣整個(gè)捕獲過程就可以做到并行化。
但是問題出現(xiàn)在之上的層次，Linux中的協(xié)議棧在網(wǎng)絡(luò)層和傳輸層需要分析合并的所有數(shù)據(jù)包：
①所有流量在一個(gè)單一模塊中被處理，產(chǎn)生性能瓶頸；
②用戶進(jìn)程不能夠從一個(gè)單一的RSS隊(duì)列接收消息。
這就造成了上層應(yīng)用無法利用現(xiàn)代硬件的并行化處理能力，這種在用戶態(tài)分配流量先后序列的過程降低了系統(tǒng)的性能，丟失了驅(qū)動(dòng)層面所獲得的加速。此外，從不同隊(duì)列合并的流量可能會(huì)產(chǎn)生額外的亂序分組。
瓶頸在Linux上層協(xié)議棧 從驅(qū)動(dòng)到用戶態(tài)的數(shù)據(jù)拷貝。
從網(wǎng)卡收到數(shù)據(jù)包到應(yīng)用取走數(shù)據(jù)的一次 ＤＭＡ 過程中，存在至少２次數(shù)據(jù)包的復(fù)制：從驅(qū)動(dòng)中 ＤＭＡ 的訪問內(nèi)存到內(nèi)核的數(shù)據(jù)包緩存，以及從內(nèi)核數(shù)據(jù)包緩存到應(yīng)用程序。一次復(fù)制操作的消耗取決于數(shù)據(jù)包長(zhǎng)度，一般為５００～２?。埃埃皞€(gè) ＣＰＵ 周期之間。上述過程中更糟糕的是，當(dāng)數(shù)據(jù)包很小時(shí)，逐包復(fù)制的效率更加低下，這是由于每個(gè)操作恒定的開銷引起的。內(nèi)核到用戶空間的上下文切換。
從應(yīng)用程序的視角來看，它需要執(zhí)行系統(tǒng)調(diào)用來接收每個(gè)分組.每個(gè)系統(tǒng)調(diào)用包含一次從用戶態(tài)到內(nèi)核態(tài)的上下文切換，隨之而來的是大量的CPU時(shí)間消耗。在每個(gè)數(shù)據(jù)包上執(zhí)行系統(tǒng)調(diào)用時(shí)產(chǎn)生的上下文切換可能消耗近1 000個(gè)CPU周期。跨內(nèi)存訪問。
例如，當(dāng)接收一個(gè)64 B分組時(shí)，cache未命中造成了額外13.8%的CPU周期的消耗。另外，在一個(gè)基于NUMA的系統(tǒng)中，內(nèi)存訪問的時(shí)間取決于訪問的存儲(chǔ)節(jié)點(diǎn)。因此，cache未命中在跨內(nèi)存塊訪問環(huán)境下會(huì)產(chǎn)生更大的內(nèi)存訪問延遲，從而導(dǎo)致性能下降。
提高捕獲效率的技術(shù)
目前高性能報(bào)文捕獲引擎中常用的提高捕獲效率的技術(shù)
- 預(yù)分配和重用內(nèi)存資源。
開始分組接收之前，預(yù)先分配好將要到達(dá)的數(shù)據(jù)包所需的內(nèi)存空間用來存儲(chǔ)數(shù)據(jù)和元數(shù)據(jù)(分組描述符)。尤其在加載網(wǎng)卡驅(qū)動(dòng)程序時(shí)就分配好 N 個(gè)描述符隊(duì)列(每個(gè)硬件隊(duì)列和設(shè)備一個(gè))。
同樣，當(dāng)一個(gè)數(shù)據(jù)包被傳送到用戶空間，其對(duì)應(yīng)的描述符也不會(huì)被釋放，而是重新用于存儲(chǔ)新到達(dá)的分組.得益于這一策略，在每個(gè)數(shù)據(jù)包分配/釋放所產(chǎn)生的性能瓶頸得到了消除.此外，也可以通過簡(jiǎn)化sk_buff的數(shù)據(jù)結(jié)構(gòu)來減少內(nèi)存開銷。 - 數(shù)據(jù)包采用并行直接通道傳遞。
為了解決序列化的訪問流量，需要建立從RSS隊(duì)列到應(yīng)用之間的直接并行數(shù)據(jù)通道。這種技術(shù)通過特定的RSS隊(duì)列、特定的CPU核和應(yīng)用三者的綁定來實(shí)現(xiàn)性能的提升。Intel XL710 NIC 可以選用對(duì)稱哈希，保證同一條流的往返數(shù)據(jù)包被分配到相同的CPU核上時(shí)，避免造成低效的跨核訪問。 - 內(nèi)存映射。
使用這種方法，應(yīng)用程序的內(nèi)存區(qū)域可以映射到內(nèi)核態(tài)的內(nèi)存區(qū)域，應(yīng)用能夠在沒有中間副本的情況下讀寫這片內(nèi)存區(qū)域。用這種方式我們可以使應(yīng)用直接訪問網(wǎng)卡的DMA內(nèi)存區(qū)域，這種技術(shù)被稱為零拷貝.但零拷貝也存在潛在的安全問題，向應(yīng)用暴露出網(wǎng)卡環(huán)形隊(duì)列和寄存器會(huì)影響系統(tǒng)的安全性和穩(wěn)定性 。 - 數(shù)據(jù)包的批處理。
為了避免對(duì)每個(gè)數(shù)據(jù)包的重復(fù)操作的開銷，可以使用對(duì)數(shù)據(jù)包的批量處理。這個(gè)策略將數(shù)據(jù)包劃分為組，按組分配緩沖區(qū)，將它們一起復(fù)制到內(nèi)核/用戶內(nèi)存.運(yùn)用這種技術(shù)減少了系統(tǒng)調(diào)用以及隨之而來的上下文切換的次數(shù);同時(shí)也減少了拷貝的次數(shù)，從而減少了平攤到處理和復(fù)制每個(gè)數(shù)據(jù)包的開銷。但由于分組必須等到一個(gè)批次已滿或定時(shí)器期滿才會(huì)遞交給上層，批處理技術(shù)的主要問題是延遲抖動(dòng)以及接收?qǐng)?bào)文時(shí)間戳誤差的增加。 - 親和性與預(yù)取。
由于程序運(yùn)行的局部性原理，為進(jìn)程分配的內(nèi)存必須與正在執(zhí)行它的處理器操作的內(nèi)存塊一致，這種技術(shù)被稱為內(nèi)存的親和性。CPU親和性是一種技術(shù)，它允許進(jìn)程或線程在指定的處理器核心上運(yùn)行。在內(nèi)核與驅(qū)動(dòng)層面，軟件和硬件中斷可以用同樣的方法指定具體的CPU核或處理器來處理，稱為中斷親和力。每當(dāng)一個(gè)線程希望訪問所接收的數(shù)據(jù)，如果先前這些數(shù)據(jù)已被分配到相同CPU核的中斷處理程序接收，則它們?cè)诒镜豤ache能夠更容易被訪問到。
目前幾種高性能報(bào)文捕獲引擎
- libpcap-mmap
libpcap-mmap是對(duì)舊的libpcap實(shí)現(xiàn)的改進(jìn)，新版本的libpcap基本都采用packet_mmap機(jī)制。PACKET_MMAP通過mmap，減少一次內(nèi)存拷貝（ 「第4次拷貝沒有了」 ），減少了頻繁的系統(tǒng)調(diào)用，大大提高了報(bào)文捕獲的效率。 - PF_RING
我們看到之前l(fā)ibpcap有4次內(nèi)存拷貝。libpcap_mmap有3次內(nèi)存拷貝。PF_RING提出的核心解決方案便是減少報(bào)文在傳輸過程中的拷貝次數(shù)。我們可以看到，相對(duì)與libpcap_mmap來說，pfring允許用戶空間內(nèi)存直接和rx_buffer做mmap。這又減少了一次拷貝 （ 「libpcap_mmap的第2次拷貝」 ：rx_buffer->skb）。
PF-RING ZC實(shí)現(xiàn)了DNA（Direct NIC Access 直接網(wǎng)卡訪問）技術(shù)，將用戶內(nèi)存空間映射到驅(qū)動(dòng)的內(nèi)存空間，使用戶的應(yīng)用可以直接訪問網(wǎng)卡的寄存器和數(shù)據(jù)。通過這樣的方式，避免了在內(nèi)核對(duì)數(shù)據(jù)包緩存，減少了一次拷貝（ 「libpcap的第1次拷貝」 ，DMA到內(nèi)核緩沖區(qū)的拷貝）。這就是完全的零拷貝。其缺點(diǎn)是，只有一個(gè) 應(yīng)用可以在某個(gè)時(shí)間打開DMA ring（請(qǐng)注意，現(xiàn)在的網(wǎng)卡可以具有多個(gè)RX / TX隊(duì)列，從而就可以在每個(gè)隊(duì)列上同時(shí)一個(gè)應(yīng)用程序），換而言之，用戶態(tài)的多個(gè)應(yīng)用需要彼此溝通才能分發(fā)數(shù)據(jù)包。 - DPDK
pf-ring zc和dpdk均可以實(shí)現(xiàn)數(shù)據(jù)包的零拷貝，兩者均旁路了內(nèi)核，但是實(shí)現(xiàn)原理略有不同。pf-ring zc通過zc驅(qū)動(dòng)（也在應(yīng)用層）接管數(shù)據(jù)包，dpdk基于UIO實(shí)現(xiàn)。
3.1 UIO+mmap 實(shí)現(xiàn)零拷貝（zero copy）
UIO（Userspace I/O）是運(yùn)行在用戶空間的I/O技術(shù)。Linux系統(tǒng)中一般的驅(qū)動(dòng)設(shè)備都是運(yùn)行在內(nèi)核空間，而在用戶空間用應(yīng)用程序調(diào)用即可，而UIO則是將驅(qū)動(dòng)的很少一部分運(yùn)行在內(nèi)核空間，而在用戶空間實(shí)現(xiàn)驅(qū)動(dòng)的絕大多數(shù)功能。采用Linux提供UIO機(jī)制，可以旁路Kernel，將所有報(bào)文處理的工作在用戶空間完成。
3.2 UIO+PMD 減少中斷和CPU上下文切換
DPDK的UIO驅(qū)動(dòng)屏蔽了硬件發(fā)出中斷，然后在用戶態(tài)采用主動(dòng)輪詢的方式，這種模式被稱為PMD（Poll Mode Driver）。
與DPDK相比，pf-ring（no zc）使用的是NAPI polling和應(yīng)用層polling，而pf-ring zc與DPDK類似，僅使用應(yīng)用層polling。
3.3 HugePages 減少TLB miss
在操作系統(tǒng)引入MMU（Memory Management Unit）后，CPU讀取內(nèi)存的數(shù)據(jù)需要兩次訪問內(nèi)存。第一次要查詢頁(yè)表將邏輯地址轉(zhuǎn)換為物理地址，然后訪問該物理地址讀取數(shù)據(jù)或指令。
為了減少頁(yè)數(shù)過多，頁(yè)表過大而導(dǎo)致的查詢時(shí)間過長(zhǎng)的問題，便引入了TLB(Translation Lookaside Buffer)，可翻譯為地址轉(zhuǎn)換緩沖器。TLB是一個(gè)內(nèi)存管理單元，一般存儲(chǔ)在寄存器中，里面存儲(chǔ)了當(dāng)前最可能被訪問到的一小部分頁(yè)表項(xiàng)。
引入TLB后，CPU會(huì)首先去TLB中尋址，由于TLB存放在寄存器中，且其只包含一小部分頁(yè)表項(xiàng)，因此查詢速度非?？臁Ｈ鬞LB中尋址成功（TLB hit），則無需再去RAM中查詢頁(yè)表；若TLB中尋址失敗（TLB miss），則需要去RAM中查詢頁(yè)表，查詢到后，會(huì)將該頁(yè)更新至TLB中。
而DPDK采用HugePages ，在x86-64下支持2MB、1GB的頁(yè)大小，大大降低了總頁(yè)個(gè)數(shù)和頁(yè)表的大小，從而大大降低TLB miss的幾率，提升CPU尋址性能。
3.4 其它優(yōu)化
SNA（Shared-nothing Architecture），軟件架構(gòu)去中心化，盡量避免全局共享，帶來全局競(jìng)爭(zhēng)，失去橫向擴(kuò)展的能力。NUMA體系下不跨Node遠(yuǎn)程使用內(nèi)存。
SIMD（Single Instruction Multiple Data），從最早的mmx/sse到最新的avx2，SIMD的能力一直在增強(qiáng)。DPDK采用批量同時(shí)處理多個(gè)包，再用向量編程，一個(gè)周期內(nèi)對(duì)所有包進(jìn)行處理。比如，memcpy就使用SIMD來提高速度。
cpu affinity：即 CPU 親和性。
3.5 DPDK VS PF-RING
ＰＦ-ＲＩＮＧ的ＤＮＡ工作方式下，網(wǎng)卡驅(qū)動(dòng)ＮＡＰＩ的整體流程基本沒變，依舊是由報(bào)文觸發(fā)硬中斷，軟中斷進(jìn)行輪詢收包，但ＤＮＡ工作方式下，網(wǎng)卡的ＤＭＡ緩沖被映射到了內(nèi)核中ＰＦ-ＲＩＮＧ的環(huán)形緩沖上，而改環(huán)形緩沖又被映射到了用戶態(tài)，故用戶態(tài)應(yīng)用程序可直接讀取到網(wǎng)卡的報(bào)文。在本工作方式下，直接避免了報(bào)文的拷貝。在中斷方面，ＰＦ-ＲＩＮＧ整體收包的流程依然采取報(bào)文觸發(fā)硬中斷，隨后軟中斷進(jìn)行輪詢收包的方式。在始終維持大量報(bào)文到來的高速網(wǎng)絡(luò)環(huán)境中，這種基于ＮＡＰＩ的異步中斷式收包
仍然會(huì)帶來中斷活鎖以及較高的中斷上下文切換開銷。在系統(tǒng)調(diào)用方面，ＰＦ-ＲＩＮＧ的環(huán)形緩沖存在于內(nèi)核態(tài)，當(dāng)應(yīng)用程序讀取報(bào)文時(shí)需依賴系統(tǒng)調(diào)用從用戶態(tài)讀取內(nèi)核態(tài)中的數(shù)據(jù)，故ＰＦ-ＲＩＮＧ存在系統(tǒng)調(diào)用的開銷。ＤＰＤＫ開源時(shí)間較短，但是目前當(dāng)下最熱的數(shù)據(jù)轉(zhuǎn)發(fā)技術(shù)，商用案例多且得到主流設(shè)備廠家的應(yīng)用，有良好的產(chǎn)業(yè)生態(tài)鏈。ＤＰＤＫ借助于用戶態(tài)I０，使輪詢模式的網(wǎng)卡驅(qū)動(dòng)運(yùn)行在用戶態(tài)接收?qǐng)?bào)文，一切數(shù)據(jù)操作都發(fā)生在用戶態(tài)，故與其他兩種技術(shù)相比，基本避免了系統(tǒng)調(diào)用的使用以及用戶態(tài)內(nèi)核態(tài)上下文切換的開銷。與ＮＡＰＩ即異步中斷模式相比，在本驅(qū)動(dòng)模式下，網(wǎng)卡的一切中斷被關(guān)閉，由此消除了中斷上下文的切換。每當(dāng)網(wǎng)卡接收隊(duì)列填滿報(bào)文之后填寫接收描述符，ＣＰＵ只需輪詢?cè)撁枋龇纯筛兄欠襁M(jìn)行報(bào)文處理，該機(jī)制保證ＣＰＵ只專注于對(duì)報(bào)文的輪詢Ｉ／Ｏ與處理，提高了報(bào)文的接收與處理效率。在報(bào)文拷貝與存儲(chǔ)方面，ＤＰＤＫ通過用戶態(tài)核心庫(kù)的緩沖區(qū)管理功能在用戶態(tài)為報(bào)文存儲(chǔ)提供了預(yù)分配內(nèi)存緩沖區(qū)，再者通過環(huán)境抽象層ＥＡＬ直接與硬件資源交互，將預(yù)分配內(nèi)存緩沖區(qū)的地址直接寫入到網(wǎng)卡寄存器中。由此，網(wǎng)卡將接收到的報(bào)文直接存儲(chǔ)到了用戶態(tài)的內(nèi)存緩沖區(qū)中，實(shí)現(xiàn)了報(bào)文的零拷貝。ＰＦ-ＲＩＮＧＤＮＡ與ＤＰＤＫ都實(shí)現(xiàn)了真正的零拷貝，單純就拷貝這一行為來說，二者的優(yōu)化達(dá)到了同一程度。但是值得注意的是，由于捕獲的報(bào)文進(jìn)行入侵檢測(cè)分析，故在后期會(huì)對(duì)存儲(chǔ)報(bào)文內(nèi)存進(jìn)行頻繁的讀取，相比于ＰＦ-ＲＴＮＧ使用常規(guī)內(nèi)存分頁(yè)技術(shù)，ＤＰＤＫ在預(yù)分配內(nèi)存時(shí)使用的Ｈｕｇｅｐａｇｅ技術(shù)，在后期數(shù)據(jù)處理階段中，可顯著提高內(nèi)存的訪問效率。 - Netmap
4.1 Netmap是一個(gè)高性能收發(fā)原始數(shù)據(jù)包的框架，由Luigi Rizzo等人開發(fā)完成，其包含了內(nèi)核模塊以及用戶態(tài)庫(kù)函數(shù)。其目標(biāo)是，不修改現(xiàn)有操作系統(tǒng)軟件以及不需要特殊硬件支持，實(shí)現(xiàn)用戶態(tài)和網(wǎng)卡之間數(shù)據(jù)包的高性能傳遞。數(shù)據(jù)包不經(jīng)過操作系統(tǒng)內(nèi)核進(jìn)行處理，用戶空間程序收發(fā)數(shù)據(jù)包時(shí)，直接與網(wǎng)卡進(jìn)行通信。在Netmap框架下，內(nèi)核擁有數(shù)據(jù)包池，發(fā)送環(huán)接收環(huán)上的數(shù)據(jù)包不需要?jiǎng)討B(tài)申請(qǐng)，有數(shù)據(jù)到達(dá)網(wǎng)卡時(shí)，當(dāng)有數(shù)據(jù)到達(dá)后，直接從數(shù)據(jù)包池中取出一個(gè)數(shù)據(jù)包，然后將數(shù)據(jù)放入此數(shù)據(jù)包中，再將數(shù)據(jù)包的描述符放入接收環(huán)中。內(nèi)核中的數(shù)據(jù)包池，通過mmap技術(shù)映射到用戶空間。用戶態(tài)程序最終通過netmap_if獲取接收發(fā)送環(huán)netmap_ring，進(jìn)行數(shù)據(jù)包的獲取發(fā)送。
與硬件解耦 ，只需要對(duì)網(wǎng)卡驅(qū)動(dòng)程序稍微做點(diǎn)修改就可以使用此框架（幾十行行），傳統(tǒng)網(wǎng)卡驅(qū)動(dòng)將數(shù)據(jù)包傳遞給操作系統(tǒng)內(nèi)核中協(xié)議棧，而修改后的數(shù)據(jù)包直接放入Netmap_ring供用戶使用。 虛擬交換機(jī)場(chǎng)景下，使用Netmap可以實(shí)現(xiàn)不同網(wǎng)卡間高效數(shù)據(jù)轉(zhuǎn)發(fā)，將一個(gè)網(wǎng)卡的數(shù)據(jù)放到另外一個(gè)網(wǎng)卡上時(shí)，只需要將接收環(huán)中的packet的描述符放入發(fā)送環(huán)，不需要拷貝數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)包的零拷貝。
4.2 簡(jiǎn)單 對(duì)比 netmap 和 DPDK。
可能唯一相同之處就是: 將 NIC 的 rx_ring_buffer 和 tx_ring_buffer，映射到 user-level，直接在 user-level 進(jìn)行 packet RX/TX。- 相比 DPDK 來說，netmap 并不能算作一個(gè)豐富的SDK。
- 使用netmap，需要很多手動(dòng)操作的細(xì)節(jié)，比如說 手動(dòng)修改 netmap_shadow_ring，不是很方便
- rx_/tx_ring_buffer 都是由 netmap.ko 預(yù)分配，user-level application 不能動(dòng)態(tài)分配，只能使用，而已。
- netmap 并不是在 user-level 實(shí)現(xiàn) driver （__ DPDK 的 PMD 是在 user-level ）。 而是，在原本的 kernel driver 上打 patch，加入 netmap 自定義的邏輯。Linux 中仍然會(huì)有 "ethX" 這樣的 "net_device"。 只不過 Linux stack 無法直接向其收發(fā)packet，罷了。但是 "ifconfig" 之類的東西，還是可以用的。
- 仍然會(huì)有 中斷。對(duì)于 packet RX，仍然是 RX IRQ handler -> BH napi_rx_poll()，對(duì)于 packet TX，仍然是 TX-DONE IRQ handler -> BH napi_tx_done_poll()。 只不過，netmap 會(huì)在 poll() 中加入自定義的邏輯，替換掉driver 原本的邏輯。
- netmap 只是將 ring_buffer 映射到user-level。但并不將 NIC hw_ring_descriptors 映射到 user-level。 每種不同的NIC 的 descriptor 格式，都不一樣。因?yàn)樵O(shè)計(jì)上的考慮，想要對(duì)user-level application表現(xiàn)得common 和 generic ，就不能映射。 幾乎全部 NIC HW offload features，比如說 VLAN offload, checksum offload, TSO, 等，都需要特別設(shè)置 hw_ring_descriptors 的一些fields。netmap 完全不考慮這些 NIC HW offload features。
- netmap 也沒有像 DPDK 那樣規(guī)定 lcore thread model 和 進(jìn)行packet RX/TX時(shí)的 multi-thread best practice。對(duì)于 netmap來說，thread, priority, CPU affinity, 等等，都不是 netmap 本身規(guī)定的內(nèi)容，而完全由 使用netmap的 programmer 來控制。
-
netmap 只是進(jìn)行最簡(jiǎn)單的 packet RX/TX。沒有其他任何對(duì) packet 進(jìn)行處理的 library。比如說，DPDK 提供了對(duì) packet data 進(jìn)行處理的 GRO, GSO, IP分片/重組，QoS，加解密，等等等 library。 但是，這些都不是 netmap 的內(nèi)容。
高性能包捕獲方案的比較
綜上所述，ＤＰＤＫ高速報(bào)文捕獲技術(shù)更加適合于作為高速報(bào)文捕獲機(jī)制的基礎(chǔ)解決方案。
參考：
https://blog.csdn.net/gengzhikui1992/article/details/103142848
https://blog.csdn.net/xzhao28/article/details/109112898
