数据在Internet上是以数据包为单位传输的，单位为字节，数据在网络上传输，受网络设备，网络质量等原因的影响，使得接收到的数据少于发送出去的数据，造成丢包。
数据包接收、发送原理
发送数据包：
1.应用程序的数据包，在TCP层增加TCP报文头，形成可传输的数据包。
2.在IP层增加IP报头，形成IP报文。
3.经过数据网卡驱动程序将IP包再添加14字节的MAC头，构成frame（暂⽆CRC），frame（暂⽆CRC）中含有发送端和接收端的MAC地址。
4.驱动程序将frame（暂⽆CRC）拷贝到网卡的缓冲区，由网卡处理。
5.⽹卡为frame（暂⽆CRC）添加头部同步信息和CRC校验，将其封装为可以发送的packet，然后再发送到网线上，这样说就完成了一个IP报文的发送了，所有连接到这个网线上的网卡都可以看到该packet。
1.⽹卡收到⽹线上的packet，⾸先检查packet的CRC校验，保证完整性，然后将packet头去掉，得到frame。（⽹卡会检查MAC包内的⽬的MAC地址是否和本⽹卡的MAC地址⼀样，不⼀样则会丢弃。）
2.⽹卡将frame拷贝到预分配的ring buffer缓冲。
3.⽹卡驱动程序通知内核处理，经过TCP/IP协议栈层层解码处理。
4.应⽤程序从socket buffer 中读取数据。
网络丢包可分为以下6种情况
1.硬件网卡丢包
2.网卡驱动丢包
3.以太网链路层丢包
4.网络IP层丢包
5.传输层UDP/TCP丢包
6.应用socket丢包
硬件网卡丢包
ring Buffer溢出
物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃；
通过ethtool或/proc/net/dev可以查看因Ring Buffer满而丢弃的包统计，在统计项中以fifo标识：
ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
$ cat /proc/net/dev
Inter-|Receive | Transmitface |bytes packets errs drop fifo frame compressed
multicast|bytes packets errs drop fifo colls carrier compressed
eth0: 17253386680731 42839525880 0 0 0 0 0 244182022 14879545018057 41657801805 0 0 0 0 0 0查看eth0网卡Ring Buffer最大值和当前设置
ethtool -g eth0解决方案：修改网卡eth0接收与发送硬件缓存区大小
ethtool -G eth0 rx 4096 tx 4096网卡端口协商丢包
查看网卡丢包统计：ethtool -S eth1/eth0
查看网卡配置状态：ethtool eth1/eth0
主要查看网卡和上游网络设备协商速率和模式是否符合预期；
解决方案：
1 重新自协商： ethtool -r eth1/eth0;
2 如果上游不支持自协商，可以强制设置端口速率：
ethtool -s eth1 speed 1000 duplex full autoneg off网卡流控丢包
1. 查看流控统计：
ethtool -S eth1 | grep control
rx_flow_control_xon是在网卡的RX Buffer满或其他网卡内部的资源受限时，给交换机端口发送的开启流控的pause帧计数。对应的，tx_flow_control_xoff是在资源可用之后发送的关闭流控的pause帧计数。
查看网络流控配置：ethtool -a eth1
解决方案：关闭网卡流控
ethtool -A ethx autoneg off //自协商关闭
ethtool -A ethx tx off //发送模块关闭
ethtool -A ethx rx off //接收模块关闭报文mac地址丢包
一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据，如果报文的目的mac地址不是对端的接口的mac地址，一般都会丢包，一般这种情况很有可能是源端设置静态arp表项或者动态学习的arp表项没有及时更新，但目的端mac地址已发生变化（换了网卡），没有更新通知到源端（比如更新报文被丢失，中间交换机异常等情况）；
查看：
1.目的端抓包，tcpdump可以开启混杂模式，可以抓到对应的报文，然后查看mac地址；
2.源端查看arp表或者抓包（上一跳设备），看发送的mac地址是否和下一跳目的端的mac地址一致；
解决方案：
1.刷新arp表然后发包触发arp重新学习（可能影响其他报文，增加延时，需要小心操作）；
2.可以在源端手动设置正确的静态的arp表项；
网线接触不良：
如果网卡统计里面存在crc error 计数增长，很可能是网线接触不良，可以排查一下：
ethtool -S eth0
解决方案：一般试着重新插拔一下网线，或者换一根网线，排查插口是否符合端口规格等;
报文长度丢包
网卡有接收正确报文长度范围，一般正常以太网报文长度范围：64-1518，发送端正常情况会填充或者分片来适配，偶尔会发生一些异常情况导致发送报文不正常丢包；
查看：
ethtool -S eth1|grep length_errors
解决方案：
1 调整接口MTU配置，是否开启支持以太网巨帧；
2 发送端开启PATH MTU进行合理分片；
