NFV、DPDK以及部分用戶態協議研究

本文爲做者原創，轉載請註明出處（http://www.cnblogs.com/mar-q/）by 負贔屓

　　對筆者而言，這是一個挺新的領域，比較有意思。

　　1、解釋名詞：

　　NFV（Network Function Virtualization）：經過使用x86等通用性硬件以及虛擬化技術，來承載不少功能的軟件處理。從而下降網絡昂貴的設備成本。 這項技術的目的在於軟硬件的解耦合，讓網絡設備功能再也不依賴於底層硬件，爲啥呢，由於硬件研發週期長，貴啊。

　　DPDK（Intel Data Plane Development Kit）：Intel數據面開發包，它是一組快速處理數據包的開發平臺接口。

　　2、咱們的網絡存在什麼問題？

　　目前服務器併發量達到C10k是沒有問題的，經過軟件做出了比較好的解決方案，例如Nginx、Lighthttp等基於事件驅動的web框架和Tornado這類非阻塞web框架，都可以較好的解決萬級別的用戶請求。目前的非阻塞或者異步，原理上都是線程的異步模式，也就是說仍是須要線程進行上下文切換，只不過區別在於內核什麼時候產生中斷。 

　　可是這種異步模式到了C10M基本就不夠用了，網絡請求達到了千萬級，這在之前也許是網絡設備廠商須要考慮的事情，隨着硬件設備的發展，愈來愈趨於模塊的統一化。例如曾經網絡專用處理器是Intel公司的主力產品線，誕生了IXP4xx~IXP28xx等一系列專用處理芯片，而在2006年左右，AMD和Intel曾經爆發過一場多核之戰，隨着新一代core架構的誕生（Intel要感謝以色列的工程師），這場戰爭基本宣告結束，可是在當時，AMD在技術上曾經一度領先，個人第一臺電腦CPU就是AMD的。此次商業大戰讓Intel思考使用通用多核處理器取代IXP專用處理器，由此IXP的研發體系開始向Intel多核CPU轉型，這爲DPDK的誕生創造了條件。

　　爲啥爲Intel向通用CPU轉型就會產生DPDK呢，由於使用通用的底層硬件咱們就能夠沒必要太關注底層，你們都是用的X86，都是用的RISC，因此更多的功能能夠放在軟件層面來完成，尤爲是硬件開發成本和週期是遠遠超過軟件的，因此何樂而不爲呢。再回到前面的問題，爲何異步解決不了C10M的問題呢？由於線程的頻繁調度是須要內核進行上下文切換的，而CPU是存在指令週期的，尤爲是當Cache不命中的時候，切換上下文的指令週期會延長不少，要解決這個問題就要避開這種中斷模式：即採用輪詢的方式來提高性能。

　　從數據包角度分析：這就要求咱們必須繞開現有的內核協議，由於現有的內核協議棧是基於中斷模式的，若是要繞開內核，那就要解決驅動問題，解決網卡接口數據怎麼到內存的問題，這些就是DPDK所提供的功能。

　　從多核角度分析：要儘可能減小線程的調度和切換，最好每一個OS進程綁定一個核，每一個核上數據結構都大體相同，在NUMA架構（非一致性訪存體系結構，分多節點，每一個節點多個CPU，內部共享一個內存控制器）下提升訪存速度。　　

　　從內存角度分析：要儘可能減小Cache miss，若是每一個用戶佔用2k空間，10M的用戶將使用20g內存，這麼多併發鏈接必定會產生Cache miss，一旦失效CPU運行時間會提升一個數量級，所以咱們能夠經過大頁的方法，儘可能把內存劃分更少的塊數，以此提升命中率。

　　綜上，千萬級數據包的處理思路就是：摒棄內核協議（PF_RING，Netmap，intelDPDK）、多核的OS綁定、內存大頁。[1]

　　3、用戶態協議

　　傳統X86架構網絡數據包處理是CPU中斷方式：網卡驅動接收數據包->中斷通知CPU處理->CPU拷貝數據並交給協議棧，當數據量大時會產生大量CPU中斷，致使CPU沒法運行其餘程序。DPDK採用輪詢方式處理：DPDK重載網卡驅動（接管網卡），DPDK接收數據包後不中斷，直接將數據包經過零拷貝技術存入內存，應用層直接經過DPDK接口直接從內存讀取數據包。 DPDK目前正在成爲實現NFV的一項標杆技術，它主要爲Intel architecture（IA）處理器架構下用戶空間高效的數據包處理提供庫函數和驅動的支持，它不一樣於Linux系統以通用性設計爲目的，而是專一於網絡應用中數據包的高性能處理，運行在用戶空間上利用自身提供的數據平面庫來收發數據包，繞過了Linux內核協議棧對數據包處理過程。[2]

　　須要注意的是，DPDK自己並非一項協議，它不提供諸如IP協議、防火牆等網絡協議功能，它只是咱們在OS下的一套數據處理接口。由於多年來，高性能網絡背後的傳統思想就是將全部的數據包處理功能，儘量的推向內核，數據報傳輸時須要跨越內核和用戶，數據報中斷產生的上下文切換和數據複製的成本都極大限制了數據報文處理的速度，因此咱們能夠用DPDK來繞過內核，這就是用戶態協議要完成的工做。

