電腦網絡卡有問題怎麼解決（網絡卡出現問題怎麼解決）

2023-03-28 09:27:53

作者 | 阿文

責編 | 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】