网络层协议栈丢包原因分析
你在排查线上服务延迟时，是否经常遇到“ping不通”或者“请求超时”的情况？明明物理链路正常，交换机也没报警，数据包却像石沉大海。问题很可能出在网络层协议栈的丢包环节。这类问题不像硬件故障那么直观，但影响却不小，尤其在高并发场景下，轻微的丢包都可能导致连接重传、响应变慢甚至服务雪崩。
协议栈处理能力不足
服务器收到数据包后，需要通过网络层协议栈进行解析和转发。如果短时间内涌入大量报文，协议栈来不及处理，内核中的接收队列就会溢出。Linux 系统中，这个队列由 net.core.netdev_max_backlog 控制。一旦超出限制，新到的数据包就会被直接丢弃。
比如某次大促期间，电商后台突然收不到订单推送，抓包发现对方确实在发，但本机 tcpdump 就捕获不到。查看系统日志 dmesg，就能看到类似 netdev_max_backlog dropped packet 的提示，这就是典型的队列溢出。
路由表配置错误或缺失
数据包到达主机后，协议栈会查询路由表决定下一跳。如果目标地址不在任何路由条目中，系统无法确定如何转发，只能丢弃。这种情况常见于多网卡服务器，比如新增了一块网卡但没配默认路由，或者静态路由写错了掩码。
用 ip route show 检查当前路由规则，再结合 ip route get <目标IP> 可以模拟路径查找过程。若返回 “Network is unreachable”，基本可以锁定是路由问题。
防火墙规则主动拦截
iptables 或 nftables 配置不当也会导致“丢包”。虽然严格来说这不是“丢”，而是策略性拒绝，但在表现上和丢包无异。例如设置了 INPUT 链 DROP 所有非白名单来源，但忘了放行必要的监控探针，结果健康检查频繁失败。
排查时可以用 iptables -L -n -v 查看各链的匹配计数，如果某条规则的包计数持续上升，说明流量正被它拦截。更精细的做法是启用日志规则：
-A INPUT -s 192.168.10.50 -j LOG --log-prefix "DROPPED_PKT: "
-A INPUT -s 192.168.10.50 -j DROP这样在 /var/log/messages 或 journald 中就能看到具体哪些包被拦了。
IP 分片重组失败
当数据包大小超过 MTU，会被分片传输。接收端需在协议栈中完成重组。如果部分分片丢失，或者重组定时器超时（Linux 默认 30 秒），整个原始报文都会被丢弃。这种问题在跨公网传输大包时尤为明显，尤其是经过多个不一致 MTU 的网络段。
可通过 sysctl net.ipv4.ipfrag_high_thresh 查看重组队列上限，过低可能导致缓存不足。同时，使用 tcpdump -i any 'ip[6] & 0x20 != 0' 能抓取带分片标志的包，辅助判断是否涉及分片传输。
内存资源紧张
协议栈处理包需要分配 skb_buffer（套接字缓冲区）。当系统内存紧张，特别是低端内存（ZONE_DMA）耗尽时，即使只是接收一个 ICMP 包，也可能因无法分配 buffer 而丢弃。这种场景多见于长时间运行、未调优的老服务器。
通过 cat /proc/net/sockstat 可查看当前 socket 内存使用情况。若 mem 列数值偏高，或 pages 接近上限，就可能是瓶颈所在。配合 vm.drop_caches=1 临时释放页缓存，有时能缓解症状。
中断合并与 CPU 绑定问题
现代网卡支持中断合并（Interrupt Coalescing），把多个包的中断合并成一次处理，提升效率。但设置过激会导致延迟升高，小包堆积。反过来，若关闭合并，CPU 又可能因频繁中断而过载，顾不上协议栈处理。
用 ethtool -c eth0 查看当前中断参数，top 观察软中断（si）占比。若软中断长期高于 20%，可尝试启用 RPS（Receive Packet Steering）将负载分摊到多个 CPU 核心：
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus这表示让前四个逻辑核参与处理该队列的软中断。
ICMP 不可达消息误导排查
有时候你用 ping 测试连通性，收到 “Destination Unreachable” 报文，误以为是路径丢包。实际上这是网络层按规范返回的反馈，并非丢包。真正的问题可能在中间路由器上，比如 ACL 拒绝、下一跳失效等。这时候要区分“主动拒绝”和“静默丢弃”——前者有回执，后者则完全无响应。
结合 traceroute 使用，观察在哪一跳开始出现超时或拒绝，能更快定位故障点。