　　爲啥叫用戶態協議呢？它和現有的TCP/IP協議有什麼區別呢？簡而言之就是現有的TCP/IP協議都是基於內核運行的，而用戶態協議就是另外開發一套協議運行於內核以外。自2014年起在OSDI、NSDI、TOCS 等頂會期刊上出現了很多用戶態協議，列舉以下：

　　1. IX Project：Stanford & EPFL git、論文地址

　　IX是一個專門的數據面lib OS，解決了高吞吐量，低延遲，強大的保護和能源效率之間的4路權衡。IX使用硬件虛擬化將控制面與數據面分開，從而保持現有內核的健壯性。控制面負責資源分配，數據面負責提供高性能網絡I / O。經過對事件驅動關鍵應用的延遲和吞吐量進行優化，主要方法是按批次綁定處理數據包，最小化這些連續傳輸，並保持多核同步。 IX的團隊則認爲不該信任那些直接訪問設備的應用，一方面擔憂應用的穩定性，另外一方面這種方式對網絡安全產生的巨大威脅。所以IX經過Intel虛擬化擴展讓I/O路徑和應用程序代碼共存，將隊列映射到內核，可是仍然設法在隔離的保護域中運行網絡堆棧，在這個隔離的保護域中，應用程序不能使用數據。

　　簡而言之，IX本身實現了一個叫dune的安全核，由於須要使用硬件虛擬化，因此IX目前支持的網卡有限，我後續會發布測試的文章。

　　2. mTCP：KAIST（韓）git、論文地址

　　mTCP是一個基於多核的高性能用戶態協議，這個團隊認爲因爲內核和用戶空間之間移動數據所採起的機制（如數據拷貝和上下文切換），內核正在阻礙實現良好可擴展的網絡性能，因此他們徹底拋棄內核，利用新的網卡NIC和CPU功能（如multiqueue），將設備驅動程序和網絡堆棧直接移入應用程序，並將內核徹底從IO路徑中取出。 

　　3. Arrakis：git

　　作法和mTCP相似，它不只在應用數據上繞過了內核，它不只對網絡數據包進行內核屏蔽，對數據存儲也進行了屏蔽。

　　4. Sandstorm：論文地址　　比mTCP在層和API方面更深刻一些，它保留了到客戶端應用程序的POSIX套接字接口，儘管它們被從新編譯連接到mTCP而不是網絡的libc，它還實現了一個用戶級堆棧，對網絡代碼進行特定應用調整，爲Web和DNS服務器實現提供加速。　　

　　5. 國內的幾個大的用戶態協議棧 

• DPDK-ANS，相似mTCP，他們和阿里走得比較近，已經開始商業運做了，可是開源不是不少：git傳送

• f-stack，騰訊一個團隊開發的用戶態協議棧，使用了FreeBSD：git傳送

　　4、其餘解決方案

　　上面的分析咱們能夠看到，主要瓶頸就是內核，繞過內核就可以獲更高的性能，安全性咋辦呢，IX彷佛更好一些，他們的項目中集成了一個dune的系統，這套系統相似於一個安全殼，也就是他們所言的dataplane operating system，dune這個項目是10年就開始作的，因此他們至關因而搞了一套結合運用。

　　我在跑這套項目的時候還注意到了另外一套標準RDMA（Remote Direct Memory Access）遠程直接數據存取，就是爲了解決網絡傳輸中服務器端數據處理的延遲而產生的。RDMA這種技術之前只能運行在專用網絡下（例如超算平臺），爲了將這種技術用在以太網環境下，就逐步發展出了RoCE/iWarp兩種協議。RoCE目前主要是由Mellonax主導（以色列一家專一高性能網絡設備研發的公司），和TCP協議無關，性能更好。iWarp主要由Chelsio主導，下層會依賴TCP協議，性能和可擴性行都差一些，優勢是考慮了對廣域網的支持。目前來看RoCE比iWarp前景更好，實際使用也更普遍。對比DPDK，DPDK是Intel主導，提供了基於用戶態的數據鏈路層的功能，能夠在上面構建出基於用戶態的網絡棧。實際使用中一個顯然的缺點是隻有poll功能，沒有陷入中斷來減小對CPU的消耗。明顯RDMA偏專用線路（須要專用網卡支持），DPDK則走通用路線（Intel本身就搞定了）。[3]

　　發展出這麼多協議和實現，根本緣由在於網絡硬件發展很快，而目前佔據主導的TCP/IP協議仍然是爲了適配當初低速網絡環境設計的。關注了一下最近DPDK在學術界的走向，以及開始向底層網件發展了，相信不久就會出現成熟商用的通用型快速網絡體系。

 

 

參考：

[1]https://mp.weixin.qq.com/s?__biz=MzA3ODgyNzcwMw==&mid=202113096&idx=1&sn=7ce616f596c529890dfd475ce8d31858&scene=4#wechat_redirect

[2]http://dpdk.org/browse/dpdk/tree/examples/

[3]http://blog.csdn.net/sdulibh/article/details/51829830