Wireshark实战指南:从抓包到分析的五种经典故障排查场景
一、准备工作:打造专业抓包环境
二、网络延迟定位:时间就是金钱
三、DNS解析故障:从响应码看乾坤
四、HTTP异常请求:藏在报文里的密码
五、TCP重传风暴:不是所有重传都是故障
六、解密TLS:拨开加密的迷雾
七、无线网络诊断:空气中的数据战争
八、自动化分析:让机器帮你看报文
九、避坑指南:这些错误千万别犯
十、案例复盘:一次完整的故障排查之旅
一、准备工作:打造专业抓包环境
工欲善其事,必先利其器。安装Wireshark时建议勾选Npcap的"802.11+radio"选项,这对无线网络抓包至关重要。记得在捕获选项里开启"Update list of packets in real time",这个实时刷新功能在排查瞬时故障时能救命。
笔者在数据中心遇到过一次诡异的TCP连接超时问题,通过在交换机配置端口镜像,成功捕获到服务器网卡在特定负载下出现的环回包异常。这里有个小技巧:capture.filter
里设置tcp port 80
比在显示过滤器设置效率高20%。
二、网络延迟定位:时间就是金钱
当用户抱怨网页加载慢时,先按Ctrl+Alt+R
开启时间参考功能。重点观察TCP握手时序:正常SYN到SYN-ACK的间隔应该小于1ms。某次排查电商网站卡顿,发现SYN重传时间间隔从1秒指数级增长到8秒,最终定位到防火墙的异常会话限制配置。
延迟分析三板斧:
- I/O图表看整体趋势
tcp.time_delta > 0.5
过滤异常间隔- 统计→TCP流图形中的锯齿状波动
三、DNS解析故障:从响应码看乾坤
遇到域名无法解析时,先看响应报文中的RCODE字段。那次排查CDN节点故障,发现大量SERVFAIL(2)响应,原来是递归DNS的ECS配置错误。注意:NXDOMAIN(3)和REFUSED(5)的处理逻辑完全不同。
推荐过滤器:dns.flags.response == 1 && dns.rcode != 0
四、HTTP异常请求:藏在报文里的密码
某API服务突发500错误,用http.response.code >= 500
快速定位到异常响应。进一步分析发现请求头里的Expect: 100-continue
导致服务端处理超时。更隐蔽的问题:有个客户端发送的Content-Length
与实际body长度差1字节,触发服务端缓冲区溢出保护。
小技巧:右击报文→Follow→HTTP Stream,完整还原会话过程。
五、TCP重传风暴:不是所有重传都是故障
用tcp.analysis.retransmission
过滤重传包时要注意区分类型。曾遇到服务器配置了TCP Fast Open导致正常重传被误判,关键要看重传间隔是否指数增长。健康的重传率应低于0.5%,超过2%就要亮红灯了。
进阶分析:统计→Conversations→TCP标签,按重传次数排序。重点关注单个流持续重传的情况,这往往是端到端路径问题。
六、解密TLS:拨开加密的迷雾
配置SSLKEYLOGFILE环境变量后,在Wireshark的TLS协议首选项中导入密钥。某次分析微信小程序加载失败,解密后发现服务器发送了certificate_required
警报,原来是客户端没有发送SNI扩展。
重要提示:TLS1.3的握手过程更简洁,要特别关注ClientHello
中的supported_versions扩展。
七、无线网络诊断:空气中的数据战争
在802.11协议过滤器中,wlan.fc.type_subtype == 0x08
过滤信标帧。曾发现某会议室WiFi频繁掉线,通过信标帧间隔分析,定位到隐藏的非法热点干扰。关键指标:重传率超过15%或信号强度波动大于5dBm都需警惕。
蓝牙抓包技巧:需要专用适配器,关注L2CAP层的PSM
参数,配合btl2cap.psm == 0x0001
过滤控制信道。
八、自动化分析:让机器帮你看报文
推荐使用tshark命令行工具批量处理:
tshark -r capture.pcap -Y "tcp.analysis.window_update" -T fields -e frame.time -e ip.src -e tcp.window_size
某次分析DDoS攻击,用这个脚本快速统计出SYN包的源IP分布。
九、避坑指南:这些错误千万别犯
- 不要在虚拟交换机上直接抓包,会丢失VLAN标签
- 巨型帧捕获需要调整MTU设置
- 时间显示格式务必统一为UTC
- 抓取回环流量需要安装RawCap
- 持续抓包超过1GB时要设置文件分段
那次在金融系统排查交易超时,因为没注意NTP时间同步,导致分析报文时序完全错乱,白白浪费两天时间。
十、案例复盘:一次完整的故障排查之旅
去年双十一某电商APP图片加载缓慢,通过以下步骤定位:
- 在客户端抓取完整HTTPS流量
- 发现大量STREAM_RESET帧
- 关联CDN节点的TCP流图形
- 发现服务端频繁调整接收窗口
- 最终定位到负载均衡器的缓冲区设置过小
整个分析过程用时3小时,涉及12个关键报文分析,最终通过调整net.ipv4.tcp_rmem
参数解决。