網(wǎng)絡(luò)數(shù)據(jù)包分析 網(wǎng)卡Offload
對于網(wǎng)絡(luò)安全來說，網(wǎng)絡(luò)傳輸數(shù)據(jù)包的捕獲和分析是個基礎(chǔ)工作，綠盟科技研究員在日常工作中，經(jīng)常會捕獲到一些大小遠(yuǎn)大于MTU值的數(shù)據(jù)包，經(jīng)過分析這些大包的特性，發(fā)現(xiàn)和網(wǎng)卡的offload特性有關(guān)，本文對網(wǎng)卡Offload技術(shù)做簡要描述。
網(wǎng)絡(luò)分片技術(shù)
MTU
最大傳輸單元，指一種通信協(xié)議的某一層上面所能通過的最大數(shù)據(jù)包大小（以字節(jié)為單位）。
在以太網(wǎng)通信中，MTU規(guī)定了經(jīng)過網(wǎng)絡(luò)層封裝的數(shù)據(jù)包的最大長度。例如，若某個接口的MTU值為1500，則通過此接口傳送的IP數(shù)據(jù)包的最大長度為1500字節(jié)。
小編注：對于普通用戶來說，如果你優(yōu)化過迅雷的下載速度，可能通過這篇文章《合理設(shè)置MTU，提升下載速度》，對MTU的基礎(chǔ)知識有所了解。
IP分片
當(dāng)IP層需要傳送的數(shù)據(jù)包長度超過MTU值時，則IP層需要對該數(shù)據(jù)包進(jìn)行分片，使每一片的長度小于或等于MTU值。在分片過程中，除了對payload進(jìn)行分片外，數(shù)據(jù)包的IP首部也需要進(jìn)行相應(yīng)的更改：
將identifier字段的值復(fù)制給每個分片；
將分片數(shù)據(jù)包的Flags中的DF位置為0；
除最后一個分片之外的其他分片，將MF位置為1；
將Fragment Offset字段設(shè)置正確的值。
MSS
最 大分段長度，TCP數(shù)據(jù)包每次能夠傳輸?shù)淖畲髷?shù)據(jù)分段長度，在TCP協(xié)議的實際實現(xiàn)中，MSS往往用MTU-(IP Header Length + TCP Header Length)來代替。在TCP通信建立連接時，取兩端提供的MSS的最小值作為會話的MSS值。由于TCP分段有MSS值的限制，通常情況下TCP數(shù)據(jù) 包經(jīng)IP層封裝后的長度不會大于MTU，因此一般情況下，TCP數(shù)據(jù)包不會進(jìn)行IP分片。
網(wǎng)卡offload機(jī)制
早先TCP設(shè)計的目標(biāo)是為了解決低速網(wǎng)絡(luò)傳輸?shù)牟豢煽啃詥栴}（撥號上網(wǎng)的年代），但隨著互聯(lián)網(wǎng)骨干傳輸速度的提升（光纖、千兆以太、萬兆以太）以及用戶端更可靠的訪問機(jī)制的出現(xiàn)（ADSL等），相關(guān)的數(shù)據(jù)中心及客戶端桌面環(huán)境上的TCP軟件常常需要面臨大量的計算需求。
當(dāng)網(wǎng)絡(luò)速度超過1Gb的時候，這些計算會耗費大量的CPU時間，有數(shù)據(jù)表明，即便使用千兆全雙工網(wǎng)卡，TCP通信也將消耗CPU的80%的使用率（以2.4GHz奔騰4處理器為例），這樣留給其他應(yīng)用程序的時間就很少了，表現(xiàn)出來就是用戶可能感覺到很慢。
小編注：當(dāng)年的蠕蟲病毒對CPU的影響與此近似。
為了解決性能問題，就產(chǎn)生了TOE技術(shù)（TCP offload engine），將TCP連接過程中的相關(guān)計算工作轉(zhuǎn)移到專用硬件上（比如網(wǎng)卡），從而釋放CPU資源。從2012年開始，這項技術(shù)開始在普通用戶的網(wǎng)卡上應(yīng)用。
隨 著技術(shù)的日趨成熟，目前越來越多的網(wǎng)卡設(shè)備開始支持offload特性，以便提升網(wǎng)絡(luò)收發(fā)和處理的性能。本文所描述的offload特性，主要是指將原本 在協(xié)議棧中進(jìn)行的IP分片、TCP分段、重組、checksum校驗等操作，轉(zhuǎn)移到網(wǎng)卡硬件中進(jìn)行，降低系統(tǒng)CPU的消耗，提高處理性能。
發(fā)送模式
**TSO （tcp-segmentation-offload） **
從 名字來看很直觀，就是把tcp分段的過程轉(zhuǎn)移到網(wǎng)卡中進(jìn)行。當(dāng)網(wǎng)卡支持TSO機(jī)制時，可以直接把不超過滑動窗口大小的payload下傳給協(xié)議棧，即使數(shù) 據(jù)長度大于MSS，也不會在TCP層進(jìn)行分段，同樣也不會進(jìn)行IP分片，而是直接傳送給網(wǎng)卡驅(qū)動，由網(wǎng)卡驅(qū)動進(jìn)行tcp分段操作，并執(zhí)行checksum 計算和包頭、幀頭的生成工作。例如，
在本地主機(jī)上（10.8.55.1）發(fā)送一個超長的HTTP請求，當(dāng)TSO模式關(guān)閉時，10.8.55.1抓包如下
當(dāng)TSO模式開啟時，10.8.55.1抓包如下：
**UFO（udp-fragmentation-offload） **
是一種專門針對udp協(xié)議的特性，主要機(jī)制就是將IP分片的過程轉(zhuǎn)移到網(wǎng)卡中進(jìn)行，用戶層可以發(fā)送任意大小的udp數(shù)據(jù)包（udp數(shù)據(jù)包總長度最大不超過64k），而不需要協(xié)議棧進(jìn)行任何分片操作。目前貌似沒找到有支持UFO機(jī)制的網(wǎng)卡，主要是應(yīng)用在虛擬化設(shè)備上。
**GSO（generic-segmentation-offload） **
相 對于TSO和UFO，GSO機(jī)制是針對所有協(xié)議設(shè)計的，更為通用。同時，與TSO、UFO不同的是，GSO主要依靠軟件的方式實現(xiàn)，對于網(wǎng)卡硬件沒有過多 的要求。其基本思想就是把數(shù)據(jù)分片的操作盡可能的向底層推遲直到數(shù)據(jù)發(fā)送給網(wǎng)卡驅(qū)動之前，并先檢查網(wǎng)卡是否支持TSO或UFO機(jī)制，如果支持就直接把數(shù)據(jù) 發(fā)送給網(wǎng)卡，否則的話再進(jìn)行分片后發(fā)送給網(wǎng)卡，以此來保證最少次數(shù)的協(xié)議棧處理，提高數(shù)據(jù)傳輸和處理的效率。
接收模式
**LRO/GRO（large-receive-offload） **
在網(wǎng)卡驅(qū)動層面上將接受到的多個TCP數(shù)據(jù)包聚合成一個大的數(shù)據(jù)包，然后上傳給協(xié)議棧處理。這樣可以減少協(xié)議棧處理的開銷，提高系統(tǒng)接收TCP數(shù)據(jù)的能力和效率。
generic-receive-offload，基本思想和LRO類似，只是改善了LRO的一些缺點，比LRO更加通用。目前及后續(xù)的網(wǎng)卡都采用GRO機(jī)制，不再使用LRO機(jī)制。例如，
當(dāng)本地主機(jī)（10.51.19.40）開啟GRO模式時，從主機(jī)10.8.55.11向主機(jī)10.51.19.40發(fā)送一個超長請求。
10.8.55.11抓包如下：
10.51.19.40抓包如下：
**RSS（Receive Side Scaling） **
具備多個RSS隊列的網(wǎng)卡，可以將不同的網(wǎng)絡(luò)流分成不同的隊列，再將這些隊列分配到多個CPU核心上進(jìn)行處理，從而將負(fù)荷分散，充分利用多核處理器的能力，提交數(shù)據(jù)接收的能力和效率。
聯(lián)系客服
