该如何缓解网卡的普遍问题?

作者 | 阿文

责编 | Elle

在互联网的早期，使用网络分片和分段的机制，可以很大程度上减轻了解决低速网络传输的不可靠性问题，下面先简单介绍下网络分片技术。

网络分片技术

MTU

最大传输单元（Maximum Transmission Unit，MTU）用来通知对方所能接受数据服务单元的最大尺寸，说明发送方能够接受的有效载荷大小。是包或帧的最大长度，一般以字节记。

在以太网通信中，MTU规定了经过网络层封装的数据包的最大长度。例如，若某个接口的MTU值为1500，则通过此接口传送的IP数据包的最大长度为1500字节。在Linux中通过netstat -i 可以查看对于网卡接口的MTU，如下所示:

[root@centos ~]# netstat -i

Kernel Interface table

Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0 1500 318145 0 0 0 492216 0 0 0 BMRU

lo 65536 5334 0 0 0 5334 0 0 0 LRU

MSS

MSS（Maximum Segment Size，最大报文长度），是TCP协议定义的一个选项，MSS选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。

为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以一般MSS值1460。

而一般以太网MTU都为1500, 所以在以太网中, 往往TCP MSS为1460。

协商TCP MSS大小具体过程如下：

TCP client发出SYN报文，其中option选项填充的MSS字段一般为(MTU-IP头大小-TCP头大小)，同样TCP server收到SYN报文后，会发送SYN＋ACK报文应答，option选项填充的mss字段也为(MTU-IP头大小-TCP头大小)；协商双方会比较SYN和SYN+ACK报文中MSS字段大小，选择较小的MSS作为发送TCP分片的大小。

对于涉及PPPOE＋NAT、IPsec、L2TP、GRE等组网，通常由于报文太大需要分片，这样会降低传输速率; 所以选择一个合适的MSS对传输数据来说比较重要. linux中一般可以通过netfilter iptables设置TCP MSS来解决。

iptables -A FORWARD -p tcp- -tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

该规则的目的就是改变TCP MSS以适应PMTU(Path MTU)

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN- j TCPMSS --set-mss 1024

设置MSS为1024

IP分片

当IP层需要传送的数据包长度超过MTU值时，则IP层需要对该数据包进行分片，使每一片的长度小于或等于MTU值。在分片过程中，除了对payload进行分片外，数据包的IP首部也需要进行相应的更改：

• 将identifier字段的值复制给每个分片；

• 将分片数据包的Flags中的DF位置为0；

• 除最后一个分片之外的其他分片，将MF位置为1；

• 将Fragment Offset字段设置正确的值。

TCP分段

在TCP通信建立连接时，取两端提供的MSS的最小值作为会话的MSS值。当一次传输的payload数据长度大于MSS限制时，会将payload分割为多个数据段，分别封装在tcp报文中，按顺序进行传输。

由于MSS的限制，TCP通信在传输较长数据时会先进行TCP分段，所以其IP层报文长度会小于等于MTU值，因此TCP报文不会进行IP分片。而UDP通信由于没有类似机制，因此传输较长数据时，会在IP层根据MTU的限制，进行IP分片。简单概括起来就是：TCP协议进行TCP分段，UDP协议进行IP分片

网卡的offload机制

随着网络技术的发展和传输速度的提升，现在数据的传输量越来越大，因此，无论是IP分片还是TCP分段机制，对大量分片/分段包进行拆分/重组的工作，都带来了大量的计算需求，即面临着越来越多的CPU消耗。offload机制应运而生，它可以提升网络的收发性能，将本来该操作系统进行的一些数据包处理（如分片、重组等）放到网卡硬件中去做， 降低系统 CPU 消耗的同时，提高处理的性能。越来越多的网卡设备支持 offload 特性。

网卡 offload 包括 LSO/LRO、GSO/GRO、TSO/UFO 等。

LSO/LRO

LSO/LRO 分别对应到发送和接收两个方向，全称是 Large Segment Offload 和 Large Receive Offload。

LSO 计算机网络上传输的数据基本单位是离散的网包，既然是网包，就有大小限制，这个限制就是 MTU（Maximum Transmission Unit）的大小，一般是 1518 字节。

比如我们想发送很多数据出去，经过 OS 协议栈的时候，会自动帮你拆分成几个不超过 MTU 的网包。然而，这个拆分是比较费计算资源的（比如很多时候还要计算分别的 checksum),由 CPU 来做的话，往往会造成使用率过高。

在发送数据超过 MTU 限制的时候（太容易发生了），OS 只需要提交一次传输请求给网卡，网卡会自动的把数据拿过来，然后进行切，并封包发出，发出的网包不超过 MTU 限制。这就是LSO。

当网卡收到很多碎片包的时候，LRO 可以辅助自动组合成一段较大的数据，一次性提交给 OS 处理一般的，LSO 和 LRO 主要面向 TCP 报文。

TSO/UFO

TCP Segmentation Offload 和 UDP fragmentation offload，分别对应 TCP 报文和 UDP 报文。

