Linux 經典的幾款收包引擎

   
 
 
    公衆號關注 
 
    「 
 
    傑哥的IT之旅 
 
    」， 

   

   
   
    
    
             
    

   
 
 
    選擇「 
 
    星標 
 
    」， 
 
    重磅乾貨，第一 
 
    時間送達！ 

   

   
   
    
    
             
    

   
 
 
    
 

   

來自：網絡安全研發隨想 

連接：https://urlify.cn/7vYNJj

本文列舉四個比較經典的 Linux 收包引擎，若是還有其餘你以爲ok的能夠留言。這四個分別是：

• libpcap/libpcap-mmap

• PF_RING

• DPDK

• xdp

libpcap

libpcap的包捕獲機制是在數據鏈路層增長一個旁路處理，不干擾系統自身的網路協議棧的處理，對發送和接收的數據包經過Linux內核作過濾和緩衝處理，最後直接傳遞給上層應用程序。

一、數據包到達網卡設備。
二、網卡設備依據配置進行DMA操做。（ 「第1次拷貝」 ：網卡寄存器->內核爲網卡分配的緩衝區ring buffer）
三、網卡發送中斷，喚醒處理器。
四、驅動軟件從ring buffer中讀取，填充內核skbuff結構（ 「第2次拷貝」 ：內核網卡緩衝區ring buffer->內核專用數據結構skbuff）
五、接着調用netif_receive_skb函數：

• 5.1 若是有抓包程序，由網絡分接口進入BPF過濾器，將規則匹配的報文拷貝到系統內核緩存 （ 「第3次拷貝」）。BPF爲每個要求服務的抓包程序關聯一個filter和兩個buffer。BPF分配buffer 且一般狀況下它的額度是4KB the store buffer 被使用來接收來自適配器的數據；the hold buffer被使用來拷貝包到應用程序。

• 5.2 處理數據鏈路層的橋接功能；

• 5.3 根據skb->protocol字段肯定上層協議並提交給網絡層處理，進入網絡協議棧，進行高層處理。

六、libpcap繞過了Linux內核收包流程中協議棧部分的處理，使得用戶空間API能夠直接調用套接字PF_PACKET從鏈路層驅動程序中得到數據報文的拷貝，將其從內核緩衝區拷貝至用戶空間緩衝區（ 「第4次拷貝」 ）

libpcap-mmap

libpcap-mmap是對舊的libpcap實現的改進，新版本的libpcap基本都採用packet_mmap機制。PACKET_MMAP經過mmap，減小一次內存拷貝（ 「第4次拷貝沒有了」 ），減小了頻繁的系統調用，大大提升了報文捕獲的效率。

PF_RING

咱們看到以前libpcap有4次內存拷貝。libpcap_mmap有3次內存拷貝。PF_RING提出的核心解決方案即是減小報文在傳輸過程當中的拷貝次數。

咱們能夠看到，相對與libpcap_mmap來講，pfring容許用戶空間內存直接和rx_buffer作mmap。這又減小了一次拷貝 （ 「libpcap_mmap的第2次拷貝」 ：rx_buffer->skb）

PF-RING ZC實現了DNA（Direct NIC Access 直接網卡訪問）技術，將用戶內存空間映射到驅動的內存空間，使用戶的應用能夠直接訪問網卡的寄存器和數據。

經過這樣的方式，避免了在內核對數據包緩存，減小了一次拷貝（ 「libpcap的第1次拷貝」 ，DMA到內核緩衝區的拷貝）。這就是徹底的零拷貝。

其缺點是，只有一個 應用能夠在某個時間打開DMA ring（請注意，如今的網卡能夠具備多個RX / TX隊列，從而就能夠在每一個隊列上同時一個應用程序），換而言之，用戶態的多個應用須要彼此溝通才能分發數據包。

DPDK

pf-ring zc和dpdk都可以實現數據包的零拷貝，二者均旁路了內核，可是實現原理略有不一樣。pf-ring zc經過zc驅動（也在應用層）接管數據包，dpdk基於UIO實現。

一、UIO+mmap 實現零拷貝（zero copy）

UIO（Userspace I/O）是運行在用戶空間的I/O技術。Linux系統中通常的驅動設備都是運行在內核空間，而在用戶空間用應用程序調用便可，而UIO則是將驅動的不多一部分運行在內核空間，而在用戶空間實現驅動的絕大多數功能。採用Linux提供UIO機制，能夠旁路Kernel，將全部報文處理的工做在用戶空間完成。

