服务间偶发超时、连接被重置、请求发出去没响应,这类问题日志里往往看不到原因。tcpdump 能直接看网卡上的真实报文,是判断“包到底有没有到、谁先断开连接”的最直接办法。本文整理常用的过滤写法和几个典型现象的判读。
# 查看有哪些网卡
tcpdump -D
# 在 eth0 上抓包,不解析主机名和端口名(更快,输出更清晰)
tcpdump -i eth0 -nn
# 任意网卡
tcpdump -i any -nn常用选项:
-nn:不做 DNS 和端口名解析,避免抓包时产生额外的查询流量。-c 100:抓到 100 个包后退出。-s 0:抓取完整报文(新版本默认已是完整长度,低版本需要显式指定)。-w file.pcap:写入文件,用于事后分析。-A 或 -X:以 ASCII 或十六进制显示报文内容,适合查看明文 HTTP。抓包需要 root 权限,在生产机上要注意流量很大时对性能和磁盘的影响。
先过滤再抓,能显著降低干扰:
# 指定主机
tcpdump -i eth0 -nn host 10.0.0.5
# 指定端口
tcpdump -i eth0 -nn port 8080
# 组合条件:来自某主机且目的端口为 3306
tcpdump -i eth0 -nn src host 10.0.0.5 and dst port 3306
# 只看 TCP SYN 包(排查建连问题)
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0'
# 只看 RST 包(排查连接被重置)
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0'逻辑运算符是 and、or、not,含括号或位运算的表达式要用单引号包起来,避免被 shell 解释。
12:00:01.123456 IP 10.0.0.5.51234 > 10.0.0.9.8080: Flags [S], seq 100, win 64240, length 0字段含义:时间、源地址与端口、目的地址与端口、TCP 标志、序号、窗口大小、负载长度。常见标志:
[S]:SYN,发起连接。[S.]:SYN+ACK,响应连接。[.]:ACK。[P.]:PSH+ACK,带数据。[F.]:FIN,正常关闭。[R] 或 [R.]:RST,异常中断。客户端反复发送 [S] 而收不到 [S.],说明报文没有被服务端响应,可能原因:服务端没监听该端口且防火墙静默丢弃、安全组或网络策略拦截、路由不通。再在服务端网卡上同时抓包:如果服务端也看不到 SYN,问题在链路中间;如果看到了却不回应,问题在服务端本机。
对 SYN 的响应直接是 [R.],通常是目标端口没有进程监听。
建立后某一方突然发 [R]。关注是谁先发的:服务端发的,可能是应用主动关闭、超时清理或负载均衡的空闲超时;中间设备发的,可能是防火墙会话超时。结合发 RST 之前的静默时长判断,如果恰好是某个固定数值(如 60 秒、350 秒),多半是某一层的空闲超时。
同一序号的数据包重复出现,是重传的表现。重传集中出现说明链路上有丢包或对端响应慢。在 Wireshark 中,TCP 分析会直接标出 retransmission 和 duplicate ack,比肉眼看文本更方便。
对比请求发出时间和响应第一个数据包到达时间。网络往返时间可以从 SYN 到 SYN+ACK 的间隔估计;如果往返很快,但请求到响应之间隔了很久,说明时间花在服务端应用处理上。
# 抓取并轮转,避免文件无限增长:每个文件 100MB,最多保留 10 个
tcpdump -i eth0 -nn -s 0 -C 100 -W 10 -w /tmp/cap.pcap port 8080再把文件下载到本地,用 Wireshark 打开,通过“跟踪 TCP 流”和“专家信息”查看完整会话。
-nn 和过滤表达式缩小范围。原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。