Linux怎么查看网络接口的丢包统计 Linux下ip -s link详解

Linux怎么查看网络接口的丢包统计 Linux下ip -s link详解

说到网络排查，丢包绝对是个让人头疼的经典问题。网络时好时坏，应用响应慢，很多时候根源都在这里。那么，在Linux系统里，我们怎么快速、准确地定位丢包发生在哪个环节呢？今天就来深入聊聊那个最直接、也最强大的工具：ip -s link。

ip -s link 输出里哪些字段代表丢包

直接运行 ip -s link show eth0，你会看到一大堆统计数字。别慌，真正需要你“火眼金睛”盯着的，其实就集中在接收（RX）和发送（TX）的几项关键指标里。它们可不是一个叫“丢包”的单一字段，而是分散在各个环节的“告密者”：

• RX: ... dropped：这是内核层面的主动丢弃。简单说，就是数据包已经到了Linux内核，但因为接收队列满了，或者系统处理不过来（比如软中断太忙、CPU负载过高），内核只好“忍痛割爱”。这通常指向系统性能瓶颈。
• RX: ... overrun：这个更底层，是网卡Ring Buffer溢出的标志。想象一下，网卡接收数据的速度（DMA写入）像瀑布一样快，而内核取走数据的速度像小溪流，结果就是缓冲区爆满，后来的包直接被硬件丢弃。这往往意味着流量突发超过了系统处理能力。
• RX: ... errors：物理层错误。比如CRC校验失败、帧长度不对等。这类丢包通常指向硬件问题，像网线接触不良、光模块光衰过大、端口协商失败等。
• TX: ... dropped：发送侧的丢弃。原因可能是发送队列满了，或者是内核的流量控制（qdisc）策略触发了丢包（比如限速）。不过要注意，通过tc命令配置的复杂丢包策略，不一定体现在这里。

记住一个原则：执行命令后，重点就看这四列数字——只要它们不是零，并且在持续增长，那就是丢包正在发生的铁证。

为什么 ifconfig 的 dropped 和 ip -s link 的 dropped 不一样

很多朋友习惯用老牌的 ifconfig 命令，但发现它显示的 RX dropped 和 ip -s link 里的对不上。这不是bug，而是统计口径不同。

ifconfig 报告的 dropped，更多反映的是内核在分配 sk_buff（套接字缓冲区）失败，或者应用层的socket接收缓冲区已满时的丢弃。而 ip -s link 的 dropped 统计更底层，属于网络设备子系统（netdev），涵盖了NAPI处理机制中的丢弃情况。可以说，ip -s link 的视角更贴近真实网卡的行为。

• 如果你看到 ifconfig 显示有丢包，但 ip -s link 的 dropped 却是0，那问题大概率出在应用层。可以检查一下socket缓冲区：netstat -s -u | grep "receive buffer errors"。
• 反过来，如果 ip -s link 的 overrun 很高，但 ifconfig 里没有对应字段——这很正常，因为 ifconfig 根本不统计Ring Buffer溢出这种硬件层面的丢包。

ethtool -S 和 ip -s link 的丢包字段怎么对应

想要更细粒度的洞察？ethtool -S eth0 命令能提供驱动级别的详细统计。但它的字段名因网卡驱动而异，和 ip -s link 的映射关系不是简单的一一对应：

• ip -s link 里的 overrun，大致对应 ethtool -S 输出中的 rx_over_errors 或 rx_fifo_errors。具体是哪个，得看驱动。比如ixgbe驱动常用 rx_fifo_errors，而e1000e驱动则用 rx_over_errors。
• ip -s link 里的 errors，通常是 ethtool -S 里各种物理层错误的总和，比如 rx_crc_errors、rx_frame_errors 等。
• ip -s link 里的 dropped，有时能对应到 ethtool -S 的 rx_missed_errors（部分驱动），但更可靠的方法是结合查看 /proc/net/softnet_stat 文件的第二列来验证。

所以，不必死磕字段名的完全匹配。更实用的方法是看趋势：在同一个时间点，反复执行几次 ip -s link，如果发现 overrun 或 dropped 的数值在跳动增长，那问题就在持续发生，这才是关键。

tc qdisc 丢包不会出现在 ip -s link 统计里

这一点至关重要，却最容易被忽略：由 tc（Traffic Control）工具配置的丢包策略，是完全绕开网卡统计体系的。也就是说，即使你的 ip -s link 所有字段都是完美的0，网络上依然可能因为TC规则在大量丢包。

• 怎么检查？ 运行 tc qdisc show dev eth0。仔细看输出里有没有 loss（丢包）、limit（队列限制）、rate（限速）、burst（突发）这类关键词。
• 典型“坑”：在测试环境里，为了模拟网络异常，可能会加上一条 tc qdisc add dev eth0 root netem loss 10%，结果上线时忘记清理，导致生产环境“无故”丢包。
• 如何确认影响？ 可以做个简单测试：用 hping3 -c 10 -S <目标IP> 发送10个SYN包，同时在同机用 tcpdump -i eth0 port 80 抓包。对比发出的包数和抓到的包数，就能直观看到TC规则是否在生效丢包。

因此，一个完整的丢包排查流程，第一步就应该是 tc qdisc show。因为它配置的丢包无声无息，却又常常是问题的元凶，可别让它成了漏网之鱼。