干这行久了你会发现一个特别尴尬的现象很多人一打开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重传、乱序的包底色标出来你要是觉得不明显自己去「视图 → 着色规则」调高对比度扫包的时候余光一瞥就能发现异常区。第三个是用右键菜单里的「标记/取消标记」给关键包打标配合ShiftCtrlN快速跳到下一个标记包梳理事件顺序的时候非常顺手。这些都不是什么高深功能但天天用下来能省掉不少低效操作。我做抓包排障这么多年最大的体会是Wireshark再强也替代不了分析者的思路。工具只是把数据摊开给你看怎么从海量包里找到那个最有价值的点靠的是一套严谨的流程——先定义问题再选对抓包位置然后从宏观统计切入沿TCP流逐步下钻最后在应用层锁定证据。你按这个顺序多练几遍下次再有人拿着一堆抓包文件来问“帮我看看怎么回事”你就能气定神闲地一步一步把他带向真正的答案了。