Linux怎么查看网络接口的丢包详情 Linux下ethtool -S统计详解

排查网络丢包时，ethtool -S 命令输出的统计信息是定位物理层和驱动层问题的关键。但面对几十个甚至上百个计数器，哪些字段真正反映了丢包？它们和协议栈统计的丢包又是什么关系？今天我们就来拆解清楚。

ethtool -S 输出里哪些字段代表丢包

真正需要关注的物理层丢包指标，通常是 rx_missed_errors、rx_dropped、rx_fifo_errors 和 tx_aborted_errors 这几项。需要注意的是，并非所有网卡驱动都会输出全部字段，但只要这些值非零且在持续增长，基本就能断定丢包发生在网卡硬件或驱动层。

一个常见的误区是只盯着 rx_packets 和 tx_packets 的总数看，这两个计数器只记录了成功收发的包数，并不包含丢弃的部分。而 rx_errors 这类汇总项又过于笼统，容易掩盖具体原因——所以必须拆开看子项。

• rx_missed_errors：当网卡的接收环缓冲区（ring buffer）已满，新到的数据包来不及被内核取走就会被覆盖丢弃。这通常是中断响应延迟或CPU过载的典型信号。
• rx_dropped：由网卡驱动主动丢弃的包。原因可能是帧校验失败、帧长度异常，也可能是系统启用了反向路径过滤（rp_filter）导致验证失败。
• rx_fifo_errors：数据从网卡通过DMA写入内存中的环缓冲区时发生FIFO溢出。在高吞吐的UDP场景下较为常见，且常与 rx_missed_errors 成对出现。
• tx_aborted_errors：发送过程中因载波丢失、冲突次数超限等问题而中止。一般指向物理链路问题，比如网线接触不良或双工模式不匹配。

netstat -s -u 和 ethtool -S 的丢包统计差异

这两组数据统计的层级完全不同。netstat -s -u 显示的是协议栈层面的丢包，例如“Udp: 12 packets to unknown port received”或 UdpInErrors，这些是数据包到达IP层或Socket层后被丢弃的。而 ethtool -S eth0 统计的是网卡硬件和驱动层的丢包。两者不能直接相加或对比。

一个高效的排查路径通常是：先用 ping 确认存在丢包现象 → 接着查 ethtool -S 看网卡级计数器是否有增长 → 如果这里为0，再转向 netstat -s -u 和 /proc/net/snmp 查看 UdpInErrors 等协议栈统计 → 最后检查应用层Socket的接收缓冲区是否溢出（可通过 ss -i 查看 rcv_space 和 rcv_ssthresh）。

• UdpInErrors 值高：通常意味着Socket接收缓冲区已满（可能因 net.core.rmem_max 设置过小），或者应用程序读取数据的速度太慢。
• rx_missed_errors 高但 UdpInErrors 低：这表明丢包卡在驱动层的环缓冲区到内核协议栈之间。需要检查并调整 net.core.netdev_max_backlog 参数，或者尝试关闭IRQ负载均衡。
• 注意驱动差异：部分Realtek网卡的驱动会将校验和错误（checksum error）也计入 rx_dropped。此时需要配合 ethtool -k eth0 命令，检查接收卸载（rx offload）功能是否开启。

为什么 ethtool -S 的值有时不更新或显示 0

首先，不是所有网卡驱动都实现了完整的统计功能。这在虚拟网卡（如 veth、macvlan）、部分USB转以太网设备或老旧芯片（如某些RTL8139变种）上尤其常见。执行 ethtool -S 可能只输出几个基础字段，甚至直接报错“No data a vailable”。

其次，这些统计值通常是自驱动加载以来的累计值。网卡刚启动（up）时，或者执行过 ifconfig eth0 down && up 操作后，计数器并不会自动重置。虽然有些驱动在执行软复位（ethtool -r eth0）后会清零，但不同厂商的实现并不一致，不能作为通用依赖。

• 确认驱动支持：运行 ethtool -i eth0 确认驱动名称和版本，然后查阅对应厂商的文档，确认是否支持你关心的统计项。
• 使用备用命令：如果 ethtool -S 输出过于简单（只有 rx_packets/tx_packets），可以换用 ip -s link show eth0 命令，它能补充显示 dropped 和 overruns 等关键信息。
• 注意权限：ethtool -S 命令需要root权限才能获取完整统计，普通用户执行可能会静默忽略部分字段。

调整 ring buffer 大小前先确认它是否真瓶颈

遇到丢包就增大接收环缓冲区（ethtool -G eth0 rx 4096）是一种常见的“条件反射”，但现实中，很多丢包的根源并非缓冲区大小，而是中断延迟、CPU核心绑定不合理，或者软中断（softirq）处理不过来。

在动手调整之前，建议先做两步验证：首先，用 watch -n 1 'cat /proc/interrupts | grep eth0' 观察对应网卡中断请求（IRQ）的计数是否均匀增长。然后，使用 perf top -e irq:softirq_entry --call-graph dwarf 查看 net_rx_action 函数的CPU占用比例。如果这个比例长期高于70%，才说明软中断处理确实是瓶颈，此时调大ring buffer才有实际意义。

• 查看与设置：使用 ethtool -g eth0 查看当前ring buffer大小，默认值通常是256或512。注意最大值受驱动和硬件限制（例如Intel e1000系列最大支持4096）。
• 生效与持久化：ethtool -G 的修改会立即生效，但重启网络或系统后会恢复默认。需要将配置写入网络脚本或创建systemd服务来实现持久化。
• 避免盲目调大：将缓冲区设置得过大（比如8192）可能会增加内存占用和缓存未命中率，反而降低吞吐性能。对于多队列网卡，还需要同步调整队列数量（ethtool -L）。

总结来说，数据包从网卡寄存器、驱动队列、协议栈输入队列到Socket缓冲区的整个路径上，每一层都可能成为丢包点。排查时最容易忽略的一步，就是确认你手头网卡型号对应的驱动，对 ethtool -S 中各个字段的定义是否与通用理解一致——同一个字段名，在Intel的i40e驱动和Realtek的r8169驱动下，其统计语义可能完全不同。