网络数据包分析网卡Offload

http://blog.nsfocus.net/network-packets-analysis-nic-offload/

对于网络安全来说，网络传输数据包的捕获和分析是个基础工作，绿盟科技研究员在日常工作中，经常会捕获到一些大小远大于MTU值的数据包，经过分析这些大包的特性，发现和网卡的offload特性有关，本文对网卡Offload技术做简要描述。

文章目录

网络分片技术

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的相关选项，或者在链路的其他节点进行抓包。