ip -s link的packet drops与ss -tm的sock_drop差异及成因咨询

嘿，我来帮你理清楚这两个丢包指标的区别和背后的原因，解决你遇到的“接口丢包为0但套接字有丢包计数”的困惑~

一、本质差异：统计的是不同阶段的丢包 #

这两个指标根本不是一回事，统计的是网络数据包在不同处理阶段的丢弃情况：

• ip -s link的dropped：属于网络接口/链路层的统计。数据包还没进入TCP协议栈的上层处理流程，就在网卡驱动或者链路层被丢弃了，才会被记在这里。简单说，就是“数据包根本没摸到TCP层的门槛”。
• ss -tm的sock_drop（也就是skmem里的d字段）：属于TCP套接字层面的统计。数据包已经成功通过链路层、IP层，到达了TCP层，但因为套接字相关的问题没法被正常处理，最终被丢弃，才会触发这个计数。也就是“数据包到了TCP层，但没被应用接住”。

二、各自的常见成因 #

1. ip -s link中dropped的可能原因 #

• 网卡硬件或驱动出问题：比如网卡本身故障，或者驱动版本不兼容，导致接收的帧校验失败直接丢弃
• 网卡接收队列（ring buffer）不足：突发大流量过来时，网卡的硬件接收队列来不及把数据包传给内核，只能丢包
• 链路层故障：比如网线松动、交换机端口故障，导致传输的帧损坏，被链路层丢弃
• 内核参数配置不合理：比如net.core.rx_queue_len设置过小，内核的软件接收队列没法及时处理网卡传过来的包

2. sock_drop的可能原因 #

• 应用处理速度跟不上：这是最常见的情况！应用程序没及时读取套接字的接收缓冲区（sk_rcvbuf），导致缓冲区被占满，新到达的TCP报文段没法存入，只能被丢弃
• TCP连接状态异常：比如连接已经被应用关闭（调用了close()），但对端还在发数据；或者连接超时后，迟来的报文到达，会被TCP层丢弃并计入这个指标
• 内核TCP协议栈异常：比如某些内核参数配置冲突，导致TCP层无法正确处理接收到的报文
• 上层拦截规则：比如某些防火墙模块或者自定义内核模块，在TCP层拦截了数据包，这种情况下不会被统计到接口层面的丢包，而是计入sock_drop

三、对你遇到的情况的解释 #

你看到ip -s link的dropped为0，但sock_drop有数值，说明所有数据包都成功通过了链路层和IP层，到达了TCP层，但因为套接字层面的原因被丢弃了——大概率是你的应用程序处理TCP数据的速度太慢，导致套接字接收缓冲区溢出了。

备注：内容来源于stack exchange，提问作者PeopleMoutainPeopleSea