Linux服务器网络延迟排查实战：tcpdump抓包分析与mtr路径诊断

网络延迟是服务器运维中最高频的故障类型之一。用户报告”网站慢”、”接口超时”时，问题可能出在DNS解析、TCP握手、应用处理、后端依赖任一环节。系统化的排查工具链——tcpdump、mtr、ss——配合分层定位方法，可以在分钟级别内锁定延迟根因。

tcpdump抓包过滤语法与常用参数

tcpdump是Linux下最基础的抓包工具，通过BPF（Berkeley Packet Filter）语法过滤数据包。定位特定端口的通信：

# 抓取80端口的TCP包
tcpdump -i eth0 -nn port 80

# 抓取特定IP的双向通信
tcpdump -i eth0 -nn host 10.0.1.100

# 组合过滤：指定IP和端口
tcpdump -i eth0 -nn src 10.0.1.50 and dst port 443

# 抓取TCP SYN包（连接建立请求）
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'

# 保存到文件用Wireshark分析
tcpdump -i eth0 -w /tmp/capture.pcap port 443

-nn参数禁止DNS和端口名解析，避免抓包过程中产生额外DNS查询延迟。-w保存原始pcap文件，后续用tcpdump -r回放或用Wireshark图形化分析。

分析TCP握手延迟，关注SYN与SYN-ACK之间的时间差：

# 显示时间戳
tcpdump -i eth0 -nn -tttt port 443

# 输出示例
2026-09-07 10:23:45.123456 IP 10.0.1.50.54321 > 10.0.2.100.443: Flags [S], seq 123456
2026-09-07 10:23:45.125789 IP 10.0.2.100.443 > 10.0.1.50.54321: Flags [S.], seq 789012, ack 123457
# 握手延迟：2.333ms

如果SYN-ACK延迟超过100ms，排查方向包括：服务端accept队列溢出、防火墙conntrack表满、服务端CPU负载过高无法及时响应。

mtr实时网络路径诊断

mtr结合traceroute和ping的功能，持续探测网络路径上每一跳的丢包率和延迟。相比单次traceroute，mtr的统计特性更能反映间歇性问题：

# 持续追踪到目标IP的路径
mtr -n -c 100 10.0.2.100

# 输出示例
HOST                Loss%   Snt    Last   Avg   Best   Wrst
1. 10.0.1.1         0.0%    100    0.5    0.6    0.3    1.2
2. 10.0.0.1         0.0%    100    1.2    1.3    1.0    2.1
3. 10.0.2.100       5.0%    100   15.3   14.8   12.1   28.5

-n禁止DNS解析加速输出，-c 100发送100个探测包。第3跳5%的丢包率和28.5ms的最差延迟表明目标服务器或最后一跳网络存在抖动。

解读mtr结果需要注意：中间节点的丢包率可能是ICMP限速策略导致的，不一定是真实丢包。只有最终目标节点的丢包率才是真实的端到端丢包。如果中间节点丢包但目标节点不丢包，说明中间节点只是限制了ICMP响应速率。

TCP模式的mtr更准确，因为部分网络设备对ICMP做限速但不对TCP SYN做限速：

# 使用TCP SYN探测（需要root权限）
mtr -n -T -P 443 -c 100 10.0.2.100

-T启用TCP模式，-P指定目标端口。TCP模式需要内核支持CAP_NET_RAW权限。

ss连接状态分析与TIME_WAIT堆积

ss是netstat的替代工具，性能更高且信息更丰富。排查连接状态分布：

# 统计各状态TCP连接数
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 输出示例
    152 ESTAB
     89 TIME-WAIT
     12 CLOSE-WAIT
      3 SYN-RECV

TIME-WAIT数量过高（与ESTAB同量级）会占用大量端口资源。CLOSE-WAIT数量多说明应用层未及时调用close()，属于代码bug。SYN-RECV持续存在说明accept队列溢出或SYN Flood攻击。

查看特定连接的详细信息，包括RTT和拥塞窗口：

# 显示TCP内部信息
ss -ti dst 10.0.2.100

# 输出示例
State  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port
ESTAB  0       0       10.0.1.50:54321     10.0.2.100:443
    cubic rto:204 rtt:2.3/0.5 mss:1448 pmtu:1500 rcvmss:1312
    snd_cwnd:10 advwnd:6400 bytes_retrans:0 bytes_acked:15260

rtt:2.3/0.5表示RTT均值2.3ms、标准差0.5ms。snd_cwnd:10是发送拥塞窗口（单位为MSS），10表示可发送10个MSS大小的数据段。bytes_retrans:0表示无重传，如果重传字节数持续增长，说明链路存在丢包。

DNS解析延迟排查

DNS解析往往是延迟的第一道关卡。使用dig测量解析耗时：

# 测量DNS解析时间
dig +trace example.com

# 逐级查询
dig +trace +additional example.com

# 输出关键行
;; Query time: 23 msec
;; SERVER: 10.0.0.53#53(10.0.0.53)

正常DNS解析应在50ms以内完成。如果dig +trace显示某级DNS服务器响应缓慢，可尝试切换到公共DNS（如114.114.114.114）对比：

dig @114.114.114.114 example.com
dig @10.0.0.53 example.com

应用层缓存DNS结果可消除重复解析延迟。glibc的nscd（Name Service Cache Daemon）或systemd-resolved提供系统级DNS缓存：

# 检查nscd DNS缓存状态
nscd -g | grep -A5 "hosts cache"

# 检查systemd-resolved状态
systemd-resolve --statistics

缓存命中率应保持在90%以上。如果命中率低，检查TTL配置是否过短或缓存服务是否正常工作。

延迟排查标准流程

面对”网络慢”的报告，按以下流程逐步定位：

# 1. 确认延迟现象：单机还是全局
ping -c 10 target_ip          # 基础连通性和延迟
mtr -n -c 50 target_ip        # 路径诊断

# 2. 排除DNS
dig +time=2 +tries=1 domain    # DNS解析时间

# 3. 排除TCP握手
tcpdump -i eth0 -nn -tttt 'tcp[tcpflags] & tcp-syn != 0 and host target_ip' -c 20

# 4. 检查连接状态
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

# 5. 检查内核丢包
netstat -s | grep -E "drop|overflow|reset"

# 6. 检查网卡队列
ethtool -S eth0 | grep -i drop
ethtool -S eth0 | grep -i fifo

netstat -s输出内核网络栈各层统计，关注SYN to LISTEN和overflow计数。如果这两个值持续增长，说明accept队列溢出，需要增大somaxconn和应用的listen backlog。ethtool -S查看网卡硬件层丢包，fifo丢包通常由网卡缓冲区不足导致，可通过ethtool -G eth0 rx 4096增大接收缓冲区解决。