网卡问题处理(该如何缓解网卡的普遍问题)
网卡问题处理(该如何缓解网卡的普遍问题)MSS(Maximum Segment Size,最大报文长度),是TCP协议定义的一个选项,MSS选项用于在TCP连接建立时,收发双方协商通信时每一个报文段所能承载的最大数据长度。[root@centos ~]# netstat -iKernel Interface tableIface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flgeth0 1500 318145 0 0 0 492216 0 0 0 BMRUlo 65536 5334 0 0 0 5334 0 0 0 LRUMSSMTU最大传输单元(Maximum Transmission Unit,mtu)用来通知对方所能接受数据服务单元的最大尺寸,说明发送方能够接受的有效载荷大小。是包或帧的最大长度,一般以字节记。在以太网通信中,MTU规定了经过网络层封
作者 | 阿文
责编 | 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】