干这行久了，你会发现一个特别尴尬的现象：很多人一打开Wireshark就兴奋，鼠标咔咔点两下开始抓包，抓了一堆数据回来，盯着那一屏花花绿绿的十六进制发呆，完全不知道从哪儿看起。要么就是凭感觉点开几个看起来可疑的包，翻两下就关掉，最后只能得出一个“网络好像有问题”的结论。这套路我太熟了，因为我早年也是这么瞎翻过来的。
后来被几个线上事故教育过几轮，我才慢慢总结出一套Wireshark的标准分析顺序。这套流程不一定多花哨，但它能保证你拿到任何一个抓包文件，都能有条理地从一堆乱麻里找出真正的问题——从我该在哪儿抓，到抓到以后先看什么、后看什么，再到怎么一步步逼近根因。这篇文章我就把完整的分析顺序掰开揉碎讲清楚，适合刚入门不知道怎么下手的兄弟，也适合那些已经会抓包但分析没章法的朋友。看完你至少能少走三个月弯路。
1. 先别急着抓包：搞清楚你到底要解决什么问题
1.1 抓包前必须想明白的三件事
我一直觉得，抓包这个动作本身一点都不难，难的是你抓之前有没有想明白三个问题：抓到包以后打算回答什么？在哪个位置抓最合适？抓多久、抓多大？
这三个问题没想清楚，你抓回来的包大概率是废的。就拿“网页打开慢”这个最常见的诉求来说，慢的原因可能出在DNS解析、TCP握手、TLS协商、HTTP请求排队、服务端处理、客户端渲染，每一个环节表现到抓包里都是不同的特征。你要是没有目标地随便抓一通，回头分析的时候就会发现手里全是数据，但没有一条能直接指向真相的线索。
所以我的建议是，动手之前先在纸上或者脑子里把问题定义清楚。比如：“用户反馈访问某接口要8秒，我想确认这8秒到底消耗在哪个环节。”这句话就是一根很清晰的主线，后面所有分析动作都围绕它展开。
1.2 抓包位置不对，努力全白费
抓包位置是整个排查里最容易被忽略、影响却最大的一环。你在客户端抓、在服务端抓、在中间交换机端口镜像抓，看到的包内容基本一样，但看到的视角完全不一样。
客户端抓包能看到应用发出的原始请求，能看到DNS解析耗时，能看到连接建立耗时，但看不到服务端内部的处理情况。服务端抓包能确认请求有没有到服务器、服务器响应快不快，但看不到客户端侧的网络状况。两边各抓一份，对比同一个TCP流的时序，是定位“问题出在哪一端”的最有效手段。
这里要多说一句，物理位置也很关键。同一台机器上，你在有线网卡上抓和无线网卡上抓，结果可能天差地别。无线网卡默认只能抓到自己这条链路的数据流，除非进监听模式，否则抓不到其他终端的包。你要是想抓局域网内其他设备的包，要么用交换机的端口镜像，要么加个Hub或者用支持监听模式的无线网卡，不然什么技巧都白搭。
1.3 抓多久、存多大，提前规划好
抓包时长和文件大小不是越多越好。Wireshark默认把所有包都缓存在内存里，抓到一定程度机器会卡，把系统搞到假死也是常有的事。
我一般这么处理：先用捕获过滤器（Capture Filter）把范围缩小，只保留跟问题相关的流量。比如排查某个IP的HTTP问题，就只抓这个IP的TCP 80和443端口，别把整个公司内网的全部流量都抓下来。然后设置环形缓冲文件，比如每个文件100MB，保留10个文件，这样既能覆盖足够长的排查周期，又不会把磁盘撑爆。
注意：捕获过滤器和显示过滤器是两套完全不同的语法，前者用BPF语法，在抓包之前生效，先把不想要的流量丢掉；后者是Wireshark内置语法，在抓包之后对已保存数据做筛选。很多人上来就输
ip.addr == 192.168.1.1，这个其实是显示过滤器，如果写在捕获过滤器里就会直接报错。
2. 抓包的正确姿势：捕获、保存与基本的看包素养
2.1 捕获过滤器用起来，抓包效率翻倍
捕获过滤器看着不起眼，但它是决定你抓包文件质量的第一道关卡。语法就是标准的BPF，常用的也没几个：
- 只抓某个主机的流量：
host 192.168.1.100 - 只抓某个网段的流量：
net 192.168.1.0/24 - 只抓某个端口的流量：
port 80 or port 443 - 抓特定协议的流量：
tcp、udp、icmp - 排除广播和多播：
not broadcast and not multicast
把这些组合起来，比如排查某台机器访问数据库慢的问题，就可以写host 192.168.1.100 and port 3306，抓回来的包全部跟目标问题相关。文件小、干扰少、分析的时候心情也好。
2.2 时间显示和保存习惯，影响后续所有分析
这个细节我踩过好多次坑。Wireshark默认显示的是每个包被抓到的绝对时间，比如10:32:15.123456。但在分析延迟问题时，我关心的往往是“这个请求发出后，过了多久收到响应”，用绝对时间很难一眼看出来。
解决很简单：在菜单栏「视图 → 时间显示格式」里，把时间列切换成「相对于第一个包」（Seconds Since First Captured Packet）。这样时间列就会显示0.000、0.428、1.256这种相对秒数，任何两个包之间的间隔一目了然。尤其是看TCP握手耗时、HTTP请求响应间隔、重传时间跳变，这个设置几乎必不可少。
保存抓包文件也有讲究。默认保存成pcapng格式没问题，它支持了更多元数据信息。但如果你的文件是要给同事或者给其他工具用的，最好另存一份传统pcap格式，兼容性更好。文件命名上要带上日期、时间、抓包位置和用途，比如20250115-client-https-slow.pcapng。你别嫌麻烦，等你一周后回来看一个叫抓包1.pcapng的文件时，你会感谢现在的自己。
2.3 显示过滤器的基本功，先把这20个背熟
分析抓包文件，90%的时间都在跟显示过滤器打交道。这些语法你不需要背太多，但常用的必须形成肌肉记忆。我列一份自己日常用得最多的：
| 目的 | 过滤器写法 |
|---|---|
| 按IP筛选 | ip.addr == 192.168.1.100 |
| 按端口筛选 | tcp.port == 443 |
| 只看HTTP流量 | http |
| 只看DNS流量 | dns |
| 只看TCP重传 | tcp.analysis.retransmission |
| 只看TCP乱序 | tcp.analysis.out-of-order |
| 只看零窗口 | tcp.analysis.zero_window |
| 查看TCP流 | tcp.stream eq 0 |
| 按IP和端口组合 | ip.addr == 192.168.1.1 && tcp.port == 443 |
只要你学会了ip.addr、tcp.port、tcp.stream这三板斧，配合&&、||、!这几个逻辑运算符，绝大多数场景都能应付。再高级一点的用括号做优先级，比如(ip.addr == 192.168.1.1 || ip.addr == 192.168.1.2) && tcp.port == 80，这种组合式过滤在分析客户端-服务器两端流量时非常常用。
3. 拿到包以后，先看宏观再管微观
3.1 别急着点开单包，先看统计概览
这是最容易犯的毛病。客户把抓包文件发过来，你双击一开，马上拉着进度条到处点，看到哪个包顺眼就点哪个，这种方法根本找不到根因。
我的标准动作是，文件一打开，先看「统计 → 摘要」。这一页会告诉你这次抓包持续了多长时间、一共抓到多少个包、平均每秒多少包、平均速率多少Mbps，关键信息是末尾的“丢包率”——如果显示有丢包，说明抓包过程中交换机或网卡就有拥塞，这个文件本身可能就不完整，分析结论要打折扣。
接着看「统计 → 协议分级」。这张表会把所有协议按层次列出来，比如以太网→IPv4→TCP→HTTP，右侧是帧数、字节数和占比。通过协议分布，你能快速判断这份流量是以什么为主。如果TCP下面直接挂着大量TLS，那是加密流量，应用层内容看不到，只能从握手和流量特征入手分析；如果HTTP占比很高，那就能直接看请求响应内容了。
3.2 会话、端点和流量图：把大海捞针变成按图索骥
接下来看「统计 → 会话」和「统计 → 端点」。会话列表按IP对IP、端口对端口显示了每对通信双方交换了多少数据。在慢速访问问题里，这能瞬间告诉你是跟哪台服务器的哪条连接消耗了最多时间。
然后一定要打开「统计 → IO图表」。这个图以时间为横轴、流量速率或包数为纵轴，把整个抓包时段的流量走势铺开。看这个图能获得整体节奏感：流量是匀速的还是有明显的尖峰？故障发生时有没有流量突增或突降？排查循环播放视频卡顿问题的时候，你还能看到吞吐量有没有周期性波动，这往往是缓冲或者限速的特征。
3.3 专家信息：Wireshark其实已经帮你标好疑点了
很多人不知道Wireshark有一个特别有用的功能叫「分析 → 专家信息」（Expert Information）。它相当于一个自动诊断引擎，已经把你抓包文件里所有异常情况做了分类和整理。
打开以后你会看到几类标签：错误（Error）、警告（Warning）、备注（Note）、聊天（Chat）。点开错误标签，里面往往列着TCP校验和错误、TCP重传、重复ACK这些明确的异常项。直接双击对应条目，Wireshark会跳到出问题的那个包。这一下就能省去大量手动排查时间。
我自己的经验是，拿到任何抓包文件，先看专家信息里的错误和警告，基本能判断大方向。就算最后发现专家信息标注的“错误”不是根因，但它至少帮你划定了重点怀疑范围，比无头苍蝇式翻包强太多。
4. 深挖TCP：建立连接、传数据、断开连接，每一个阶段都有戏
4.1 三次握手阶段，识别连接建立慢或失败
TCP连接的过程经典到不能再经典：客户端发SYN，服务器回SYN-ACK，客户端再回ACK。分析这个阶段，抓的点有三个。
第一是看SYN有没有得到响应。如果客户端连续发送多次SYN重传都没有收到SYN-ACK，说明服务器根本不可达，或者被防火墙策略挡住了。SYN重传间隔通常是1秒、2秒、4秒这样指数增长，你看到这种规律性重传，问题大概率出在中间链路或服务端不监听该端口。
第二是看收到SYN后多久回SYN-ACK。在「时间显示设为相对时间」的前提下，找到SYN包和SYN-ACK包之间的时间差，这就是一次握手的服务端响应时间。如果这个值超过几百毫秒甚至达到秒级，那就是服务端处理能力有问题，客户端这边再折腾也没用。
第三是注意RST包。收到RST连接被直接重置，说明端口不可达或者服务主动拒绝。RST如果在握手完成前出现，检查防火墙规则；如果在数据传输中频繁出现，查应用层协议逻辑，很多服务端框架的超时设置也会直接发RST断连。
4.2 数据传输阶段，重传、乱序、零窗口三件套
数据传得怎么样，这是分析过程中信息量最大的部分。常见的异常在专家信息里都有标记，我习惯直接输入过滤器tcp.analysis.flags，把所有有问题特征的包一次性筛出来，然后逐个看。
TCP重传是全网最常见的网络问题特征。一个包发出去后，超过重传超时时间没收到ACK，发送方会重新发一遍。重传会造成应用层数据延迟，表现为下载速度上不去、页面加载卡顿。具体看的时候要关注重传的序列号和原包是否一致，重传一次还是反复重传，重传间隔是否规律的指数退避。如果大量重传集中在某条链路上，很可能是路径上丢包严重，或者是MTU设置不对导致分片被丢弃。
TCP乱序和重复ACK通常是丢包导致的伴生现象。当接收方发现序列号不连续，会立即重复ACK告诉发送方自己期望的序列号，同时把收到的乱序包暂时缓存。出现这种情况先怀疑路径丢包或负载均衡把同一个TCP流的包打到了不同后端。
零窗口表示接收方缓冲区满了，应用层来不及消费数据。这个问题的根因往往不在网络上，而在应用程序本身——接收端处理太慢，或者接收端内存分配太小。要是过滤tcp.analysis.zero_window发现大量零窗口通告，赶紧从应用侧入手查，别在网络上死磕。
4.3 挥手阶段与连接异常，看的是“这连接死没死透”
TCP断开过程有标准的四次挥手，但实际分析里更常见的是连接异常断开。比如直接收到RST而不是FIN，说明对端程序还在但突然中止；或者连接长时间处于ESTABLISHED状态，但已经不发任何数据，那可能是超时慢、保活机制失效。
另外别忘了看TCP的Window Scale选项。这个值决定了TCP窗口的最大上限。如果抓包文件里服务器SYN-ACK里没有Window Scale选项，或者窗口缩放因子为0，那这个连接的有效窗口大小会被极大限制，带宽再大也用不满，这在高带宽长延迟链路（也就是所谓的BDP很大）的场景会出现传输速率上不去的现象。
4.4 TCP时序图：比看表格更直观
Wireshark里有一个非常有用的图形分析工具，在「统计 → TCP流图 → 时序图(Stevens)」，画出来每个TCP流的序列号变化曲线。
这个图怎么看？正常传输时序列号随时间稳步增长，曲线平滑向上。如果曲线出现同一序列号的反复横跳，那就是TCP重传；如果曲线长期水平不变，说明数据在某个节点卡住了。配合左边的数据点数值，你能直观地看到传输速率什么时候掉下去了、什么时候恢复正常。
我拿到任何一个涉及“慢”的抓包文件，都会先画一张这个图。眼睛扫一遍，传输哪里停顿了、哪里有退避，立马有数。这比盯着几十个包清单里找规律高效得多。
5. 实战复盘：从一个网页加载慢的抓包文件，一步步定位根因
5.1 案例背景与初步观察
之前遇到一个典型的案例：用户反馈内网某个管理页面要十几秒才能打开，但其他网页都正常。我在用户电脑上的有线网卡抓了一份包，过程大概是11秒，共抓到3800多个包，没有捕获丢失。
按标准流程，我先把抓包文件拖进Wireshark，然后「统计 → 协议分级」。一眼扫过去，TCP下面的HTTP占了80%以上的字节，没有TLS加密——说明这个页面还是老式HTTP明文传输，可以直接分析应用层内容。紧接着看「分析 → 专家信息」，有几个Warning：一个TCP ZeroWindow，若干TCP Out-of-Order，没有疯狂的重传风暴。
初步判断：这不是一个链路恶意掉包的网络故障，更像是应用层或传输层局部异常。
5.2 按TCP流逐个排查，锁定最慢的那条连接
接着看「统计 → 会话」，里面列了一堆IP对。我按字节数排了个序，发现浏览器和一台应用服务器之间的会话数据量最大，但持续时间也最长。我选中这条会话，右键「追踪TCP流」，把这条连接从SYN开始，一直到数据传输过程的全部包按照编号抱出来。
过程如下：
- 三次握手完成得很快，SYN到SYN-ACK仅用了0.8毫秒，说明网络到服务器的基础链路没问题。
- HTTP请求发出后，服务器大约在2.3秒后才回了第一个数据包。
- 但这第一个数据包只有一点点，后面跟着又停顿了1.5秒，才继续发下一段数据。
- 整个页面加载被拆成了好几段，每段之间都有几百毫秒到两秒不等的间歇。
看到这种“响应快，数据却像挤牙膏”的模式，网络丢包重传的嫌疑就很小了。我顺便确认了一下有没有重传，输入tcp.analysis.retransmission，只有两条，频率很低，说明链路本身干净得很。
5.3 往应用层深挖，真相还在后头
虽然这是HTTP明文，但是直接看HTTP层也要注意方法。我添加显示过滤器http.request，把所有请求按时间列出来，很快发现一个规律：浏览器先请求页面主文档，然后在拿到主文档后，浏览器继续发了一批CSS、JS、图片的请求。
问题出在哪？我看每一条请求的时间戳，发现浏览器是在主文档返回之后过了很久，才发出来后面的子资源请求。而服务器的响应本身并没有特别慢——凡是请求发出去，基本都几百毫秒内就有响应。
所以链条就清晰了：瓶颈不在服务端响应速度，而在客户端（浏览器）迟迟没有发起后续的子资源请求，或者服务器存在按顺序逐块返回数据的模式。我检查服务器返回的HTTP响应头，果然发现没有开启Keep-Alive，每个TCP连接只服务一次请求就关闭。这导致浏览器每次拉取JS、CSS都要重新建立TCP连接，并且受限于浏览器在同域名下并发连接数的限制，多个文件只能排队下载，时间全耗在来回握手上了。
5.4 根因结论，直接落地到可执行修复
到这里根因已经很明确了：
- 网络层没有丢包，TCP重传率极低，排除链路质量问题。
- 服务端响应单个请求的速度是正常的，排除数据库慢、程序处理慢等后端原因。
- 导致十几秒延迟的主因是：服务端未启用Keep-Alive，同时HTTP子资源请求被浏览器并发连接策略串行化，导致大量时间被连接重建和排队消耗。
修复起来就三件事：在服务器上开启HTTP Keep-Alive；把所有JS/CSS合并或做资源打包，减少请求数量；适当的静态资源加缓存头。改完之后页面加载压缩到2秒以内，效果立竿见影。
这个案例不是多高深的技术，但如果一上来就盯着某个包分析半天，很可能半路跑偏。按“概览→会话→TCP流→HTTP层”的顺序走下来，每一步都有依据，每一层都在收窄范围，这是分析抓包文件最舒服、最不容易漏的状态。
6. 排查Wireshark常见问题，顺手解决几个抓包路上的拦路虎
6.1 为什么我抓不到HTTP请求的内容？
最常见的场景是：抓包抓了一堆，过滤http却什么都没有，全是TLS。原因很简单，现在主流网站基本都用了HTTPS加密，HTTP的应用数据被TLS加密了，所以Wireshark里看不到明文HTTP层。处理思路分两种，一是如果你只是看请求URL和域名，过滤tls.handshake.extensions_server_name就能看到TLS握手里的服务器名称到IP的映射；二是如果确实需要解密内容，需要在浏览器或者客户端里配置Wireshark的调试证书，把SSLKEYLOGFILE导出给Wireshark，这样它就能解密TLS流量。注意这个操作只影响自己的抓包环境，对服务器和网络本身没有任何改动。
6.2 抓包过程中就把网卡抓死了，怎么避免？
抓包这个操作本质上是把网卡收上来的所有包都拷贝一份做处理，遇到大流量时CPU和内存都会冲高。解决办法就是用好捕获过滤器，尽量只保留必要的协议和主机范围；并且开启「选项 → 抓包文件 → 使用多文件模式」，设置好每个文件大小上限。实时抓包时不要让Wireshark在文件里同时做响应、解析和显示，太多功能叠加也会让性能雪上加霜。
6.3 抓到蓝牙、USB、无线网卡这些非传统网络流量时要注意什么？
Wireshark其实不只可以分析传统以太网和Wi-Fi。它支持USB抓包、蓝牙抓包、甚至一些物联网设备的串口流量分析，这对嵌入式开发和硬件调试特别有用。USB抓包需要在系统层面开启USBPcap这类驱动，蓝牙抓包则要选对蓝牙适配器并安装配套解析插件。抓这些流量的基本思路和TCP/IP一样：先看统计概览，再看协议分级，顺着异常标记深挖，只是链路层的解析方式和网络环境有差异。
6.4 几个省时间的操作习惯，我从天天抓包里攒出来的
最后分享几个单人全程开挂的小习惯。第一个是给常用过滤条件做按钮，Wireshark主界面下方有过滤器栏旁边的星标，可以把tcp.analysis.flags、http.request这种常用表达式收藏起来，以后一键切换。第二个是颜色标记规则的利用，默认Wireshark会把TCP重传、乱序的包底色标出来，你要是觉得不明显，自己去「视图 → 着色规则」调高对比度，扫包的时候余光一瞥就能发现异常区。第三个是用右键菜单里的「标记/取消标记」给关键包打标，配合Shift+Ctrl+N快速跳到下一个标记包，梳理事件顺序的时候非常顺手。
这些都不是什么高深功能，但天天用下来，能省掉不少低效操作。
我做抓包排障这么多年，最大的体会是：Wireshark再强，也替代不了分析者的思路。工具只是把数据摊开给你看，怎么从海量包里找到那个最有价值的点，靠的是一套严谨的流程——先定义问题，再选对抓包位置，然后从宏观统计切入，沿TCP流逐步下钻，最后在应用层锁定证据。你按这个顺序多练几遍，下次再有人拿着一堆抓包文件来问“帮我看看怎么回事”，你就能气定神闲地一步一步把他带向真正的答案了。
