mtr是排查Linux网络延迟的首要工具，用于精准定位高延迟或丢包发生的跳点；抓包仅为验证手段，须在lo或any接口进行以规避offload失真，并结合netstat -s等协议栈统计确认根因。
排查 Linux 网络延迟过高，抓包不是第一步，而是验证性手段——它用来确认“问题是否真出在协议交互环节”，以及“卡在哪一环”。盲目抓包容易被网卡 offload、时间精度、过滤失真干扰，反而误导判断。关键在于：选对接口、避开卸载、带上下文比对。
先用 mtr 定位可疑跳点，再针对性抓包
mtr 是抓包前的必经筛子。它能告诉你延迟突增或丢包是从哪一跳开始的，从而决定抓包位置：
- 若第一跳（本地网关）就 Avg 高 + StDev 大 → 问题在本机或局域网，优先在本机 lo 或 eth0 抓包
- 若中间某跳（如第3跳）Loss% 突升 → 问题大概率在该设备或其上游链路，需协调对端或中间网络设备抓包
- 若最后一跳丢包但前面都正常 → 目标服务器自身处理异常，应在目标机上抓包（注意别只抓 eth0，也抓 lo）
抓包必须用 lo 或 any 接口，避免 offload 失真
在物理网卡（如 eth0）上直接抓包，常因 TSO/GSO/LRO 等硬件卸载功能导致看到的不是真实 TCP/IP 包：SYN 可能被合并、ACK 可能被延迟合并、时间戳不准。正确做法是：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
验证本机协议栈行为：用
tcpdump -i lo -n port 80抓回环流量，完全绕过网卡，看应用层发包和内核 ACK 是否及时 -
捕获全链路原始帧：用
tcpdump -i any -n port 80，它强制内核在协议栈更早阶段截获，保留真实时间戳和分片状态 - 避免
-i eth0单独使用，除非你已确认ethtool -k eth0显示所有 offload 均为 off
抓包后重点看三类模式，不只数丢包
延迟高 ≠ 丢包多。抓包要盯住时序逻辑，而非单纯统计：
-
SYN 半开堆积：客户端连续发多个 SYN，无 SYN+ACK 回应 → 检查目标端口是否监听（
ss -tlnp | grep :端口）、防火墙是否拦截（iptables -L -n -v）、SYN Cookie 是否误触发（netstat -s | grep "SYNs to LISTEN sockets"） -
ACK 延迟或缺失：服务端收到数据后，迟迟不发 ACK（>200ms），或 ACK 被延迟合并 → 查
/proc/sys/net/ipv4/tcp_delack_min、软中断堆积（top看 %si）、RPS 是否未启用 - 重传与乱序共存：同一 Seq 号多次重传，同时出现明显乱序（Wireshark 中 “TCP Out-Of-Order” 提示）→ 指向中间设备 QoS 限速、队列策略激进，或本机网卡中断绑定不均
配合 netstat -s/ss -s 看协议栈内部计数
抓包看到现象，要用协议栈统计确认根因。例如：
- 抓到大量重传，但
netstat -s | grep "TCPSynRetrans"值很小 → 重传来自用户态（如应用层重试），非内核 TCP 行为 - 抓包显示大量 DUP-ACK，而
netstat -s | grep "TCPTimeouts"持续增长 → 真实丢包，需查网卡 RX errors/dropped - UDP 流量延迟抖动大，
netstat -s | grep "UdpInErrors"非零 → 很可能是net.core.rmem_max过小或 DMA 内存不足，不是网络链路问题
