网络丢包是接口超时、响应变慢的幕后真凶；需用ip -s link查overrun（硬件丢包）、mtr定位丢包节点、iptables/ss/ss查协议栈丢包，并检查tc是否人为限速。
当线上服务突然出现接口超时、响应变慢或连接中断，而CPU、内存监控却一切正常时，网络丢包和高延迟往往就是幕后真凶——它不报警、不报错，只悄悄拖慢每个请求，让问题难以复现又难以定位。
快速确认本机是否在丢包
先排除本地网卡和内核收包环节的问题，执行：ip -s link show dev eth0（把eth0换成你实际的网卡名，如ens33或enp0s3）。
重点看 RX 行末尾的 dropped 和 overrun 两列：dropped 表示内核已取走数据但因内存不足或处理不过来而丢弃；overrun 表示网卡 Ring Buffer 溢出，【这是硬件级丢包的铁证】。
如果 overrun > 0，说明网卡收包速度远超内核处理能力，必须立即检查驱动版本、中断绑定或启用 RPS/RFS。
用 mtr 定位链路中哪一跳开始丢包
运行 mtr -n -c 60 -I example.com（-n 禁用 DNS 解析，-I 强制 ICMP，-c 60 发 60 个包）。
输出中重点关注 Loss% 列：从第一跳开始往下扫，找到第一个 Loss% 明显高于 0（比如 ≥3%）且后续跳数不再显著增长的节点——问题就卡在这跳设备上。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
注意：最后一跳（目标服务器）Loss% 高，大概率是对方负载高或防火墙限 ICMP；若第 3 跳起持续 15% 丢包，而第 4～8 跳 Loss% 不再上升，那第 3 跳的路由器或城域网出口就是瓶颈点。
检查内核协议栈各层是否主动丢包
方法一：查 netfilter 丢包
执行 iptables -t raw -L -v -n 2>/dev/null || echo "no raw table"，再查 iptables -t mangle -L POSTROUTING -v -n。任何 DROP 或 REJECT 规则的 packet 计数在增长，就说明是防火墙策略在丢包。
方法二：查 TCP 层重传与队列堆积
运行 ss -i state established '( dport = :80 or sport = :80 )' | head -10，观察 retrans 字段（如 retrans:5/42）：分子大于 0 且分母持续增大，说明链路存在不可靠丢包，触发了 TCP 重传机制。
方法三：查套接字接收队列溢出
执行 ss -lnt | awk '$2>100 {print $0}'，若 Recv-Q 长期 > 0（尤其 > 100），说明应用读取太慢，内核被迫丢弃新到的数据包——这时要查服务进程是否卡死、GC 暂停过长或业务逻辑阻塞。
验证是否存在人为限速或模拟丢包
第一步：检查 tc 流控规则
运行 tc qdisc show dev eth0。如果输出里含 netem 或 loss 关键字，例如 qdisc netem 800d: root refcnt 2 limit 1000 loss 10%，【说明丢包是人为配置的，不是故障而是测试残留】。
第二步：清除模拟丢包
执行 tc qdisc del dev eth0 root，立刻移除所有流控策略。再次运行 mtr 或 ip -s link，确认 dropped/overrun 值停止增长。
