TCPDump抓包分析实战

TCPDump抓包分析实战：10个常见网络问题排查案例

作为一名资深运维工程师，我在生产环境中遇到过各种奇葩的网络问题。今天分享10个真实案例，带你掌握TCPDump这把利器，让网络问题无处遁形！

前言：为什么TCPDump是运维必备神器？

在凌晨3点被告警吵醒时，当用户疯狂投诉网络卡顿时，当开发甩锅说"肯定是网络问题"时——TCPDump就是你最可靠的战友。它不会说谎，不会掩饰，只会如实记录每一个数据包的来龙去脉。

本文你将学到：

• 10个生产环境真实排查案例

• TCPDump核心参数使用技巧

• 抓包结果分析的黄金法则

• 快速定位问题的实战方法论

案例1：神秘的连接超时 - TCP三次握手失败

问题现象

 

# 用户反馈：访问API接口频繁超时
curl: (7) Failed to connect to api.example.com port 443: Connection timed out

 

抓包分析

 

# 抓包命令
tcpdump -i eth0 -nn -s0 -w timeout.pcap host api.example.com

# 分析结果
1015.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S], seq 1000, win 65535
1018.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S], seq 1000, win 65535
1024.123456 IP 192.168.1.100.45678 > 203.0.113.10.443: Flags [S], seq 1000, win 65535

 

关键发现： 只有SYN包，没有SYN-ACK回包！

解决方案

检查防火墙规则，发现出站443端口被误删。这种"只出不进"的问题，只有抓包才能快速定位。

运维金句： 网络问题80%都卡在防火墙上，TCPDump帮你一眼看穿！

案例2：诡异的慢查询 - TCP窗口缩放问题

问题现象

数据库查询偶发性慢，监控显示CPU、内存正常，但响应时间飙升到30秒。

抓包技巧

 

# 专门抓取数据库流量
tcpdump -i any -nn -s0 port 3306 and host 192.168.1.50 -w mysql_slow.pcap

# 重点关注窗口大小变化
tcpdump -r mysql_slow.pcap -nn | grep "win"

 

分析结果

 

# 正常情况
1001 IP client.45678 > mysql.3306: win 65535
# 异常情况  
1002 IP client.45678 > mysql.3306: win 0
1002 IP mysql.3306 > client.45678: win 32768 [window probe]

 

发现问题： TCP接收窗口为0，触发零窗口探测，导致传输停顿。

根本原因： 应用程序处理MySQL结果集太慢，接收缓冲区被占满。

案例3：负载均衡的背后杀手 - RST包追踪

问题现象

负载均衡后端服务器连接频繁中断，日志显示大量"Connection reset by peer"。

实战抓包

 

# 专门捕获RST包
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' -c 100

# 结果分析
1115 IP 10.0.1.100.80 > 192.168.1.200.12345: Flags [R.], seq 12345, ack 67890
1116 IP 10.0.1.100.80 > 192.168.1.201.12346: Flags [R.], seq 54321, ack 98765

 

分析思路：

1. RST包的发送方向（是客户端还是服务端主动断开？）

2. RST包的时机（在数据传输中？还是连接建立后？）

3. 序列号是否正确（判断是否为异常RST）

最终发现： 负载均衡器健康检查配置错误，超时时间设置过短，导致正常连接被误杀。

案例4：HTTP请求的离奇失踪 - 应用层协议分析

问题描述

Web应用POST请求成功率只有70%，GET请求正常，开发坚持说代码没问题。

深度抓包

 

# 抓取HTTP流量并保存
tcpdump -i eth0 -A -s0 port 8080 -w http_post.pcap

# 过滤POST请求
tcpdump -r http_post.pcap -A | grep -i "post"

 

分析发现

 

# 成功的POST请求
POST /api/user HTTP/1.1
Content-Length: 256
Content-Type: application/json

{"user_id":123,"name":"test"}

# 失败的POST请求  
POST /api/user HTTP/1.1
Content-Length: 512
Content-Type: application/json

{"user_id":123,"name":"test"}

 

