内网丢包和延迟过高多为时好时坏的瓶颈问题，需分层定位；先区分真丢包与高延迟伪装，再逐层排查物理链路、内核协议栈及应用接收。
内网丢包和延迟过高，往往不是“网络不通”，而是“时好时坏”“只在高峰期出问题”，这类现象背后通常有明确的链路或系统瓶颈。排查关键不在于盲目抓包，而在于分层定位、逐段验证——从物理链路到内核协议栈，再到应用接收，每一层都可能成为“丢包黑点”或“延迟放大器”。
一、先确认是不是真丢包，还是延迟伪装成丢包
很多“丢包”其实是高延迟导致超时，被误判为丢包。比如 curl 超时、TCP 连接 hang 住、服务调用失败等，未必是包丢了，可能是处理慢了。
- 用 ping -c 10 目标IP 看基础连通性与 RTT 波动：如果丢包率 0%，但最大延迟 >100ms（内网一般应
- 用 hping3 -c 10 -S -p 22 目标IP（走 TCP SYN）绕过 ICMP 屏蔽，更贴近真实业务流量行为
- 对比 curl -w "@format.txt" -o /dev/null -s http://内网服务 中的 time_connect 和 time_starttransfer：若前者稳定、后者大幅波动，问题大概率在服务端处理，而非网络
二、查本机网卡与驱动层是否在 silently 丢包
真正的丢包，常发生在数据刚进网卡还没进协议栈时，这时 tcpdump 抓不到，但 ip -s link 会留下痕迹。
- 运行 ip -s link show dev eth0（把 eth0 换成你实际网卡名），重点看 RX 部分：
dropped：软中断来不及处理、netdev_max_backlog 溢出
overrun：Ring Buffer 满了，DMA 写不进内存（驱动/硬件瓶颈）
errors：物理层异常（双工不匹配、线缆质量差、光衰高） - 用 ethtool eth0 检查：
Speed/Duplex 是否为 “10000Mb/s Full”（非 Auto/Negotiation 失败状态）
Link detected: yes（确保物理连接正常）
如果出现 “Half Duplex”，立刻查交换机端口配置——这是内网丢包最常见却最易忽略的原因之一
三、定位丢包发生在哪一段路径上
内网虽短，但中间可能经过接入交换机、汇聚交换机、防火墙、VLAN 网关等节点。单靠 ping 不足以暴露中间跳点的问题。
- 用 mtr -n -z -c 50 内网目标IP（-n 禁 DNS、-z 禁花哨字符、-c 50 多周期统计）
重点关注每跳的 Loss%：如果只有最后一跳丢包，大概率是目标机问题；如果某中间跳持续 5%+ 丢包且后续跳 Loss% 不再上升，问题就在那一跳设备（比如某台老旧的三层交换机限速或 buffer 不足） - 对比双向路径：
A → B 丢包，但 B → A 正常？说明问题在 A 的发包路径（如 A 的 TX 队列满、QoS 限速）或 B 的接收侧（如 B 的 netdev_max_backlog 小）
四、检查内核协议栈入口是否“堵车”
当突发流量打进来，软中断（ksoftirqd）处理不过来，就会在 netif_receive_skb 前丢弃 skb——这个阶段丢包不会进 TCP 层，所以 ss、netstat 看不到重传，tcpdump 也抓不到。
- 查当前 backlog 设置：sysctl net.core.netdev_max_backlog（默认常为 1000）
若业务是短连接高并发（如 API 网关、Redis 客户端密集访问），建议调至 3000–5000，配合增大 Ring Buffer - 观察软中断负载：cat /proc/softirqs | grep NET_RX
多次执行看数值增长是否远高于其他项；再结合 top -H 查看 ksoftirqd/*/CPUx 占用是否持续 >80% - 临时验证：增大 backlog 后，用 watch -n1 'grep dropped /proc/net/dev' 观察 rx_dropped 是否停止增长