对于支持TSO机制的网卡，可以直接把不超过滑动窗口大小 的payload下传给协议栈，即使数据长度大于MSS，也不会在TCP层进行分段，同样也不会进行IP分片，而是直接传送给网卡驱动，由网卡驱动进行tcp分段操作，并执行checksum计算和包头、帧头的生成工作。

UFO是专门针对udp协议的特性，主要机制就是将IP分片的过程转移到网卡中进行，用户层可以发送任意大小的udp数据包（udp数据包总长度最大不超过64k），而不需要协议栈进行任何分片操作。主要应用在虚拟化设备上，实际支持UFO机制的网卡非常少见。

GSO/GRO

对应的是 Generic Segmentation Offload 和 Generic Receive Offload。

可以理解为是TSO/UFO的合并升级，是针对所有协议设计的发送模式，更为通用。同时，GSO机制并不完全依赖于网卡硬件层面的支持。GSO机制首先通过软件实现的方式，将IP分片/TCP分段的操作，尽可能的向底层推迟，直到数据发送给网卡驱动之前。再对网卡的硬件特性进行判断，如果支持TSO/UFO机制，就直接把数据发送给网卡，由网卡进行IP分片/TCP分段操作。若网卡不支持上述机制，则在数据发送给网卡之前再去进行IP分片/TCP分段操作，这样即使不依靠网卡硬件，也最大幅度的减少了协议栈处理的次数，提高数据处理和传输的效率。

它比LSO 和 LRO 更通用，能够自动检测网卡支持特性，支持分包则直接发给网卡，否则先分包后发给网卡。的驱动一般用 GSO/GRO。

目前在实际的网卡应用上，主要是TSO和GSO机制组合使用，除了GSO单独作用于UDP报文以外，TSO和GSO都作用于TCP报文，其组合关系如下：

? GSO开启， TSO开启: 协议栈推迟分段，并直接传递大数据包到网卡，让网卡自动分段。

? GSO开启， TSO关闭: 协议栈推迟分段，在最后发送到网卡前才执行分段。

? GSO关闭， TSO开启: 同GSO开启， TSO开启。

? GSO关闭， TSO关闭: 不推迟分段，在tcp_sendmsg中直接发送MSS大小的数据包。

配置offload

我们使用 ethtool -k interface 可以查看当前网卡是否有开启这些特性

[root@centos ~]# ethtool -k eth0

Features for eth0:

……

tcp-segmentation-offload: on

tx-tcp-segmentation: on

tx-tcp-ecn-segmentation: on

tx-tcp-mangleid-segmentation: on

tx-tcp6-segmentation: on

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off



……

如果要开启或关闭

# ethtool -k eth0 gro off

# ethtool -k eth0 gso off

# ethtool -k eth0 tso off

在gro gso tso 为on 的情况下，使用tcp抓包,会发现length 超过 mtu 所设置的值

15:46:58.892537 IP centos.ssh > 223.132.11.12.37101: Flags [.], ack 11085075, win 13706, length 0

15:46:58.892574 IP 223.132.11.12.37101 > centos.ssh: Flags [P.], seq 11085075:11086523, ack 13969, win 1024, length 1448

15:46:58.892592 IP 223.132.11.12.37101 > centos.ssh: Flags [.], seq 11086523:11089419, ack 13969, win 1024, length 2896

15:46:58.892596 IP centos.ssh > 223.132.11.12.37101: Flags [.], ack 11089419, win 13706, length 0

15:46:58.892652 IP 223.132.11.12.37101 > centos.ssh: Flags [.], seq 11089419:11093763, ack 13969, win 1024, length 4344

15:46:58.892657 IP centos.ssh > 223.132.11.12.37101: Flags [.], ack 11093763, win 13706, length 0

而如果关闭，则length 最大值会在mtu所设置的范围之内。

15:53:01.123621 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44699683:44701131, ack 57626, win 1024, length 1448

15:53:01.123627 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44701131:44702579, ack 57626, win 1024, length 1448

15:53:01.123695 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44702579:44704027, ack 57626, win 1024, length 1448

15:53:01.123698 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44704027:44705475, ack 57626, win 1024, length 1448

15:53:01.123701 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44705475:44706923, ack 57626, win 1024, length 1448

15:53:01.123706 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44706923:44708371, ack 57626, win 1024, length 1448

15:53:01.123708 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44708371:44709819, ack 57626, win 1024, length 1448

15:53:01.123710 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44709819:44711267, ack 57626, win 1024, length 1448

15:53:01.123782 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44711267:44712715, ack 57626, win 1024, length 1448

15:53:01.123788 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44712715:44714163, ack 57626, win 1024, length 1448

15:53:01.123791 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44714163:44715611, ack 57626, win 1024, length 1448

15:53:01.123793 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44715611:44717059, ack 57626, win 1024, length 1448

15:53:01.123795 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44717059:44718507, ack 57626, win 1024, length 1448

15:53:01.123870 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44718507:44719955, ack 57626, win 1024, length 1448

15:53:01.123874 IP 223.132.11.12.3477 > iZ28wru16cpZ.65422: Flags [.], seq 44719955:44721403, ack 57626, win 1024, length 1448

声明：本文系作者投稿。

【End】