二、UIO+PMD 減小中斷和CPU上下文切換

DPDK的UIO驅動屏蔽了硬件發出中斷，而後在用戶態採用主動輪詢的方式，這種模式被稱爲PMD（Poll Mode Driver）。

與DPDK相比，pf-ring（no zc）使用的是NAPI polling和應用層polling，而pf-ring zc與DPDK相似，僅使用應用層polling。

三、HugePages 減小TLB miss

在操做系統引入MMU（Memory Management Unit）後，CPU讀取內存的數據須要兩次訪問內存。第一次要查詢頁表將邏輯地址轉換爲物理地址，而後訪問該物理地址讀取數據或指令。

爲了減小頁數過多，頁表過大而致使的查詢時間過長的問題，便引入了TLB(Translation Lookaside Buffer)，可翻譯爲地址轉換緩衝器。TLB是一個內存管理單元，通常存儲在寄存器中，裏面存儲了當前最可能被訪問到的一小部分頁表項。

引入TLB後，CPU會首先去TLB中尋址，因爲TLB存放在寄存器中，且其只包含一小部分頁表項，所以查詢速度很是快。若TLB中尋址成功（TLB hit），則無需再去RAM中查詢頁表；若TLB中尋址失敗（TLB miss），則須要去RAM中查詢頁表，查詢到後，會將該頁更新至TLB中。

而DPDK採用HugePages ，在x86-64下支持2MB、1GB的頁大小，大大下降了總頁個數和頁表的大小，從而大大下降TLB miss的概率，提高CPU尋址性能。

四、其它優化

• SNA（Shared-nothing Architecture），軟件架構去中心化，儘可能避免全局共享，帶來全局競爭，失去橫向擴展的能力。NUMA體系下不跨Node遠程使用內存。

• SIMD（Single Instruction Multiple Data），從最先的mmx/sse到最新的avx2，SIMD的能力一直在加強。DPDK採用批量同時處理多個包，再用向量編程，一個週期內對全部包進行處理。好比，memcpy就使用SIMD來提升速度。

• cpu affinity：即 CPU 親和性

XDP

xdp表明eXpress數據路徑，使用ebpf 作包過濾，相對於dpdk將數據包直接送到用戶態，用用戶態當作快速數據處理平面，xdp是在驅動層建立了一個數據快速平面。在數據被網卡硬件dma到內存，分配skb以前，對數據包進行處理。

請注意，XDP並無對數據包作Kernel bypass，它只是提早作了一點預檢而已。

相對於DPDK，XDP具備如下優勢：

• 無需第三方代碼庫和許可

• 同時支持輪詢式和中斷式網絡

• 無需分配大頁

• 無需專用的CPU

• 無需定義新的安全網絡模型

XDP的使用場景包括：

• DDoS防護

• 防火牆

• 基於XDP_TX的負載均衡

• 網絡統計

• 複雜網絡採樣

• 高速交易平臺

OK，以上就是今天的分享，若是你以爲還有其餘的收包引擎，能夠留言分享。

---

若是您以爲這篇文章對您有點用的話，麻煩您爲本文來個四連：轉發分享、點贊、點在看、留言，由於這將是我寫做與分享更多優質文章的最強動力！

---

本公衆號所有博文已整理成一個目錄，請在公衆號後臺回覆「m」獲取！

推薦閱讀：

一、 最全 VxLAN 知識詳解
二、 什麼是堡壘機？爲何須要堡壘機？
三、 Linux 系統下對目錄擴容的方法
四、 一文吃透 Linux 提權
五、 Linux 日誌文件系統原來是這樣工做的
六、 Linux 網絡狀態工具 ss 命令使用詳解

關注微信公衆號「 傑哥的IT之旅」，後臺回覆「 1024」查看更多內容，回覆「 加羣」 備註：地區-職業方向-暱稱 便可加入讀者交流羣。

     
 
 
      
  
       
       
        
        
                 
        
  
       

   
        
        
         
         
                  
         
   
        
 
         
 
          
 
           
 
            
 
             
 
               
             
 
             
 
              點個[在看]，是對傑哥最大的支持！ 
             
 
            
 
           
 
          
 
         
 
        
  
       
       
        
        
                 
        
  
       
 

     

本文分享自微信公衆號 - 傑哥的IT之旅（Jake_Internet）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。