刚接触Wireshark的时候我干过最蠢的事就是打开抓包文件之后对着几百条花花绿绿的列表一顿乱翻看到哪个包像有问题就点哪个最后往往是越看越懵时间花了问题还是没定位到。后来在几个线上故障里翻了车才慢慢琢磨出一套固定的分析路子。这套流程说白了就是先定策略再抓包抓完先看整体、再破会话、最后根据特征顺藤摸瓜定位根因。今天我把它完整拆开讲清楚按这个顺序走绝大多数网络问题都能从一堆乱麻里理出线头。1. 内容整体设计与思路拆解1.1 为什么你需要一套标准分析顺序Wireshark最大的门槛不是功能复杂而是信息过载。一次普通的网页访问背后可能就有几十个TCP连接、上千个数据包更别提那种跑了几个小时的抓包文件动辄几百MB。没有分析顺序的话你面对的不是数据包是一堆十六进制噪音。我记得有一次线上反馈系统登录特别慢我拿着抓包文件开始翻先看TCP握手感觉没啥问题又看HTTP请求响应也觉得挺正常半小时后才发现问题其实出在DNS解析上——客户端每次请求都在等一个超时的DNS响应。如果当时按先跑统计、再过滤慢请求、最后下钻DNS这个顺序来五分钟就搞定了。所谓标准分析顺序从方法论上看就是一层一层做减法第一层先用统计和专家信息锁定哪一段链路有问题确定大致方向第二层用过滤器把可疑会话单独拎出来确认问题在哪个连接上第三层跟踪流、看时序、对比正常与异常行为找到具体原因。这个顺序刚好对应网络排障从粗到细的天然逻辑不跳步就不会乱。1.2 这套分析顺序能解决什么问题说白了这套顺序覆盖了日常工作中最高频的几类问题连接建立慢或失败也就是三次握手相关的故障SYN重传、半连接、握手超时传输慢比如HTTP请求发出去之后迟迟等不到响应或者下载速度上不去数据异常中断比如连接被重置RST、丢包重传严重、乱序导致性能劣化应用层协议异常比如HTTP 4xx/5xx、TLS握手失败、DNS解析超时等。不管你是做运维、网络工程、测试还是偶尔需要排查接口联调问题这套思路都能直接套用。1.3 分析顺序的六个核心阶段我把整套流程拆成六个阶段后面每一章都会具体展开明确目标与抓包位置选择——先搞清楚在哪抓和抓什么快速全局扫描——用宏观视图判断问题方向会话筛选与定位——锁定嫌疑TCP流TCP行为分析——通过握手、重传、窗口等判断传输层状态应用层根因定位——在嫌疑流里找到真正的业务原因验证与总结——确认原因、量化影响、沉淀结论。为什么非要把定位嫌疑流放在TCP分析前面因为我在实际中吃过亏不先确定是哪个会话有问题直接扎进TCP细节里很容易被大量重传包带偏方向最后分析半天发现那只是背景流量。2. 抓包前准备与抓包策略2.1 抓包位置选不对后面全白费很多新手抓包失败或者抓不到想要的包问题常常出在抓包位置上。Wireshark只能看到它所运行的那台主机能收到的流量。比如你要排查浏览器访问网页慢就在用户自己电脑上抓用Wireshark或者WinPcap都行要排查服务器接口响应慢就到服务器上抓要看两台设备之间的完整交互得用交换机镜像口Port Mirroring / SPAN或者串联一台分光器/TAP设备。如果目标主机装了防火墙、网卡驱动开启了大量卸载Large Send Offload、TCP Segmentation Offload或者链路做了硬件加速抓包数据可能是残缺的。最典型的就是TCP Segmentation Offload数据包直接从内核以大包发出去抓包软件看到的包大于MTU导致分析时出现异常的分片和校验和错误。所以正式抓包前我习惯先做两件事在Wireshark的捕获选项里确认一下已解析的地址是不是抓包主机的正确IP随便访问一个网页看看列表里有没有实时产生流量。如果只有零星广播包说明位置或者网卡选错了。2.2 捕获过滤器的正确用法Wireshark的过滤器分两层抓包时用的捕获过滤器Capture Filter和抓包后用的显示过滤器Display Filter。很多人一上来就用显示过滤器但包已经全部收进内存了文件大、卡顿、分析效率低。标准做法是先想清楚我要分析什么流量再用捕获过滤器做第一层收敛。常见的捕获过滤器语法如下# 只抓特定IP的流量 host 192.168.1.100 # 抓某个网段 net 192.168.1.0/24 # 抓特定端口HTTP port 80 # 抓HTTP和DNS组合 port 80 or port 53 # 排除大海捞针的广播组播 not broadcast and not multicast比如业务反馈客户端连服务器超时目标明确直接在服务端抓包机上下这个过滤器就够了host 192.168.1.200 and tcp port 8080这会把内存占用和文件体积压到最低分析时就不会被无关流量干扰。2.3 抓多长时间的包合适抓包时间不是越长越好。抓得越久无关噪声越多分析越费劲。一般的经验值问题能复现的情况下抓1到5分钟足够偶发性问题可以配合环形缓冲区持续抓包保留最近几分钟的数据问题复现后再停止大型下载或视频直播场景控制在10分钟以内否则几百兆甚至上G的文件处理起来非常痛苦。环形缓冲区在Wireshark的捕获选项里面可以设置指定每个文件的容量比如50MB和文件数量比如10个存满后自动覆盖最初的抓包文件。这个功能尤其适合那种不确定什么时候出问题的场景。2.4 分析前必须做的三个设置抓完包不是马上到处乱点先花十秒钟做好三个基础设置能让后续分析顺畅很多开启时间显示为相对时间在视图 - 时间显示格式里选自第一个数据包的经过时间方便观察包与包之间的间隔定位慢在哪个环节开启名称解析但要克制勾选解析网络名称里的MAC和传输层端口解析但不要勾选网络名称解析DNS反向解析会在抓包文件很大时拖慢速度保存副本前去除重复包如果抓包机在两个网口同时抓了流量记得在统计 - 合并时留意重复项或者在分析前用tshark做一次去重。这些看起来不起眼但直接影响效率。特别是相对时间显示我见过太多人对着绝对时间在那算半天延迟根本没必要的。3. 全局扫描先看森林再看树木3.1 专家信息Expert Info是最快的体检报告抓包完成后的第一步不是去看数据包列表而是先看Wireshark左下角的专家信息Expert Info面板。它相当于给整个抓包文件做了一次自动体检把异常、错误、警告按照严重程度排列好。打开方式统计 - 专家信息或者直接用工具栏上的专家信息按钮。关注几个关键等级错误Error通常是Checksum错误校验和错误、TCP重复ACKDup ACK、TCP ZeroWindow零窗口、RST复位等这些往往是直接导致故障的线索注意Note/ 警告Warning比如TCP重传、TCP快速重传、乱序Out-of-Order、可疑的TCP重传等这些说明网络在丢包或排队聊天Chat多数是正常的TCP握手、挥手流程不必过度关注。我在实际排障中最常看的两个指标就是重复ACK的数量和重传的比例。如果专家信息里一大票TCP Spurious Retransmission和Out-of-Order基本可以判定网络链路存在问题比如丢包严重或者带宽饱和。3.2 用统计视图建立宏观认知专家信息告诉你有没有异常但还不够直观。下一步建议打开几个统计视图建立宏观认知。1. 端点统计Endpoints在统计菜单里打开端点可以看到通讯双方、IP地址、各端点的数据包数量和字节数快速找出流量大户。比如线上突然卡顿打开端点统计一看某个IP发送了80%的流量嫌疑就高度集中了。2. 会话统计Conversations会话视图按TCP/UDP连接维度展示流量。用它可以找出吞吐量最大、存在异常的会话。排序方式建议按照数据包数量或相对起始时间来排。3. IO图表I/O Graph这个图最关键——它能展示流量随时间的变化趋势。我一般把Y轴设置为数据包数量或者字节数同时叠加两种过滤条件一种显示全部流量一种显示错误流量比如TCP重传。看图的思路是如果整体流量呈周期性尖峰说明有定时任务或心跳流量如果某个时间段突然归零说明可能断线如果错误流量与重传流量同时飙升高概率是链路拥塞或丢包。有一个实际案例印象很深某个服务的监控图显示流量异常下降但服务没挂我用I/O Graph叠加了HTTP 500的过滤条件发现实际上请求量很高只是后端大量返回500导致正常响应流量骤降。没有IO图光靠看列表很难发现这种模式。3.3 设置显示过滤器锁定范围有了宏观方向之后就开始用显示过滤器锁定具体范围。显示过滤器的语法非常简单易用是我日常消耗最多的功能。常用过滤条件参考# 只看某个IP的出入流量 ip.addr 192.168.1.100 # 只看HTTP流量 http # 只看DNS查询 dns # 只看TCP的RST包 tcp.flags.reset 1 # 只看TCP重传包 tcp.analysis.retransmission # 只看重复ACK tcp.analysis.duplicate_ack # 只看慢于1秒的HTTP请求需要先设置HTTP时间统计 http.time 1调试时把过滤条件加进显示栏Wireshark会实时过滤效率比翻列表高一个量级。4. 会话定位与TCP行为分析4.1 从全局会话里挑出“嫌疑罪犯”宏观扫描之后你基本能判断哪个方向有问题了。接下来的任务是精确定位到某一条TCP连接。推荐操作路径打开统计 - 会话按数据包数量或字节数降序排列找到与故障时间点重合的会话右键 - 跟踪TCP流在弹出的流内容窗口里先看应用层数据是否正常再回看原始包列表。你可能会问为什么先用跟踪流而不是直接看包列表因为跟踪TCP流能让你快速看到这个连接的完整语义尤其HTTP这类文本协议请求/响应一眼就能看清。然后再切回包列表看时序和重传细节比从一堆包里去拼故事快得多。4.2 三次握手快速判断连接层问题TCP连接建立的快慢直接决定用户体验。分析三次握手主要看三点1. 握手完成时长用显示过滤器tcp.flags.syn 1过滤纯SYN包然后看时间戳。正常情况下第二个包SYNACK和第一个包SYN之间的时间差应该在1到3毫秒以内。如果超过50毫秒说明服务器接受连接的能力或者中间链路有延迟。2. 是否存在SYN重传如果服务器一直不回SYNACK客户端会持续重传SYN。重传次数多了最终报连接超时。这时要看服务器端是否在监听端口用ss -lnt确认防火墙是否丢掉了入站的SYN包服务器负载是否过高内核backlog队列已满3. SYNACK有没有被丢弃还有一种隐蔽场景服务器回了SYNACK但客户端一直没收到客户端不断重传SYN但服务器端看状态是SYN_RECV。这种多发生在中间防火墙对SYNACK做了拦截或者服务器路由有问题。4.3 重传Retransmission与重复ACKDup ACK的判读TCP的重传是网络排障最常碰到的现象但很多人一看到重传就喊网络丢包这其实太武断了。重传本身分为好几类原因差异很大类型出现场景常见原因TCP Retransmission数据包丢失或ACK丢失链路丢包、队列拥塞TCP Fast Retransmission收到三个重复ACK后立即重传网络乱序、单包丢失TCP Spurious Retransmission实际没丢却被误判超时网络延迟大、操作系统超时参数过于激进TCP Out-of-Order接收顺序与发送顺序不一致多条路径转发、设备负载均衡处理方法少量重传小于1%通常不影响体验可以继续观察大量重传且集中在同一时间点基本就是链路抖动或交换机丢包建议检查端口统计、错误计数器、光模块收发光功率Spurious Retransmission往往不是网络问题而是TCP参数问题比如系统RTO初始值设置得过低。重传比例如何量化在统计 - TCP流图 - 时间序列图里可以直观看到每个TCP流的序列号变化如果出现明显的锯齿状回退说明重传集中在这个时间段。4.4 窗口Window与吞吐量的关系TCP的窗口大小决定了在不等待确认的情况下能发送多少数据。分析慢的问题时窗口是不可忽略的指标。ZeroWindow零窗口接收方通告窗口为0说明接收端缓冲区满了应用程序没及时取走数据。排查方向应用处理能力、内存、IO瓶颈。Window Full窗口占满发送方数据已占满对方通告的窗口开始等待ACK。排查方向带宽是否跑满、中间设备是否缓存异常。窗口缩放因子Window Scaling高带宽长链路必须开窗口缩放否则最大窗口只有64KB吞吐量上不去。实际中有一个常见误区客户端下载慢一看重传基本没有窗口也正常但吞吐就是上不去。过滤条件看一下TCP时间戳选项有些中间设备会改写时间戳干扰RTT计算进而影响TCP拥塞控制拉低了吞吐。4.5 连接中断RST与四次挥手的区别连接断得干脆利落通常是RST正常结束是FIN。遇到RST包建议按这个思路排查看RST包的发送方是客户端还是服务器跟随TCP流确认RST之前是否有未完成的数据传输查看RST包之前是否有应用层报错比如HTTP返回401未授权、403禁止访问等如果RST发生在数据交互中间优先怀疑应用层主动关闭、连接空闲超时或中间防火墙的Idle Timeout。下面这个案例足以说明问题某个App接口偶发性报错抓包发现服务器先发出了FIN客户端回ACK之后又发了一个RST。后来定位到是客户端应用在收到服务器结束信号后主动释放资源时底层socket已经关闭导致RST被打到网络上。这属于应用逻辑问题跟网络环境一点关系都没有。如果不看包永远发现不了。5. 应用层根因定位实战5.1 HTTP慢请求分析三板斧HTTP是日常排障最常见的应用层协议。分析HTTP慢我一般用三个手段第一板斧HTTP过滤与时间统计在Wireshark里输入http.time这个过滤条件可以看到每个HTTP请求的处理时间从请求发出到收到完整响应的时间差。再结合http.request.method、http.response.code能快速揪出最慢的几个请求# 只看POST请求并且耗时超过1秒的 http.request.method POST and http.time 1 # 只看服务器返回5xx错误的请求 http.response.code 500注意http.time属于Wireshark的分析字段它会随会话和响应自动计算但前提是你抓的包里同时包含请求和响应。第二板斧对比请求与响应时间用时间显示格式 - 自第一个数据包的经过时间逐条看请求和响应在时间轴上的位置请求发出SYN包之后出现HTTP请求体很快到服务器但服务器迟迟不回复说明慢在服务端处理与网络无关服务器回复了但客户端很久才收到中间链路有问题。第三板斧关注HTTP响应码的语义500/502/503服务端出错要么代码异常要么上游链路数据库、缓存慢504网关超时通常是后端服务处理超过了代理超时阈值301/302重定向链路过长会让请求变慢200但数据体大如果是大JSON或大图片耗时主要花在传输上。5.2 DNS解析慢的定位技巧DNS问题经常伪装成打开网页慢因为TCP握手前必须先完成域名解析。如果DNS出问题一切白搭。用显示过滤器dns看解析流程重点看客户端发出的DNS查询是否立刻得到响应如果没有响应客户端会在0.5秒、1秒、2秒后重试每次重试都会增加用户感知的延迟如果响应回来了但耗时特别长优先排查DNS服务器和客户端之间的链路质量。还有一种隐蔽情况DNS查询被中间设备抢答DNS劫持返回的IP不是预期目标导致业务连到了错误的服务端。这种问题光看DNS响应内容就能发现异常。5.3 TLS/HTTPS握手失败怎么分析现在很多业务都走HTTPSTLS握手失败比HTTP裸协议复杂得多。分析TLS时我按下面几步走第一步过滤TLS握手包tls.handshake.type 1 # ClientHello tls.handshake.type 2 # ServerHello tls.handshake.type 11 # Certificate第二步查看会话的加密套件协商客户端在ClientHello里列出支持的加密套件服务端从其中选择一个。如果客户端和服务端的加密套件列表没有交集TLS握手直接失败错误信息通常是no shared cipher。第三步查看证书链和TLS扩展证书过期、自签名、不信任根证书会导致客户端校验失败TLS扩展里的SNIServer Name Indication字段如果为空或者填错服务器会返回默认证书可能导致客户端报警证书不匹配。如果只抓到了ClientHello没有后续的ServerHello基本可以判断服务端没响应或者中间防火墙拦截了TLS握手。很多企业防火墙会做HTTPS解密检测这类设备也可能在TLS握手阶段直接切断连接。5.4 DNS、TCP、HTTP三层的联合排障顺序在实际中用户说慢不是某单层的问题而是多层叠加。我的习惯是建立一个三层联合时间线DNS阶段从用户输入域名到拿到IP花费多久TCP阶段从发起连接SYN到三次握手完成花费多久HTTP阶段从发出GET请求到收到响应花费多久拿Wireshark包列表按时间顺序看如果DNS阶段占比最大就去查DNS服务器、本地DNS缓存、hosts文件如果TCP阶段占比最大就去查路由跳数、链路延迟、防火墙策略如果HTTP阶段占比最大就去查后端逻辑、数据库查询、接口实现。这个思路特别适合那种整体页面加载5秒但不知道慢在哪的场景用相对时间逐项切开责任主体自然就清楚了。6. 常见问题与排查技巧实录6.1 抓包文件太大Wireshark卡死抓包文件超过200MB时Wireshark操作会明显卡顿。解决办法是先用tshark或者editcap做二次裁剪# 只保留HTTP流量另存为新文件 tshark -r big.pcapng -Y http -w http_only.pcapng # 只保留前100000个包 editcap -c 100000 big.pcapng small.pcapng # 提取指定IP的流量 tshark -r big.pcapng -Y ip.addr 192.168.1.100 -w ip_filtered.pcapng6.2 抓包能抓到包但看不到HTTP请求体大多是HTTP/2导致的。现在很多Web服务已经升级到HTTP/2或者HTTP/3而Wireshark对HTTP/2的解码依赖TLS密钥。如果你抓的是HTTPS流量需要在Wireshark里配置TLS解密密钥浏览器导出SSLKEYLOGFILE环境变量如果是HTTP/2明文流量直接在偏好设置里把HTTP/2协议的解码打开如果是QUICHTTP/3需要抓UDP 443端口Wireshark 4.x已经支持解密部分场景但前提同样是要有TLS key log。6.3 校验和显示错误但业务正常这个坑我踩过很多回了。Wireshark显示Checksum Offload错误比如TCP校验和错误很多时候不是真的网络错误而是网卡的校验和卸载Checksum Offloading导致操作系统没来得及计算校验和抓包工具看到的包本身就是半成品。解决方法是先判断错误是否只出现在发送方向的包上如果是去网卡高级属性里关闭IPv4校验和卸载TCP/UDP Checksum Offload重新抓包再看只有接收方向的校验和错误才有真正的排障价值。6.4 抓包中有大量广播包和组播包干扰局域网中的ARP、NetBIOS、LLMNR、mDNS等广播流量非常多很容易淹没真正要分析的流量。处理方法有两个抓包前用捕获过滤器排除not broadcast and not multicast抓包后加显示过滤器not arp and not nbns and not mdns and not llmnr也可以配合着色规则把广播包调成灰色注意力集中在业务流量上。6.5 分析无线网络抓包时的注意事项如果抓的是Wi-Fi流量Wireshark默认抓的是带有无线头RadioTap的帧。分析时注意无线空口重传机制会导致重复包和重传包数量偏多不一定是实际网络故障如果只关心IP层以上的内容可以用wlan.addr和ip.addr配合过滤在使用信标帧Beacon评估信号覆盖时用wlan.fc.type_subtype 8过滤。6.6 如何快速确认某个包是哪个进程发出的Wireshark本身不直接显示进程号但可以用Windows资源监视器或者Linux的ss -tnp对照四元组来查# Linux下根据端口查进程 ss -tnp | grep 8080 # Windows下用netstat netstat -ano | findstr 8080先确定会话的四元组源IP、源端口、目标IP、目标端口再到系统里查端口对应的PID然后到任务管理器里看是哪个进程。这个方法在排查到底是谁在发垃圾请求时特别好用。6.7 抓不到本地回环流量很多人用Wireshark抓本机访问本机服务比如127.0.0.1的流量发现怎么也抓不到。原因是回环流量不走物理网卡需要安装Npcap时勾选Support loopback traffic选项然后在Wireshark里选择Loopback: lo这个虚拟网卡接口进行抓包。6.8 数据包时间间隔显示异常大如果Wireshark显示相邻包间隔几秒甚至几十秒先排除自己的判断误区检查是否启用了名称解析导致卡顿会拉长显示时间检查网卡的TCP时间戳是否异常确认抓包机上是否有其他高负载进程比如杀毒软件全盘扫描影响了抓包软件的实时性。6.9 使用tshark做命令行自动化分析当抓包文件很多、手工处理太慢时可以改用tshark做一些常规指标统计效率提升明显# 统计TCP重传数量 tshark -r capture.pcapng -Y tcp.analysis.retransmission | wc -l # 统计HTTP 500数量 tshark -r capture.pcapng -Y http.response.code 500 | wc -l # 查看每个TCP流的RTT平均值需要开启rt tshark -r capture.pcapng -q -z io,stat,0,AVG(tcp.analysis.rtt)tcp.analysis.rtt这些命令拿到结果比打开Wireshark翻半天快得多适合批量处理多个抓包文件。6.10 实战心得排查效率提升的三个小习惯最后分享三个我个人一直坚持的习惯确实帮我省了很多时间习惯一抓包文件第一时间打标记抓包结束后立刻在注释字段里记录抓包时间、抓包位置、系统特征、问题现象。别高估自己的记忆力三天后再看抓包文件没有注释你根本想不起当时的环境。习惯二分析前先跑一遍专家信息不管多大的抓包文件先花一分钟看专家信息它会自动把最严重的问题顶上来。很多次我都是在专家信息里直接找到罪魁祸首的省去了大量手工过滤的时间。习惯三把过滤条件保存为按钮Wireshark的显示过滤器按钮栏支持自定义把我常用的一批过滤器tcp.analysis.retransmission、http.response.code 400、tcp.flags.reset 1、dns.time 0.1等存成预设按钮下次排障一键切换效率翻倍。7. 总结从抓到根因的路径回顾回顾整套分析方法核心其实只有一句话**确定问题边界层层缩小范围直到找到那个最原始的异常包。**先通过统计和专家信息判断问题发生在链路层、传输层还是应用层再通过会话与流分析锁到具体连接最后用协议细节解释为什么慢、为什么断、为什么错。Wireshark功能再强大也只是个工具真正的价值在于分析和判断能力。只要能熟练掌握从宏观到微观的分析顺序大多数网络问题都难不倒你。最后分享一个我个人的习惯每次排查完一个完整问题我会把抓包文件、过滤条件、根因分析和解决过程整理成一份简短笔记。久而久之这就变成了自己专属的排障手册以后再遇到类似问题直接按图索骥速度快得超乎你想象。下次再打开Wireshark别再瞎翻包了照着这套顺序一步步来问题就能浮出水面。
Wireshark网络排障实战：从抓包到根因定位的标准化流程
刚接触Wireshark的时候我干过最蠢的事就是打开抓包文件之后对着几百条花花绿绿的列表一顿乱翻看到哪个包像有问题就点哪个最后往往是越看越懵时间花了问题还是没定位到。后来在几个线上故障里翻了车才慢慢琢磨出一套固定的分析路子。这套流程说白了就是先定策略再抓包抓完先看整体、再破会话、最后根据特征顺藤摸瓜定位根因。今天我把它完整拆开讲清楚按这个顺序走绝大多数网络问题都能从一堆乱麻里理出线头。1. 内容整体设计与思路拆解1.1 为什么你需要一套标准分析顺序Wireshark最大的门槛不是功能复杂而是信息过载。一次普通的网页访问背后可能就有几十个TCP连接、上千个数据包更别提那种跑了几个小时的抓包文件动辄几百MB。没有分析顺序的话你面对的不是数据包是一堆十六进制噪音。我记得有一次线上反馈系统登录特别慢我拿着抓包文件开始翻先看TCP握手感觉没啥问题又看HTTP请求响应也觉得挺正常半小时后才发现问题其实出在DNS解析上——客户端每次请求都在等一个超时的DNS响应。如果当时按先跑统计、再过滤慢请求、最后下钻DNS这个顺序来五分钟就搞定了。所谓标准分析顺序从方法论上看就是一层一层做减法第一层先用统计和专家信息锁定哪一段链路有问题确定大致方向第二层用过滤器把可疑会话单独拎出来确认问题在哪个连接上第三层跟踪流、看时序、对比正常与异常行为找到具体原因。这个顺序刚好对应网络排障从粗到细的天然逻辑不跳步就不会乱。1.2 这套分析顺序能解决什么问题说白了这套顺序覆盖了日常工作中最高频的几类问题连接建立慢或失败也就是三次握手相关的故障SYN重传、半连接、握手超时传输慢比如HTTP请求发出去之后迟迟等不到响应或者下载速度上不去数据异常中断比如连接被重置RST、丢包重传严重、乱序导致性能劣化应用层协议异常比如HTTP 4xx/5xx、TLS握手失败、DNS解析超时等。不管你是做运维、网络工程、测试还是偶尔需要排查接口联调问题这套思路都能直接套用。1.3 分析顺序的六个核心阶段我把整套流程拆成六个阶段后面每一章都会具体展开明确目标与抓包位置选择——先搞清楚在哪抓和抓什么快速全局扫描——用宏观视图判断问题方向会话筛选与定位——锁定嫌疑TCP流TCP行为分析——通过握手、重传、窗口等判断传输层状态应用层根因定位——在嫌疑流里找到真正的业务原因验证与总结——确认原因、量化影响、沉淀结论。为什么非要把定位嫌疑流放在TCP分析前面因为我在实际中吃过亏不先确定是哪个会话有问题直接扎进TCP细节里很容易被大量重传包带偏方向最后分析半天发现那只是背景流量。2. 抓包前准备与抓包策略2.1 抓包位置选不对后面全白费很多新手抓包失败或者抓不到想要的包问题常常出在抓包位置上。Wireshark只能看到它所运行的那台主机能收到的流量。比如你要排查浏览器访问网页慢就在用户自己电脑上抓用Wireshark或者WinPcap都行要排查服务器接口响应慢就到服务器上抓要看两台设备之间的完整交互得用交换机镜像口Port Mirroring / SPAN或者串联一台分光器/TAP设备。如果目标主机装了防火墙、网卡驱动开启了大量卸载Large Send Offload、TCP Segmentation Offload或者链路做了硬件加速抓包数据可能是残缺的。最典型的就是TCP Segmentation Offload数据包直接从内核以大包发出去抓包软件看到的包大于MTU导致分析时出现异常的分片和校验和错误。所以正式抓包前我习惯先做两件事在Wireshark的捕获选项里确认一下已解析的地址是不是抓包主机的正确IP随便访问一个网页看看列表里有没有实时产生流量。如果只有零星广播包说明位置或者网卡选错了。2.2 捕获过滤器的正确用法Wireshark的过滤器分两层抓包时用的捕获过滤器Capture Filter和抓包后用的显示过滤器Display Filter。很多人一上来就用显示过滤器但包已经全部收进内存了文件大、卡顿、分析效率低。标准做法是先想清楚我要分析什么流量再用捕获过滤器做第一层收敛。常见的捕获过滤器语法如下# 只抓特定IP的流量 host 192.168.1.100 # 抓某个网段 net 192.168.1.0/24 # 抓特定端口HTTP port 80 # 抓HTTP和DNS组合 port 80 or port 53 # 排除大海捞针的广播组播 not broadcast and not multicast比如业务反馈客户端连服务器超时目标明确直接在服务端抓包机上下这个过滤器就够了host 192.168.1.200 and tcp port 8080这会把内存占用和文件体积压到最低分析时就不会被无关流量干扰。2.3 抓多长时间的包合适抓包时间不是越长越好。抓得越久无关噪声越多分析越费劲。一般的经验值问题能复现的情况下抓1到5分钟足够偶发性问题可以配合环形缓冲区持续抓包保留最近几分钟的数据问题复现后再停止大型下载或视频直播场景控制在10分钟以内否则几百兆甚至上G的文件处理起来非常痛苦。环形缓冲区在Wireshark的捕获选项里面可以设置指定每个文件的容量比如50MB和文件数量比如10个存满后自动覆盖最初的抓包文件。这个功能尤其适合那种不确定什么时候出问题的场景。2.4 分析前必须做的三个设置抓完包不是马上到处乱点先花十秒钟做好三个基础设置能让后续分析顺畅很多开启时间显示为相对时间在视图 - 时间显示格式里选自第一个数据包的经过时间方便观察包与包之间的间隔定位慢在哪个环节开启名称解析但要克制勾选解析网络名称里的MAC和传输层端口解析但不要勾选网络名称解析DNS反向解析会在抓包文件很大时拖慢速度保存副本前去除重复包如果抓包机在两个网口同时抓了流量记得在统计 - 合并时留意重复项或者在分析前用tshark做一次去重。这些看起来不起眼但直接影响效率。特别是相对时间显示我见过太多人对着绝对时间在那算半天延迟根本没必要的。3. 全局扫描先看森林再看树木3.1 专家信息Expert Info是最快的体检报告抓包完成后的第一步不是去看数据包列表而是先看Wireshark左下角的专家信息Expert Info面板。它相当于给整个抓包文件做了一次自动体检把异常、错误、警告按照严重程度排列好。打开方式统计 - 专家信息或者直接用工具栏上的专家信息按钮。关注几个关键等级错误Error通常是Checksum错误校验和错误、TCP重复ACKDup ACK、TCP ZeroWindow零窗口、RST复位等这些往往是直接导致故障的线索注意Note/ 警告Warning比如TCP重传、TCP快速重传、乱序Out-of-Order、可疑的TCP重传等这些说明网络在丢包或排队聊天Chat多数是正常的TCP握手、挥手流程不必过度关注。我在实际排障中最常看的两个指标就是重复ACK的数量和重传的比例。如果专家信息里一大票TCP Spurious Retransmission和Out-of-Order基本可以判定网络链路存在问题比如丢包严重或者带宽饱和。3.2 用统计视图建立宏观认知专家信息告诉你有没有异常但还不够直观。下一步建议打开几个统计视图建立宏观认知。1. 端点统计Endpoints在统计菜单里打开端点可以看到通讯双方、IP地址、各端点的数据包数量和字节数快速找出流量大户。比如线上突然卡顿打开端点统计一看某个IP发送了80%的流量嫌疑就高度集中了。2. 会话统计Conversations会话视图按TCP/UDP连接维度展示流量。用它可以找出吞吐量最大、存在异常的会话。排序方式建议按照数据包数量或相对起始时间来排。3. IO图表I/O Graph这个图最关键——它能展示流量随时间的变化趋势。我一般把Y轴设置为数据包数量或者字节数同时叠加两种过滤条件一种显示全部流量一种显示错误流量比如TCP重传。看图的思路是如果整体流量呈周期性尖峰说明有定时任务或心跳流量如果某个时间段突然归零说明可能断线如果错误流量与重传流量同时飙升高概率是链路拥塞或丢包。有一个实际案例印象很深某个服务的监控图显示流量异常下降但服务没挂我用I/O Graph叠加了HTTP 500的过滤条件发现实际上请求量很高只是后端大量返回500导致正常响应流量骤降。没有IO图光靠看列表很难发现这种模式。3.3 设置显示过滤器锁定范围有了宏观方向之后就开始用显示过滤器锁定具体范围。显示过滤器的语法非常简单易用是我日常消耗最多的功能。常用过滤条件参考# 只看某个IP的出入流量 ip.addr 192.168.1.100 # 只看HTTP流量 http # 只看DNS查询 dns # 只看TCP的RST包 tcp.flags.reset 1 # 只看TCP重传包 tcp.analysis.retransmission # 只看重复ACK tcp.analysis.duplicate_ack # 只看慢于1秒的HTTP请求需要先设置HTTP时间统计 http.time 1调试时把过滤条件加进显示栏Wireshark会实时过滤效率比翻列表高一个量级。4. 会话定位与TCP行为分析4.1 从全局会话里挑出“嫌疑罪犯”宏观扫描之后你基本能判断哪个方向有问题了。接下来的任务是精确定位到某一条TCP连接。推荐操作路径打开统计 - 会话按数据包数量或字节数降序排列找到与故障时间点重合的会话右键 - 跟踪TCP流在弹出的流内容窗口里先看应用层数据是否正常再回看原始包列表。你可能会问为什么先用跟踪流而不是直接看包列表因为跟踪TCP流能让你快速看到这个连接的完整语义尤其HTTP这类文本协议请求/响应一眼就能看清。然后再切回包列表看时序和重传细节比从一堆包里去拼故事快得多。4.2 三次握手快速判断连接层问题TCP连接建立的快慢直接决定用户体验。分析三次握手主要看三点1. 握手完成时长用显示过滤器tcp.flags.syn 1过滤纯SYN包然后看时间戳。正常情况下第二个包SYNACK和第一个包SYN之间的时间差应该在1到3毫秒以内。如果超过50毫秒说明服务器接受连接的能力或者中间链路有延迟。2. 是否存在SYN重传如果服务器一直不回SYNACK客户端会持续重传SYN。重传次数多了最终报连接超时。这时要看服务器端是否在监听端口用ss -lnt确认防火墙是否丢掉了入站的SYN包服务器负载是否过高内核backlog队列已满3. SYNACK有没有被丢弃还有一种隐蔽场景服务器回了SYNACK但客户端一直没收到客户端不断重传SYN但服务器端看状态是SYN_RECV。这种多发生在中间防火墙对SYNACK做了拦截或者服务器路由有问题。4.3 重传Retransmission与重复ACKDup ACK的判读TCP的重传是网络排障最常碰到的现象但很多人一看到重传就喊网络丢包这其实太武断了。重传本身分为好几类原因差异很大类型出现场景常见原因TCP Retransmission数据包丢失或ACK丢失链路丢包、队列拥塞TCP Fast Retransmission收到三个重复ACK后立即重传网络乱序、单包丢失TCP Spurious Retransmission实际没丢却被误判超时网络延迟大、操作系统超时参数过于激进TCP Out-of-Order接收顺序与发送顺序不一致多条路径转发、设备负载均衡处理方法少量重传小于1%通常不影响体验可以继续观察大量重传且集中在同一时间点基本就是链路抖动或交换机丢包建议检查端口统计、错误计数器、光模块收发光功率Spurious Retransmission往往不是网络问题而是TCP参数问题比如系统RTO初始值设置得过低。重传比例如何量化在统计 - TCP流图 - 时间序列图里可以直观看到每个TCP流的序列号变化如果出现明显的锯齿状回退说明重传集中在这个时间段。4.4 窗口Window与吞吐量的关系TCP的窗口大小决定了在不等待确认的情况下能发送多少数据。分析慢的问题时窗口是不可忽略的指标。ZeroWindow零窗口接收方通告窗口为0说明接收端缓冲区满了应用程序没及时取走数据。排查方向应用处理能力、内存、IO瓶颈。Window Full窗口占满发送方数据已占满对方通告的窗口开始等待ACK。排查方向带宽是否跑满、中间设备是否缓存异常。窗口缩放因子Window Scaling高带宽长链路必须开窗口缩放否则最大窗口只有64KB吞吐量上不去。实际中有一个常见误区客户端下载慢一看重传基本没有窗口也正常但吞吐就是上不去。过滤条件看一下TCP时间戳选项有些中间设备会改写时间戳干扰RTT计算进而影响TCP拥塞控制拉低了吞吐。4.5 连接中断RST与四次挥手的区别连接断得干脆利落通常是RST正常结束是FIN。遇到RST包建议按这个思路排查看RST包的发送方是客户端还是服务器跟随TCP流确认RST之前是否有未完成的数据传输查看RST包之前是否有应用层报错比如HTTP返回401未授权、403禁止访问等如果RST发生在数据交互中间优先怀疑应用层主动关闭、连接空闲超时或中间防火墙的Idle Timeout。下面这个案例足以说明问题某个App接口偶发性报错抓包发现服务器先发出了FIN客户端回ACK之后又发了一个RST。后来定位到是客户端应用在收到服务器结束信号后主动释放资源时底层socket已经关闭导致RST被打到网络上。这属于应用逻辑问题跟网络环境一点关系都没有。如果不看包永远发现不了。5. 应用层根因定位实战5.1 HTTP慢请求分析三板斧HTTP是日常排障最常见的应用层协议。分析HTTP慢我一般用三个手段第一板斧HTTP过滤与时间统计在Wireshark里输入http.time这个过滤条件可以看到每个HTTP请求的处理时间从请求发出到收到完整响应的时间差。再结合http.request.method、http.response.code能快速揪出最慢的几个请求# 只看POST请求并且耗时超过1秒的 http.request.method POST and http.time 1 # 只看服务器返回5xx错误的请求 http.response.code 500注意http.time属于Wireshark的分析字段它会随会话和响应自动计算但前提是你抓的包里同时包含请求和响应。第二板斧对比请求与响应时间用时间显示格式 - 自第一个数据包的经过时间逐条看请求和响应在时间轴上的位置请求发出SYN包之后出现HTTP请求体很快到服务器但服务器迟迟不回复说明慢在服务端处理与网络无关服务器回复了但客户端很久才收到中间链路有问题。第三板斧关注HTTP响应码的语义500/502/503服务端出错要么代码异常要么上游链路数据库、缓存慢504网关超时通常是后端服务处理超过了代理超时阈值301/302重定向链路过长会让请求变慢200但数据体大如果是大JSON或大图片耗时主要花在传输上。5.2 DNS解析慢的定位技巧DNS问题经常伪装成打开网页慢因为TCP握手前必须先完成域名解析。如果DNS出问题一切白搭。用显示过滤器dns看解析流程重点看客户端发出的DNS查询是否立刻得到响应如果没有响应客户端会在0.5秒、1秒、2秒后重试每次重试都会增加用户感知的延迟如果响应回来了但耗时特别长优先排查DNS服务器和客户端之间的链路质量。还有一种隐蔽情况DNS查询被中间设备抢答DNS劫持返回的IP不是预期目标导致业务连到了错误的服务端。这种问题光看DNS响应内容就能发现异常。5.3 TLS/HTTPS握手失败怎么分析现在很多业务都走HTTPSTLS握手失败比HTTP裸协议复杂得多。分析TLS时我按下面几步走第一步过滤TLS握手包tls.handshake.type 1 # ClientHello tls.handshake.type 2 # ServerHello tls.handshake.type 11 # Certificate第二步查看会话的加密套件协商客户端在ClientHello里列出支持的加密套件服务端从其中选择一个。如果客户端和服务端的加密套件列表没有交集TLS握手直接失败错误信息通常是no shared cipher。第三步查看证书链和TLS扩展证书过期、自签名、不信任根证书会导致客户端校验失败TLS扩展里的SNIServer Name Indication字段如果为空或者填错服务器会返回默认证书可能导致客户端报警证书不匹配。如果只抓到了ClientHello没有后续的ServerHello基本可以判断服务端没响应或者中间防火墙拦截了TLS握手。很多企业防火墙会做HTTPS解密检测这类设备也可能在TLS握手阶段直接切断连接。5.4 DNS、TCP、HTTP三层的联合排障顺序在实际中用户说慢不是某单层的问题而是多层叠加。我的习惯是建立一个三层联合时间线DNS阶段从用户输入域名到拿到IP花费多久TCP阶段从发起连接SYN到三次握手完成花费多久HTTP阶段从发出GET请求到收到响应花费多久拿Wireshark包列表按时间顺序看如果DNS阶段占比最大就去查DNS服务器、本地DNS缓存、hosts文件如果TCP阶段占比最大就去查路由跳数、链路延迟、防火墙策略如果HTTP阶段占比最大就去查后端逻辑、数据库查询、接口实现。这个思路特别适合那种整体页面加载5秒但不知道慢在哪的场景用相对时间逐项切开责任主体自然就清楚了。6. 常见问题与排查技巧实录6.1 抓包文件太大Wireshark卡死抓包文件超过200MB时Wireshark操作会明显卡顿。解决办法是先用tshark或者editcap做二次裁剪# 只保留HTTP流量另存为新文件 tshark -r big.pcapng -Y http -w http_only.pcapng # 只保留前100000个包 editcap -c 100000 big.pcapng small.pcapng # 提取指定IP的流量 tshark -r big.pcapng -Y ip.addr 192.168.1.100 -w ip_filtered.pcapng6.2 抓包能抓到包但看不到HTTP请求体大多是HTTP/2导致的。现在很多Web服务已经升级到HTTP/2或者HTTP/3而Wireshark对HTTP/2的解码依赖TLS密钥。如果你抓的是HTTPS流量需要在Wireshark里配置TLS解密密钥浏览器导出SSLKEYLOGFILE环境变量如果是HTTP/2明文流量直接在偏好设置里把HTTP/2协议的解码打开如果是QUICHTTP/3需要抓UDP 443端口Wireshark 4.x已经支持解密部分场景但前提同样是要有TLS key log。6.3 校验和显示错误但业务正常这个坑我踩过很多回了。Wireshark显示Checksum Offload错误比如TCP校验和错误很多时候不是真的网络错误而是网卡的校验和卸载Checksum Offloading导致操作系统没来得及计算校验和抓包工具看到的包本身就是半成品。解决方法是先判断错误是否只出现在发送方向的包上如果是去网卡高级属性里关闭IPv4校验和卸载TCP/UDP Checksum Offload重新抓包再看只有接收方向的校验和错误才有真正的排障价值。6.4 抓包中有大量广播包和组播包干扰局域网中的ARP、NetBIOS、LLMNR、mDNS等广播流量非常多很容易淹没真正要分析的流量。处理方法有两个抓包前用捕获过滤器排除not broadcast and not multicast抓包后加显示过滤器not arp and not nbns and not mdns and not llmnr也可以配合着色规则把广播包调成灰色注意力集中在业务流量上。6.5 分析无线网络抓包时的注意事项如果抓的是Wi-Fi流量Wireshark默认抓的是带有无线头RadioTap的帧。分析时注意无线空口重传机制会导致重复包和重传包数量偏多不一定是实际网络故障如果只关心IP层以上的内容可以用wlan.addr和ip.addr配合过滤在使用信标帧Beacon评估信号覆盖时用wlan.fc.type_subtype 8过滤。6.6 如何快速确认某个包是哪个进程发出的Wireshark本身不直接显示进程号但可以用Windows资源监视器或者Linux的ss -tnp对照四元组来查# Linux下根据端口查进程 ss -tnp | grep 8080 # Windows下用netstat netstat -ano | findstr 8080先确定会话的四元组源IP、源端口、目标IP、目标端口再到系统里查端口对应的PID然后到任务管理器里看是哪个进程。这个方法在排查到底是谁在发垃圾请求时特别好用。6.7 抓不到本地回环流量很多人用Wireshark抓本机访问本机服务比如127.0.0.1的流量发现怎么也抓不到。原因是回环流量不走物理网卡需要安装Npcap时勾选Support loopback traffic选项然后在Wireshark里选择Loopback: lo这个虚拟网卡接口进行抓包。6.8 数据包时间间隔显示异常大如果Wireshark显示相邻包间隔几秒甚至几十秒先排除自己的判断误区检查是否启用了名称解析导致卡顿会拉长显示时间检查网卡的TCP时间戳是否异常确认抓包机上是否有其他高负载进程比如杀毒软件全盘扫描影响了抓包软件的实时性。6.9 使用tshark做命令行自动化分析当抓包文件很多、手工处理太慢时可以改用tshark做一些常规指标统计效率提升明显# 统计TCP重传数量 tshark -r capture.pcapng -Y tcp.analysis.retransmission | wc -l # 统计HTTP 500数量 tshark -r capture.pcapng -Y http.response.code 500 | wc -l # 查看每个TCP流的RTT平均值需要开启rt tshark -r capture.pcapng -q -z io,stat,0,AVG(tcp.analysis.rtt)tcp.analysis.rtt这些命令拿到结果比打开Wireshark翻半天快得多适合批量处理多个抓包文件。6.10 实战心得排查效率提升的三个小习惯最后分享三个我个人一直坚持的习惯确实帮我省了很多时间习惯一抓包文件第一时间打标记抓包结束后立刻在注释字段里记录抓包时间、抓包位置、系统特征、问题现象。别高估自己的记忆力三天后再看抓包文件没有注释你根本想不起当时的环境。习惯二分析前先跑一遍专家信息不管多大的抓包文件先花一分钟看专家信息它会自动把最严重的问题顶上来。很多次我都是在专家信息里直接找到罪魁祸首的省去了大量手工过滤的时间。习惯三把过滤条件保存为按钮Wireshark的显示过滤器按钮栏支持自定义把我常用的一批过滤器tcp.analysis.retransmission、http.response.code 400、tcp.flags.reset 1、dns.time 0.1等存成预设按钮下次排障一键切换效率翻倍。7. 总结从抓到根因的路径回顾回顾整套分析方法核心其实只有一句话**确定问题边界层层缩小范围直到找到那个最原始的异常包。**先通过统计和专家信息判断问题发生在链路层、传输层还是应用层再通过会话与流分析锁到具体连接最后用协议细节解释为什么慢、为什么断、为什么错。Wireshark功能再强大也只是个工具真正的价值在于分析和判断能力。只要能熟练掌握从宏观到微观的分析顺序大多数网络问题都难不倒你。最后分享一个我个人的习惯每次排查完一个完整问题我会把抓包文件、过滤条件、根因分析和解决过程整理成一份简短笔记。久而久之这就变成了自己专属的排障手册以后再遇到类似问题直接按图索骥速度快得超乎你想象。下次再打开Wireshark别再瞎翻包了照着这套顺序一步步来问题就能浮出水面。
