前言

前面两篇文章分享了Linux网络收发包流程和常用的网络问题定位工具，本期分享一个实际的测试案例，结合前面两篇的理论基础，逐步分析丢包的原因和解决办法。

测试环境

使用某国产CPU平台的两台设备，用iperf3工具进行udp报文测试。

设备A配置网口IP为192.168.1.12。

设备B配置网口IP为192.168.1.100。

设备A作为server端，从默认端口5201监听报文。

设备B作为client端，从默认端口发送udp报文，设置带宽1000M，测试时间5S。

测试现象

从设备A端监听到有丢包，且传输速率也只有六百多兆，没有达到设定的1000M水平：

定位过程

用ifconfig查询网口统计，看是接收出错还是发送出错。

设备B发送端，可以看到发送没有错误统计：

设备A接收端，可以看到有rx error和overrun：

以下是从网上其他文章中看到的接收端错误解释，我上一篇文章中也有说明，由于我不是做做软件的，不懂看内核代码，具体这些统计的含义，建议有条件看代码的大佬以代码为准，我这里只是拾人牙慧，我个人觉得上一篇文章开头中提到的那篇雄文对于细节的理解应该是比较到位的：

(1) RX errors

表示总的收包的错误数量，这包括 too-long-frames 错误，crc 校验错误，帧同步错误以及 missed pkg 等等。

(2) RX dropped

表示数据包已经进入了Ring Buffer，但是由于内核处理不过来等系统原因，导致在数据从网卡拷贝到内存的过程中被丢弃。（这句话描述有误，ring buffer不是存数据包的，存的是描述符，描述符指向了socket buffer的位置，可以理解为数据DMA到socket buffer时丢了，可能是当前的数据内容大于socket buffer的容量）。

(3) RX overruns

overruns意味着数据包没到 ring buffer就被网卡物理层给丢弃了。当驱动处理速度跟不上网卡收包速度时，驱动来不及分配缓冲区（这句话同样有误，数据包不会到ring buffer），NIC 接收到的数据包无法及时写到socket buffer，就会产生堆积。当NIC内部缓冲区写满后，就会丢弃部分数据，引起丢包。这部分丢包为 rx_fifo_errors，在 /proc/net/dev 中体现为 fifo 字段增长，在 ifconfig 中体现为 overruns 指标增长。