电脑网卡有问题怎么解决(网卡出现问题怎么解决)

作者 | 阿文

责编 | 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】

(0)

相关推荐