首先使用ip -s link show
Linux网络接口丢包问题，说白了就是数据包在网卡层面或者驱动程序处理过程中“掉队了”，没有被正确接收或发送出去。要定位这类问题，我们通常会从
ethtool的统计数据入手，因为它能提供最接近硬件层面的详细信息，配合
ip -s link和
netstat -s，基本就能摸清个大概。
解决方案
要检测Linux网络接口的丢包问题，最直接且有效的方法就是利用
ethtool工具来查看网卡（NIC）的硬件统计数据。这些数据能告诉你数据包是在哪里、以何种原因丢失的。
首先，我们可以用
ip -s link show快速看一眼接口的概况，它会显示接收（RX）和发送（TX）的错误和丢包数量。比如：
ip -s link show eth0
输出中会有一个
RX errors和
TX errors的统计，以及
dropped的数量。这只是一个宏观的指标，具体是什么原因导致的丢包，就需要
ethtool来深挖了。
接着，我们祭出
ethtool -S。这个命令会显示网卡驱动和硬件层面报告的详细统计信息。这些统计项通常非常多，但其中有几个是我们需要重点关注的：
ethtool -S eth0
你可能会看到类似
rx_dropped、
tx_dropped、
rx_errors、
tx_errors、
rx_fifo_errors、
tx_fifo_errors、
rx_missed_errors等指标。这些才是真正能告诉你网卡是不是在丢包，以及为什么丢包的关键。如果这些计数器持续增长，那基本就能确定网络接口存在丢包问题了。
为什么我的网络接口会丢包？常见原因有哪些？
说起这个丢包，真是个让人头疼的问题，原因可能五花八门。我个人在实际工作中遇到过不少情况，总结下来，大致有这么几类：
- 硬件本身的问题： 这最直接，网线是不是坏了？网卡是不是老化了或者本身就有缺陷？交换机端口是不是有问题？有时候，一个看似不起眼的物理连接问题，就能导致大量的丢包。比如，网线水晶头没压好，或者线缆质量太差，都可能导致CRC错误，进而引发丢包。
-
驱动程序或固件问题： 这是一个比较隐蔽的坑。网卡驱动可能版本太老，或者新版本有bug，导致它无法正确处理数据包。有时，网卡固件（firmware）本身也可能存在缺陷。我遇到过一次，升级了内核后，旧的网卡驱动就不兼容了，表现就是大量的
rx_dropped
。 -
网卡缓冲区（Ring Buffer）溢出： 这是
ethtool
统计中最常揭示的问题之一。当网络流量过大，或者CPU处理不过来时，网卡接收数据包的速度超过了内核从缓冲区取走数据的速度，导致网卡内部的环形缓冲区满了，新来的数据包就只能被丢弃。rx_fifo_errors
和rx_missed_errors
通常就指向这个问题。发送端也可能出现类似情况，但接收端更为常见。 - CPU瓶颈或中断处理不及时： 即使网卡缓冲区没满，如果CPU忙于其他任务，或者中断处理优先级不高，无法及时响应网卡的中断请求，数据包也可能在进入内核前就被丢弃。这在多核CPU上，可能还涉及到中断亲和性（IRQ affinity）的配置问题。
-
网络拥塞或上层协议问题： 虽然
ethtool
主要反映网卡本地的丢包，但外部网络拥塞也可能间接导致本地丢包。比如，TCP窗口太小，或者应用层处理速度慢，导致TCP/IP协议栈在接收到数据后主动丢弃，或者不发送ACK导致发送端重传，这在netstat -s
里可能看得更清楚。 -
MTU不匹配： 路径MTU发现（PMTUD）失败时，可能会导致IP分片问题或数据包被路径中的路由器丢弃，虽然不直接体现在网卡
rx_dropped
上，但确实是网络丢包的一种形式。
ethtool的统计数据怎么解读，哪些指标最关键？
面对
ethtool -S输出的一大堆数字，刚开始看确实有点懵。但只要抓住几个核心指标，就能很快定位问题方向。
-
rx_dropped
和tx_dropped
： 这两个是“大头兵”，直接告诉你网卡在接收或发送数据包时，有多少个包被“扔掉了”。如果rx_dropped
持续增长，那你的接收端肯定有问题。tx_dropped
同理，意味着发送端出了状况。它们是判断是否丢包最直接的证据。 -
rx_errors
和tx_errors
： 这俩是总的错误计数。它们通常是其他更具体错误（比如CRC错误、帧错误、FIFO错误等）的汇总。单独看意义不大，但如果它们很高，就得去细看具体的错误类型了。 -
rx_fifo_errors
和tx_fifo_errors
： 这两个是诊断缓冲区溢出的“金指标”。rx_fifo_errors
飙高，几乎就板上钉钉是网卡接收环形缓冲区满了，来不及处理。这通常需要你考虑增大环形缓冲区的大小（用ethtool -G
命令），或者优化CPU对中断的处理能力。 -
rx_missed_errors
： 这个指标也和接收缓冲区有关。它表示网卡在没有足够资源（比如接收缓冲区满，或者CPU来不及服务）的情况下，错过了多少个数据包。和rx_fifo_errors
一样，都是指向接收端瓶颈的重要信号。 -
collisions
： 在全双工模式下，这个通常是0，但在半双工网络中（现在很少见了），它表示以太网冲突的数量。如果这个值很高，可能意味着网络环境有问题，或者网卡工作在错误的模式下。 -
其他诸如
rx_crc_errors
、rx_frame_errors
： 这些通常指向物理层或数据链路层的错误，可能是网线质量差、接口故障、或者双工模式不匹配等问题。
解读的重点是： 任何非零且持续增长的计数器都值得警惕。特别是
rx_dropped、
rx_fifo_errors和
rx_missed_errors，它们是排查接收端性能瓶颈和丢包的重中之重。当你发现这些计数器在增长时，下一步就是考虑增大网卡环形缓冲区（
ethtool -G），或者检查CPU负载和中断处理情况。
除了ethtool，还有哪些工具可以辅助诊断网络丢包？
当然了，光有
ethtool肯定是不够的，诊断网络问题是个系统工程，需要多工具协同作战，才能把问题看得更透彻。
-
ip -s link
： 之前提过，这是快速查看接口统计的利器。虽然不如ethtool -S
详细，但它简洁明了，能快速告诉你RX errors
和TX errors
以及dropped
的总数，作为初步判断非常方便。 -
netstat -s
： 这个命令能提供整个协议栈的统计信息，包括TCP、UDP、IP等各层的错误和丢包情况。比如，在UDP部分，你可能会看到InDiscards
或InErrors
。如果ethtool
显示网卡层面丢包不多，但netstat -s
显示高层的InDiscards
很多，那就说明问题可能出在内核协议栈或者应用程序处理速度上，而不是网卡本身。 -
dmesg
或journalctl -k
： 内核日志是排查驱动程序和硬件问题的宝藏。很多时候，当网卡驱动出现问题，或者环形缓冲区溢出达到某个阈值时，内核都会在日志中打印警告或错误信息。比如，你可能会看到“ring buffer full”或者“firmware bug”之类的提示。 -
tcpdump
或wireshark
： 这两个工具是抓包分析的利器。它们不能直接告诉你网卡“丢了”多少包，但可以帮助你确认数据包是否到达了网络接口，以及数据包的内容是否正确。如果tcpdump
在接口上看不到应该接收到的数据包，而ethtool
又显示rx_dropped
，那就可以基本确定问题出在网卡或其驱动层面了。反之，如果能抓到包，但应用程序没收到，那问题可能在上层。 -
sar -n DEV
或nload
/iftop
： 这些是流量监控工具。sar -n DEV
可以历史性地记录接口的流量、错误和丢包情况，帮助你观察趋势。nload
和iftop
则提供实时的流量视图。当丢包和高流量同时出现时，这通常指向带宽饱和或缓冲区不足。 -
perf
或oprofile
： 这些是更高级的性能分析工具，主要用来分析CPU使用情况。如果怀疑CPU是瓶颈，导致无法及时处理网卡中断，这些工具可以帮助你找出是哪个进程或内核函数占用了大量CPU时间，从而影响了网络数据包的处理。
总之，诊断网络丢包是一个迭代的过程。从宏观的
ip -s link开始，深入到
ethtool -S查看硬件细节，再结合
netstat -s分析协议栈，最后用
dmesg和抓包工具来验证和定位，往往能找到问题的症结所在。
