人人都会AI编程

22.4 网络延迟与丢包排查：链路检测、连接状态、抓包分析

更新时间：2026-07-12

网络延迟和丢包是线上服务中最常见的两类网络故障，可能由链路拥塞、路由故障、防火墙拦截、网卡丢包、应用层处理缓慢等多种原因引起。排查时通常遵循从链路层到传输层再到应用层的自底向上顺序：先确认物理链路和路由是否通畅，再检查主机上的连接状态和协议栈统计，最后通过抓包精确定位问题。下面介绍每个环节最实用、最常用的工具和方法。

一、链路检测：从 ping 到 MTR

1. ping —— 基础的连通性与 RTT 测试

ping -c 10 8.8.8.8
  • -c 指定发送次数，避免无限 ping。
  • 观察输出中的 time=xx ms，如果忽大忽小或持续偏高，说明链路抖动或拥塞。
  • 重点关注丢包率（packet loss）。即使 1% 的丢包也会对 TCP 吞吐造成明显影响。

2. traceroute / tracepath —— 发现路由瓶颈

traceroute -n 8.8.8.8
  • -n 不进行 DNS 反向解析，加快速度。
  • 每一跳显示三个延迟值（默认发送三个探测包），如果某一跳之后所有延迟都明显增大，通常就是该节点开始出现拥塞或路由绕路。
  • 出现 * 可能表示该节点不响应 ICMP，并不一定代表故障，但若后续所有跳都是星号，则可能是该节点确实不通。

3. mtr —— 结合 ping 与 traceroute 的实时动态分析

mtr -rn 8.8.8.8
  • -r 生成报告模式，-n 不对 IP 做 DNS 解析。
  • mtr 会持续向路由路径上每一跳发送探测包，并统计每个节点的丢包率、平均延迟和最差延迟。它比单次 traceroute 更能发现间歇性丢包和延迟抖动。
  • 重点关注 Loss% 列：如果中间某跳丢包严重但最终目的丢包不高，通常说明该中间节点只是限速了 ICMP 响应（无需担心）。如果最终目的也出现了持续丢包，则链路确实存在问题。

二、连接状态：从主机网络栈看问题

当链路本身看起来通畅，但应用仍然抱怨“慢”或“连不上”时，需要检查主机自身的连接情况和 TCP/IP 协议栈统计。

1. ss —— 查看 socket 统计与 TCP 状态

ss -tuln          # 列出所有 TCP/UDP 监听端口
ss -tan state established | wc -l   # 统计当前 ESTABLISHED 连接数
ss -t -o state time-wait           # 查看 TIME-WAIT 状态的连接及其计时器
  • ss 是取代 netstat 的现代工具，速度更快。
  • 大量连接堆积在 SYN-SENT、SYN-RECV 或 TIME-WAIT 状态往往是网络延迟或应用处理慢的迹象。
  • 如果 Recv-Q 或 Send-Q 列持续非零，说明应用读取或发送数据堆积，延迟由此产生。

2. netstat -s —— TCP 协议栈统计

netstat -s | grep -E "retransmit|segments|packet"
  • 关注 segments retransmitted（重传次数）和 packet receive errors。如果重传比例持续增长，说明存在丢包。
  • TCPFastRetrans、TCPSlowStartRetrans 等数值也能指示网络质量。

3. /proc/net/dev 或 ifconfig/ip -s link —— 网卡级别的丢包和错误

ip -s link show eth0
  • 查看 errors、dropped、overruns 等计数器。如果 RX 或 TX 的 dropped 持续增加，可能是网卡驱动队列溢出或硬件缓冲区不足。
  • 通常需要在问题复现时连续观察多次，判断计数器是否在增长。

4. ethtool -S —— 网卡硬件统计

ethtool -S eth0 | grep -i drop
  • 直接读取网卡硬件寄存器中的丢包计数器，用于区分是软件栈丢包还是网卡本身造成的丢弃（如 FCS 错误、缓冲耗尽等）。

三、抓包分析：用 packet 说话

当链路和连接统计无法直接指出问题时，抓包分析是最终手段。它能让你看到每一个报文在时间线上的实际动态。

1. tcpdump —— 通用命令行抓包工具

# 抓取与特定主机通信的所有包，写入文件
tcpdump -i eth0 host 192.168.1.100 -w capture.pcap

# 实时查看 TCP 握手和挥手过程中的关键标志位
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0'

# 查看特定端口的流量，并打印详细信息
tcpdump -i eth0 port 80 -nn -v
  • -w 将原始报文保存为 pcap 文件，方便后续用 Wireshark 分析。
  • -nn 不解析主机名和端口名，避免产生额外 DNS 查询。
  • 抓包时根据主机、端口、协议仔细过滤，避免产生海量无用数据。

2. tshark —— Wireshark 的命令行版本，分析能力更强

tshark -r capture.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.port
  • 直接筛选出所有 TCP 重传报文，并显示时间、源/目 IP 和端口。
  • 可以通过 -z io,stat,1 等选项生成流量统计。

3. 典型场景的分析模式

  • 定位延迟原因：用 tcpdump 或 tshark 抓取一次完整的 TCP 连接，在 Wireshark 中查看 “Time” 列，重点关注三次握手时间、请求发出到收到第一个响应字节的时间（TTFB）以及数据段的到达间隔。如果 SYN 或 ACK 包之间的间隔极短（微秒级别），但业务数据回包却要几百毫秒，延迟往往在应用层；如果连三次握手都很慢，那问题在网络层。
  • 定位丢包原因：在 Wireshark 中启用 “Expert Info”，会直接标出重传、重复 ACK、零窗口等事件。大量快速重传或超时重传表明有丢包。结合 tcp.analysis.lost_segment 过滤条件可以找到丢失报文的具体序号，根据时间戳判断发生在内网还是公网段。
  • 窗口与延迟：如果跟踪到接收方频繁发送窗口更新（Window Update）但窗口很小，说明应用读取缓冲区太慢；如果看到零窗口（Zero Window），应用程序很可能已经阻塞。

四、排查步骤建议

当面对一个“网络很慢/连接超时”的问题时，可以遵循以下快速路径：

  1. ping + mtr 确认基本链路是否有丢包或高延迟节点。
  2. 如果链路正常，在目标主机上执行 ss -t -o 检查是否有连接堆积或 Send-Q/Recv-Q 堆积。
  3. 查看 netstat -s 的重传统计，确认是否有持续重传。
  4. 如有怀疑，在客户端和服务端同时抓包，重点关注三次握手时间、重传、重复 ACK 和应用层响应延迟。
  5. 结合分析结果精确定位问题节点（是网络链路、防火墙、服务器网卡、内核协议栈，还是应用处理瓶颈）。

这套组合拳几乎可以覆盖 90% 以上的网络延迟和丢包问题，核心在于逐步缩小范围，用工具的叠加效应而不是盲目猜测来找到根因。