问题定位： Content-Length与实际载荷不匹配！

根本原因： 反向代理Nginx配置了client_max_body_size限制，但错误日志级别设置过高，运维没有察觉。

案例5：DNS解析的隐形陷阱

故障现象

应用启动后前几分钟正常，随后域名解析失败，重启临时解决。

DNS抓包诊断

 

# 抓取DNS查询流量
tcpdump -i eth0 -nn port 53 -w dns_issue.pcap

# 分析DNS响应
tcpdump -r dns_issue.pcap -nn | grep "A?"

 

关键发现

 

# 正常DNS查询
1201 IP 192.168.1.100.12345 > 8.8.8.8.53: 12345+ A? api.example.com
1201 IP 8.8.8.8.53 > 192.168.1.100.12345: 12345 1/0/0 A 203.0.113.10

# 异常DNS查询
1201 IP 192.168.1.100.12346 > 8.8.8.8.53: 12346+ A? api.example.com
# 没有回包！

 

问题根源： DNS服务器IP配置了双栈，但IPv6路由有问题，应用随机选择DNS服务器导致间歇性失败。

案例6：SSL握手的暗黑时刻

问题场景

HTTPS站点间歇性报告SSL握手失败，浏览器显示"ERR_SSL_PROTOCOL_ERROR"。

TLS抓包技巧

 

# 抓取SSL握手过程
tcpdump -i eth0 -nn -s0 port 443 and host web.example.com -w ssl_handshake.pcap

# 使用Wireshark分析或命令行查看
tcpdump -r ssl_handshake.pcap -nn -x

 

分析要点

 

# 正常SSL握手流程
Client Hello -> Server Hello -> Certificate -> Server Hello Done -> 
Client Key Exchange -> Change Cipher Spec -> Finished

# 异常情况：在Certificate阶段中断
Client Hello -> Server Hello -> [连接断开]

 

深度分析： 证书链不完整，中间CA证书缺失，部分客户端无法验证。

案例7：微服务间的通信雷区

复杂场景

微服务A调用服务B，成功率95%，但失败的5%找不到规律。

分布式追踪抓包

 

# 多网卡同时抓包
tcpdump -i any -nn -s0 '(src host serviceA and dst host serviceB) or (src host serviceB and dst host serviceA)' -w microservice.pcap

# 按连接分组分析
tcpdump -r microservice.pcap -nn | awk '{print $3 " -> " $5}' | sort | uniq -c

 

意外发现

 

# 正常连接
192.168.1.10.8080 -> 192.168.1.20.9090: established

# 异常连接 - 注意端口复用问题
192.168.1.10.8080 -> 192.168.1.20.9090: [端口被复用，序列号混乱]

 

问题本质： 服务B重启时，TCP TIME_WAIT状态处理不当，导致端口复用冲突。

案例8：带宽打满的真相

告警现象

服务器带宽使用率突然飙升到95%，但业务量没有明显增长。

流量分析抓包

 

# 按流量大小排序连接
tcpdump -i eth0 -nn -q | head -1000 | awk '{print $3}' | sort | uniq -c | sort -nr

# 抓取大流量连接详情
tcpdump -i eth0 -nn -s0 src 192.168.1.100 -w bandwidth_hog.pcap

 

惊人发现

大部分流量来自一个内网IP的重复请求，仔细分析发现是负载均衡健康检查配置错误，检查间隔设置为1ms！

优化方案： 调整健康检查参数，带宽使用率立即降到正常水平。

案例9：数据包的神秘变异

诡异现象

客户端发送正确数据，但服务端接收到的数据被截断或乱码。

中间人抓包

 

# 在网关设备抓包
tcpdump -i eth0 -xx -s0 host client.ip and host server.ip -w packet_corruption.pcap

# 对比数据包内容
tcpdump -r packet_corruption.pcap -xx | grep "payload"

 

真相大白

 

# 客户端发送（正确）
45 00 05 dc ... [完整数据包]

# 服务端接收（被篡改）  
45 00 05 dc ... [数据包被中间网络设备修改]

 

