怎么样查电脑网络掉包数据(网络丢包——硬件网卡丢包)
网络丢包中常见的一种丢包原因，硬件网卡丢包
RingBuffer溢出
如图所示，物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区RingBuffer中，再由中断处理程序触发Softirq从中消费，RingBuffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，RingBuffer很快会被填满，新来的数据包将被丢弃；
查看：
通过ethtool或/proc/net/dev可以查看因RingBuffer满而丢弃的包统计，在统计项中以fifo标识：
$ethtool-Seth0|greprx_fiforx_fifo_errors:0$cat/proc/net/devInter-|Receive|Transmitface|bytespacketserrsdropfifoframecompressedmulticast|bytespacketserrsdropfifocollscarriercompressedeth0:1725338668073142839525880000002441820221487954501805741657801805000000
#查看eth0网卡RingBuffer最大值和当前设置
$ethtool-geth0
解决方案：修改网卡eth0接收与发送硬件缓存区大小
$ethtool-Geth0rx4096tx4096
网卡端口协商丢包
1.查看网卡丢包统计：ethtool-Seth1/eth0
2.查看网卡配置状态：ethtooleth1/eth0
主要查看网卡和上游网络设备协商速率和模式是否符合预期；
解决方案：
1重新自协商：ethtool-reth1/eth0;
2如果上游不支持自协商，可以强制设置端口速率：
ethtool-seth1speed1000duplexfullautonegoff
网卡流控丢包
1.查看流控统计：
ethtool-Seth1|grepcontrol
rx_flow_control_xon是在网卡的RXBuffer满或其他网卡内部的资源受限时，给交换机端口发送的开启流控的pause帧计数。对应的，tx_flow_control_xoff是在资源可用之后发送的关闭流控的pause帧计数。
2.查看网络流控配置：ethtool-aeth1
解决方案：关闭网卡流控
ethtool-Aethxautonegoff//自协商关闭ethtool-Aethxtxoff//发送模块关闭ethtool-Aethxrxoff//接收模块关闭
报文mac地址丢包
一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据，如果报文的目的mac地址不是对端的接口的mac地址，一般都会丢包，一般这种情况很有可能是源端设置静态arp表项或者动态学习的arp表项没有及时更新，但目的端mac地址已发生变化（换了网卡），没有更新通知到源端（比如更新报文被丢失，中间交换机异常等情况）；
查看：
1.目的端抓包，tcpdump可以开启混杂模式，可以抓到对应的报文，然后查看mac地址；
2.源端查看arp表或者抓包（上一跳设备），看发送的mac地址是否和下一跳目的端的mac地址一致；
解决方案：
1.刷新arp表然后发包触发arp重新学习（可能影响其他报文，增加延时，需要小心操作）；
2.可以在源端手动设置正确的静态的arp表项；
其他网卡异常丢包
这类异常比少见，但如果都不是上面哪些情况，但网卡统计里面任然有丢包计数，可以试着排查一下：
网卡firmware版本:
排查一下网卡phy芯片firmware是不是有bug，安装的版本是不是符合预期，查看ethtool-ieth1:
和厂家提case询问是不是已知问题，有没有新版本等；
网线接触不良：
如果网卡统计里面存在crcerror计数增长，很可能是网线接触不良，可以通知网管排查一下：
ethtool-Seth0
解决方案：一般试着重新插拔一下网线，或者换一根网线，排查插口是否符合端口规格等;
报文长度丢包
网卡有接收正确报文长度范围，一般正常以太网报文长度范围：64-1518，发送端正常情况会填充或者分片来适配，偶尔会发生一些异常情况导致发送报文不正常丢包；
查看：
ethtool-Seth1|greplength_errors
解决方案：
1调整接口MTU配置，是否开启支持以太网巨帧；
2发送端开启PATHMTU进行合理分片；
简单总结一下网卡丢包：
网卡驱动丢包
查看：ifconfigeth1/eth0等接口
1.RXerrors:表示总的收包的错误数量，还包括too-long-frames错误，RingBuffer溢出错误，crc校验错误，帧同步错误，fifooverruns以及missedpkg等等。
2.RXdropped:表示数据包已经进入了RingBuffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
3.RXoverruns:表示了fifo的overruns，这是由于RingBuffer(akaDriverQueue)传输的IO大于kernel能够处理的IO导致的，而RingBuffer则是指在发起IRQ请求之前的那块buffer。很明显，overruns的增大意味着数据包没到RingBuffer就被网卡物理层给丢弃了，而CPU无法即使的处理中断是造成RingBuffer满的原因之一，上面那台有问题的机器就是因为interruprs分布的不均匀(都压在core0)，没有做affinity而造成的丢包。
4.RXframe:表示misaligned的frames。
5.对于TX的来说，出现上述counter增大的原因主要包括abortedtransmission,errorsduetocarrirer,fifoerror,heartbeaterros以及windownerror，而collisions则表示由于CSMA/CD造成的传输中断。