網絡分片技術
MTU
最大傳輸單元，指一種通信協議的某一層上面所能通過的最大數據包大小（以字節爲單位）。
在以太網通信中，MTU規定了經過網絡層封裝的數據包的最大長度。例如，若某個接口的MTU值爲1500，則通過此接口傳送的IP數據包的最大長度爲1500字節。
小編注：對於普通用戶來說，如果你優化過迅雷的下載速度，可能通過這篇文章《 合理設置MTU，提升下載速度 》，對MTU的基礎知識有所瞭解。
IP分片
當IP層需要傳送的數據包長度超過MTU值時，則IP層需要對該數據包進行分片，使每一片的長度小於或等於MTU值。在分片過程中，除了對payload進行分片外，數據包的IP首部也需要進行相應的更改：
- 將identifier字段的值複製給每個分片；
- 將分片數據包的Flags中的DF位置爲0；
- 除最後一個分片之外的其他分片，將MF位置爲1；
- 將Fragment Offset字段設置正確的值。
MSS
最大分段長度，TCP數據包每次能夠傳輸的最大數據分段長度，在TCP協議的實際實現中，MSS往往用MTU-(IP Header Length + TCP Header Length)來代替。在TCP通信建立連接時，取兩端提供的MSS的最小值作爲會話的MSS值。由於TCP分段有MSS值的限制，通常情況下TCP數據包經IP層封裝後的長度不會大於MTU，因此一般情況下，TCP數據包不會進行IP分片。
網卡offload機制
早先TCP設計的目標是爲了解決低速網絡傳輸的不可靠性問題（撥號上網的年代），但隨着互聯網骨幹傳輸速度的提升（光纖、千兆以太、萬兆以太）以及用戶端更可靠的訪問機制的出現（ADSL等），相關的數據中心及客戶端桌面環境上的TCP軟件常常需要面臨大量的計算需求。
當網絡速度超過1Gb的時候，這些計算會耗費大量的CPU時間，有數據表明，即便使用千兆全雙工網卡，TCP通信也將消耗CPU的80%的使用率（以2.4GHz奔騰4處理器爲例），這樣留給其他應用程序的時間就很少了，表現出來就是用戶可能感覺到很慢。
小編注：當年的蠕蟲病毒對CPU的影響與此近似。
爲了解決性能問題，就產生了TOE技術（TCP offload engine），將TCP連接過程中的相關計算工作轉移到專用硬件上（比如網卡），從而釋放CPU資源。從2012年開始，這項技術開始在普通用戶的網卡上應用。
隨着技術的日趨成熟，目前越來越多的網卡設備開始支持offload特性，以便提升網絡收發和處理的性能。本文所描述的offload特性，主要是指將原本在協議棧中進行的IP分片、TCP分段、重組、checksum校驗等操作，轉移到網卡硬件中進行，降低系統CPU的消耗，提高處理性能。
發送模式
**TSO （tcp-segmentation-offload） **
從名字來看很直觀，就是把tcp分段的過程轉移到網卡中進行。當網卡支持TSO機制時，可以直接把不超過滑動窗口大小的payload下傳給協議棧，即使數據長度大於MSS，也不會在TCP層進行分段，同樣也不會進行IP分片，而是直接傳送給網卡驅動，由網卡驅動進行tcp分段操作，並執行checksum計算和包頭、幀頭的生成工作。例如，
在本地主機上（10.8.55.1）發送一個超長的HTTP請求，當TSO模式關閉時，10.8.55.1抓包如下
當TSO模式開啓時，10.8.55.1抓包如下：
**UFO（udp-fragmentation-offload） **
是一種專門針對udp協議的特性，主要機制就是將IP分片的過程轉移到網卡中進行，用戶層可以發送任意大小的udp數據包（udp數據包總長度最大不超過64k），而不需要協議棧進行任何分片操作。目前貌似沒找到有支持UFO機制的網卡，主要是應用在虛擬化設備上。
**GSO（generic-segmentation-offload） **
相對於TSO和UFO，GSO機制是針對所有協議設計的，更爲通用。同時，與TSO、UFO不同的是，GSO主要依靠軟件的方式實現，對於網卡硬件沒有過多的要求。其基本思想就是把數據分片的操作儘可能的向底層推遲直到數據發送給網卡驅動之前，並先檢查網卡是否支持TSO或UFO機制，如果支持就直接把數據發送給網卡，否則的話再進行分片後發送給網卡，以此來保證最少次數的協議棧處理，提高數據傳輸和處理的效率。
接收模式
**LRO/GRO（large-receive-offload） **
在網卡驅動層面上將接受到的多個TCP數據包聚合成一個大的數據包，然後上傳給協議棧處理。這樣可以減少協議棧處理的開銷，提高系統接收TCP數據的能力和效率。
generic-receive-offload ，基本思想和LRO類似，只是改善了LRO的一些缺點，比LRO更加通用。目前及後續的網卡都採用GRO機制，不再使用LRO機制。例如，
當本地主機（10.51.19.40）開啓GRO模式時，從主機10.8.55.11向主機10.51.19.40發送一個超長請求。
10.8.55.11抓包如下：
10.51.19.40抓包如下：
**RSS（Receive Side Scaling） **
具備多個RSS隊列的網卡，可以將不同的網絡流分成不同的隊列，再將這些隊列分配到多個CPU核心上進行處理，從而將負荷分散，充分利用多核處理器的能力，提交數據接收的能力和效率。
網卡offload模式的設置
Linux
在linux系統下，可以通過ethtool查看各模式的狀態並進行設置：
**查看狀態 **
- ethtool –k設備名
**設置開關狀態 **
- ethtool –K設備名模式名（縮寫）on/off
windows
在windows系統下，可以通過設備管理器中網卡設備的屬性對網卡模式進行查看和調整。以Intel 82579LM和Intel I217-LM網卡爲例
- IPv4、TCP、UDP校驗和分載傳輸控制的是在網卡中進行checksum的計算和校驗，其中Rx表示接收數據、Tx表示發送數據。
- 大型發送分載對應的是前文中提到的TSO模式
- 接收方調整和接收方調整隊列對應的是RRS模式的啓用狀態以及RSS隊列的個數設置。
網卡Offload技術給網絡數據包分析帶來的影響
目前常用的抓包工具大部分都是從協議棧中（如數據鏈路層）捕獲數據包，而網卡的offload特性會將數據包的分片、重組等工作轉移到協議棧以下的硬件層面進行，因此在開啓TSO、GRO等機制的情況下，我們使用tcpdump、wireshark等工具抓取到的數據包往往不能真實反應鏈路上實際的數據幀，給網絡流量特徵的分析造成不利影響。
在某些情況下，例如分片攻擊等攻擊方式，甚至可能會因爲網卡設備的offload機制處理，而規避防火牆、IDS以及人工的檢查。針對這些情況，可以選擇關閉網卡offload的相關選項，或者在鏈路的其他節點進行抓包。