罪魁祸首： 某台交换机固件bug，对特定模式的数据包进行了错误的校验和重计算。

案例10：时间就是金钱 - 延迟分析

性能问题

API响应时间P99达到5秒，但数据库查询只需50ms。

时延测量抓包

 

# 精确时间戳抓包
tcpdump -i eth0 -ttt -nn port 8080 -w latency_analysis.pcap

# 分析往返时间
tcpdump -r latency_analysis.pcap -ttt -nn | grep "HTTP"

 

延迟分解

 

# TCP建连时间：150ms
# SSL握手时间：300ms  
# HTTP请求处理：50ms
# 网络传输时间：4500ms ← 问题在这里！

 

最终定位： 出口网关的QoS策略错误，将API流量标记为低优先级。

TCPDump实战技巧总结

黄金参数组合

 

# 万能抓包命令
tcpdump -i any -nn -s0 -w capture.pcap

# 参数解释
-i any      # 监听所有网卡
-nn         # 不解析主机名和端口名
-s0         # 抓取完整数据包
-w file     # 保存到文件

 

过滤器魔法

 

# 按主机过滤
tcpdump host 192.168.1.100

# 按端口过滤  
tcpdump port 80 or port 443

# 按协议过滤
tcpdump tcp and not ssh

# 按标志位过滤
tcpdump 'tcp[tcpflags] & tcp-syn != 0'

# 组合过滤
tcpdump -i eth0 -nn 'host 192.168.1.100 and (port 80 or port 443) and tcp[tcpflags] & tcp-syn != 0'

 

分析思维框架

网络问题排查四步法：

1. 现象描述 - 准确描述问题现象，收集错误日志

2. 假设验证 - 基于经验提出假设，设计抓包验证方案

3. 数据分析 - 深入分析抓包数据，寻找异常模式

4. 根因确认 - 找到根本原因，制定解决方案

抓包分析五个维度：

• 连接层面：TCP三次握手、四次挥手是否正常

• 传输层面：序列号、确认号、窗口大小变化

• 应用层面：HTTP状态码、SSL握手过程

• 时间层面：延迟分布、超时设置

• 统计层面：重传率、丢包率、连接数

进阶技能点

1. 自动化分析脚本

 

#!/bin/bash
# 网络问题快速诊断脚本
echo"开始网络诊断..."

# 基础连通性测试
ping -c 4 $1 > /tmp/ping.log 2>&1

# 抓包分析
timeout 30 tcpdump -i any -nn -c 100 host $1 -w /tmp/capture.pcap 2>/dev/null

# 分析结果
echo"=== 连通性测试 ==="
cat /tmp/ping.log

echo"=== 数据包统计 ==="
tcpdump -r /tmp/capture.pcap -nn | head -10

 

2. 性能监控集成

将TCPDump与监控系统结合，实现异常时自动抓包：

 

# Zabbix触发器脚本示例
if [ $NETWORK_ERROR_RATE -gt 5 ]; then
    tcpdump -i eth0 -G 300 -W 2 -w /var/log/auto_capture_%Y%m%d_%H%M%S.pcap &
    echo "自动抓包已启动"
fi

 

3. 大规模环境优化

生产环境抓包的注意事项：

• 使用环形缓冲区避免磁盘空间不足

• 合理设置过滤器减少CPU开销

• 在网络镜像端口进行抓包避免影响业务

• 建立抓包数据的归档和清理策略

结语：掌握网络诊断的核心武器

作为运维工程师，网络问题永远是我们绕不开的话题。TCPDump不仅仅是一个工具，更是我们理解网络通信本质的窗口。

记住这些关键点：

• 网络问题70%可以通过抓包快速定位

• 掌握基础的TCP/IP协议是前提

• 培养从数据包中发现异常模式的直觉

• 建立系统化的问题排查方法论

最后的运维哲学：

当所有人都在猜测问题原因时，只有数据包不会撒谎。TCPDump让我们成为网络世界的侦探，每一个字节都是破案的线索。