1. 项目概述1.1 抓包到底是什么为什么要学它网络抓包分析是每个网络工程师、运维人员、安全从业者和后端开发者都绕不开的基本功。Wireshark作为这个领域最主流的开源工具能帮你把网线上跑的数据包原原本本“录”下来再逐层拆开看个明白。简单说它就是一个网络世界的“行车记录仪”——所有经过网卡的流量谁发的、发给谁、什么协议、内容是什么一目了然。我在一线的这些年遇到的服务卡顿、网页打不开、接口超时、视频花屏、设备掉线这类问题超过一半都是靠Wireshark定位出来的。有些问题你光看代码和配置根本看不出门道但只要抓一次包数据会告诉你真正的答案。比如某个接口偶发性超时服务端日志一切正常客户端却老是重试——抓包一看原来是中间链路把带了特定TCP选项的包丢了。这种问题不抓包你排查三天三夜可能都摸不着头脑。这篇文章我会站在一个实际使用者的角度把Wireshark从安装到实战的所有关键环节都过一遍。不会只讲菜单栏有哪些按钮而是告诉你真正干活时怎么用、遇到问题时怎么查、哪些坑是我反复踩过才总结出来的。无论你是刚入门的小白还是已经用过一段时间想提升排查效率的同行这篇文章的内容应该都够用。1.2 这篇文章能帮你解决什么问题这篇文章的核心目标有三个用最短时间掌握Wireshark的完整操作链路选网卡、开始抓包、停止抓包、保存文件、过滤分析。理解TCP/IP协议栈在真实数据包里的呈现方式做到“看得懂包里的故事”。掌握几套实战排查方法遇到网络问题时能独立用抓包定位到具体环节。我刻意不写成一本文档翻译稿。菜单里每个按钮是什么官方文档写得很清楚没必要抄一遍。我更想分享的是在真实故障场景里怎么组合使用这些功能——这部分的经验文档里通常找不到。2. 抓包环境准备与核心配置2.1 安装环节的几个实际取舍Wireshark的安装本身不复杂官方直接下载对应平台的安装包即可。但有几个细节需要注意Windows平台安装时安装向导会询问是否安装Npcap新版或WinPcap老版本。这里务必选择安装Npcap。Npcap是当前Windows下抓包驱动的事实标准支持WinPcap API的兼容模式而且对Windows 10/11的适配比WinPcap好得多。安装时有个关于“支持802.11无线流量捕获”的选项如果网卡和驱动支持可以勾上否则保持默认。macOS和Linux平台也很简单。macOS直接下载官方.dmg安装Linux用户如果用的是Debian/Ubuntu系执行sudo apt install wireshark即可。Linux安装完会有一个交互式配置——是否允许非root用户抓包。在产品环境里我建议选择“是”并通过dpkg-reconfigure wireshark-common把当前用户加入wireshark组避免每次都要sudo方便日常抓包。注意如果在Linux里用sudo wireshark启动会弹出一堆插件和配置权限警告而且后续保存文件、读取配置文件都可能出现权限问题。所以把普通用户加入wireshark组比每次sudo要省心得多。2.2 抓包前必须做的网卡判断打开Wireshark后会看到一个网卡列表每个网卡都有实时的流量波形图。很多新手在这里就开始犯迷糊——到底该选哪个网卡判断标准其实很简单有线连接看以太网网卡无线连接看Wi-Fi网卡。如果是在虚拟机里面抓包要选虚拟机里的虚拟网卡而不是宿主机物理网卡。远程抓包时需要在目标机器上装抓包组件本地Wireshark只是作为前端展示。有个场景我要特别提醒如果你用笔记本连着Wi-Fi去抓无线环境里的包会发现大量802.11管理帧Beacon、Probe Request等看不到只能看到数据帧。这是因为普通无线网卡的驱动默认不进入“监听模式”抓到的只是发给本机的数据。要做真正的无线报文分析得用专门支持监听模式的网卡和驱动比如某些USB外置无线网卡配合Kali或者Windows下的特殊驱动。这个方向比较深初学阶段不用纠结。选择网卡后双击网卡名称或点击左上角的蓝色鲨鱼鳍图标就会进入实时抓包状态。界面上会快速滚动各种颜色的报文列表——这个列表就叫“数据包列表窗格”。2.3 长期抓包的滚动文件模式默认情况下Wireshark会把所有数据包存在内存里抓得越久内存占用越大。长时间无人值守抓包时强烈建议使用“多文件滚动写入”模式。在“捕获选项”对话框里找到“输出”设置可以设置每个文件的大小限制比如10MB或100MB。文件数量上限比如10个或50个文件。触发滚动的方式按文件大小、按时间、按数据包数量。这样设的好处是磁盘不会被撑爆而且保留的是最近一段时间的数据。比如我要定位一个“凌晨3点随机断网”的问题就设置按文件大小滚动保留最近24小时数据第二天早上起来看最后几个文件里有没有异常TCP重传或断开记录。3. 包列表里的“色谱”—如何快速读懂抓包界面3.1 列表窗格、详情窗格和字节窗格的分工抓包开始后你会看到三个纵向排列的区域各司其职数据包列表窗格顶部所有报文按时间顺序排列每一行是一个数据包包含序号、时间、源地址、目的地址、协议、长度、信息摘要。协议详情窗格中部选中一个包后这里会按协议层展开从物理层到应用层逐层解析左侧有箭头可以展开每一层的字段。字节窗格底部展示数据包的原始十六进制字节和对应的ASCII字符cte直接对应到详情窗格的某个字段。这三个区域是联动的。你在中部详情窗格点击某个字段底部字节窗格对应的字节会高亮。多数时候我们只看前两个就够了真正分析二进制内容时才关注字节窗格。3.2 包列表各列的真正用途包列表的列不是摆设每个都值得理解No.包的序号从1开始递增。注意这是抓包会话内的计数值不是TCP序号。Time包被抓到的相对时间默认从抓包开始计算。可以对时间列重新设置显示模式比如显示为“自上一个包到此包的间隔”这特别适合分析重传间隔。Source / DestinationIP地址。默认显示可能经过了名称解析就是自动把IP反解成域名——这个功能建议关闭既拖慢速度又会误导分析见3.3。Protocol协议类型。Wireshark会根据端口号和协议特征自动识别TCP、UDP、HTTP、TLS、DNS、ARP等等都会直接标出来。Length包长以太网帧的总长度包含头部和尾部校验。Info最重要的信息列用一句话总结这个包干了什么。比如“SYN, ACK, Seq0 Ack1”。3.3 三个默认就要关闭的“友好功能”Wireshark默认开启了名称解析实话说初学阶段挺好看但实际排障时存在三个明显问题DNS反解增加耗时大量陌生IP的环境里每抓一个包都要去问DNS服务器延迟很明显。结果不稳定同一IP在不同时间可能反解出不同域名干扰判断。误导新手看到源地址显示成“server01.local”但真正出故障的其实是某个内网IP你根本不知道它在哪台机器上。我的习惯是从“视图”菜单里把“名称解析”的三个子选项物理地址、网络地址、传输端口全部关掉只看纯数字IP和端口号。这样干净利落很多。技巧平均包量很大的环境里每秒几千甚至上万个包开着名称解析会导致界面明显卡顿。关掉后流畅度立竿见影。3.4 时间列的精确定位技巧抓包分析经常需要跟日志时间对齐。比如应用日志显示“15:32:18.456 请求超时”你需要在包里找到对应时间点发生了什么。这时建议把时间列显示格式改成“自1970年1月1日以来的秒数”或“绝对日期和时间”并在“视图-时间显示格式”里选择“带日期的时间”。然后根据日志时间直接一目看过去基本就能锁定区间。还有一种用法查看两个包的精确间隔。选中第一个包再按住Ctrl选中第二个包底部状态栏会自动显示“两个包之间的时间差”。在做TCP重传间隔分析或响应时延分析时这个功能太好用了不需要自己拿计算器去减。3.5 数据包着色规则——为什么有些包是红的Wireshark默认给不同协议和异常情况配了颜色。比如浅紫色是TCP流量天蓝色是UDP绿色是HTTP。但这里真正需要注意的是着色规则提示的异常黑色TCP问题包比如Checksum校验错误。红色TCP重传包Retransmission。浅红色TCP快速重传、乱序、重复确认等异常事件。黄色TCP重传后的恢复情况有时也表示某种警告。这些颜色不是装饰。当你看到一个红色包基本说明网络里有重传——重传意味着丢包或者时延异常。看到黑色包基本说明有包在传输中被破坏了。在正常内网环境里微量重传是允许的但如果重传比例高网络质量就是有问题了。你可以在“视图-着色规则”里自定义这些规则。比如我习惯给DUP ACK重复确认单独加一个橙色调因为它是定位丢包的关键信号。4. 过滤器的正确用法——捕获过滤器与显示过滤器4.1 先区分两种性质完全不同的过滤器Wireshark里的过滤器分两种初学者常搞混**捕获过滤器Capture Filter**的作用发生在抓包阶段由底层驱动Npcap/ libpcap执行。它把不符合条件的包直接丢弃不写入内存也不写入文件。它的语法属于BPFBerkeley Packet Filter比较原始。**显示过滤器Display Filter**的作用发生在分析阶段只在界面中过滤显示底层的包全部都在。它的语法是Wireshark自创的有自动补全好写得多。简单理解捕获过滤器是“进门前选人”显示过滤器是“进门后翻名单”。实际工作中我极少使用捕获过滤器原因很简单——你不知道后续会需要分析哪类包把所有包都抓下来最稳妥。只有在一种情况下必须用抓包量极大且磁盘空间紧张时比如持续抓上G级别的流量才考虑用捕获过滤器缩小范围。4.2 最常用的捕获过滤器写法捕获过滤器的语法是协议 方向 类型的组合方向常见的是src源、dst目的、src or dst任一端、src and dst两端都要常见写法# 只抓某个主机的流量进或出 host 192.168.1.100 # 只抓某个网段 net 192.168.1.0/24 # 只抓80端口的TCP流量 tcp port 80 # 抓HTTP的POST请求80端口且数据包中包含POST字样 tcp port 80 and (tcp[((tcp[12:1] 0xf0) 2):4] 0x504F5354) # 排除某台主机的流量 not host 192.168.1.100这些写法在“捕获选项”界面里可以直接选预置模板不用死记。但我要强调一点如果你用捕获过滤器太激进导致关键包被丢弃后面分析和重放都会无从下手。所以宁可抓全、抓大也不要贪图省事从一开始就滤掉太多。4.3 显示过滤器——每天都要用的核心技能显示过滤器是Wireshark分析阶段的“查词框”位于工具栏下方输入时自动补全。它的语法核心逻辑是“字段 操作符 值”操作符支持、!、、、contains、matches等。我最常用的几组按场景列出# 只看某个主机 ip.addr 192.168.1.100 # 只看某个IP之间的对话 ip.addr 192.168.1.100 ip.addr 192.168.1.101 # 只看TCP协议 tcp # 只看TCP端口源或目的为443 tcp.port 443 # 只看HTTP请求 http.request # 只看DNS查询 dns.flags.response 1 # 只看重传的包 tcp.analysis.retransmission # 只看某个时间段的包相对时间大于5秒 frame.time_relative 5几个容易踩坑的点我在这里单独提一下ip.addr 1.1.1.1和ip.src 1.1.1.1的区别ip.addr是“源或目的任意一个匹配”ip.src是锁定源地址。排查双向通讯问题时ip.addr很顺手但如果你只想看某个方向就必须用ip.src或ip.dst。tcp.port 80的问题它匹配源端口或目的端口如果客户端和服务器都用了80端口倒是没问题但实际场景里服务端端口80、客户端随机端口这个条件会同时匹配到大量反向包。如果想精确看某个方向用tcp.srcport或tcp.dstport。http和http.request的区别http匹配所有HTTP报文包括响应http.request只匹配请求行。分析并发请求时建议用http.request配合tcp.stream一起看会话。4.4 TCP流跟踪——一键看懂一次完整对话在包列表里选中任意一个TCP包右键点击“追踪流”选择“TCP流”会弹出一个独立的窗口把这次TCP会话的所有内容按顺序拼在一起自动去掉TCP头部的开销把净载荷按正常时序合并显示。这个功能在做HTTP/DNS/SMTP这类文本协议分析时效率极高。比如一个HTTP请求你能直接看到请求头、请求体、响应头、响应体不用一条条翻包。而且流跟踪窗口里的内容可以切换显示格式ASCII、HEX转储、C数组等。注意一点如果流量经过TLS加密追踪流窗口里只能看到乱码因为载荷已加密。这种情况下需要先解决TLS解密问题具体做法在第6章单独讲。5. 从三次握手到连接关闭——TCP协议帧的实战解析5.1 SYN、SYN-ACKACK——每次TCP连接都要过一遍的三步曲无论你用什么应用只要走TCP连接建立阶段就一定有三步客户端发SYN、服务端回SYN-ACK、客户端再回ACK。在Wireshark里看到完整三步说明双向通路没问题任何一步缺失或者重复都能快速定位故障方向。举一个我实际处理过的例子某公司内部系统的页面偶尔加载极慢服务端部署在另一栋楼。抓包发现客户端发出SYN后服务端一直没有回SYN-ACK挂了约3秒后客户端主动超时重传SYN。这说明什么SYN能发出去但服务端的SYN-ACK没回来。由于在同一网段内先排查防火墙——果然防火墙上有一条过期的安全策略把SYN-ACK这类“外部先响应”的流量给丢弃了。再举一个场景如果客户端发SYN后迟迟没有响应服务端也不回而你又确认服务端口在监听——把抓包点移到服务端本机再看一次。如果服务端本机能抓到SYN但应用没有响应问题多半出在服务端自身的半连接队列或者全连接队列溢出。5.2 标志位的作用与Wireshark标识TCP报文头里的Flags标志位是每次握手和断开时最关键的字段。Wireshark的Info列会把这些标志位直接缩写显示出来SYN请求建立连接。ACK确认对方数据。PSH ACK推送数据表示数据包中有实际载荷。FIN ACK主动关闭连接。RST异常终止连接常见于端口不监听、程序主动拒绝、TCP连接发生异常超时。我最看重的是RST包。在很多故障复盘里RST的“凶手”身份非常明显但需要结合两边的抓包才能判断是谁发的、因为什么发。比如服务端对客户端发来的包回RST常见原因包括服务端口根本没有进程监听。服务端口有进程但进程崩溃/假死导致协议栈直接拒绝。TCP连接因超时被端侧清理后续数据到达后触发RST。防火墙截断了连接后伪造RST给两端。拿到RST包后先看RST包是谁发出来的再往前翻几个包看这个连接之前干了什么基本上就能定位到原因。5.3 四次挥手与连接关闭的疑难点TCP拆除连接时正常情况是四次挥手主动关闭方发送FIN ACK对方回ACK对方再发送FIN ACK主动方回最后的ACK。实际抓包里经常看到的“变体”有两种同时关闭双方几乎同时发FIN这时需要各自回应ACK总包数就不同。一条FIN ACK合并很多协议栈会把第二个FIN和中间的ACK合并成一个包发出于是只看到三次挥手。还有一种常见现象连接建立后一侧直接发RST而没有FIN。这通常意味着应用层异常退出、socket被强制关闭或者L4负载均衡探活失败后强制清理。在排查长连接掉线问题时FIN和RST是两种完全不同的语义别混为一谈。5.4 TCP序号与确认号——看包时最容易忽略的线索TCP是可靠传输靠的就是Sequence Number序号和Acknowledgment Number确认号。客户端发出一个包Seq100, Len10意味着这10字节的序号从100到109。服务端收到后回Ack110意思是“你下个包从序号110开始发”。Wireshark默认把TCP序号做了“相对序号”显示从0开始数大大方便阅读。在做大文件传输慢问题的分析时我会重点观察两种异常未按顺序到达乱序抓包中表现为后续包序列号和前序包的序列号不连续。这意味着接收方需要缓存等待有效吞吐下降。重复确认DUP ACK接收方检测到序号空洞反复用同一个ACK确认号催发送方。当收到连续三个相同ACK时发送方触发快速重传。遇到这两类现象我会先确认是单点现象还是全网普遍现象。单点大多和处理性能或无线链路相关全网普遍就要看交换机端口流量、CRC错误计数等物理层指标。6. 应用层协议实践——HTTP、DNS与TLS的抓包分析6.1 HTTP排障状态码之外的隐藏信息Web开发者的日常绝对离不开HTTP抓包。很多人只看浏览器开发者工具里的“网络”栏但那只能看本机发的HTTPS请求如果要看清链路中间发生了什么必须回到Wireshark。HTTP分析时我常做这几件事用http.request过滤出所有请求按时间线看请求发起频率。用tcp.stream eq 编号跟随某一个请求的完整生命周期从TCP握手到HTTP响应。看响应的时间间隔——在流跟踪窗口里请求发出后到响应回来之间的时间能区分是网络慢还是业务处理慢。一个典型判例本地开发环境请求一个接口耗时3秒浏览器里看是在等响应TTFB很长但服务端日志说处理只要50毫秒。Wireshark一抓发现TCP握手完成后的第一个数据包HTTP请求发出了但服务端迟迟不回包。继续翻发现请求包后被服务端回了一个TCP零窗口通知——服务端的接收缓冲区满了。查看服务端程序原来是负责读socket的线程堵住了没人消费数据。这个场景里HTTP层面完全看不出问题但TCP窗口告诉你一切。6.2 HTTP状态码与Wireshark的对应在包列表里看到HTTP响应时Info列会直接显示状态码。比如HTTP/1.1 200 OK正常。HTTP/1.1 301 Moved Permanently重定向注意查看Location头。HTTP/1.1 404 Not Found路径有问题。HTTP/1.1 499 Client Closed Request这是某些WEB服务返回的特殊状态表示客户端在服务端响应前断开了连接。遇到404要看请求的URL路径和实际服务端路由是否一致遇到499要重点抓客户端连接断开的那一刻看看是不是超时配置、浏览器主动取消或者中间代理提前断开。6.3 DNS抓包解析慢和解析失败怎么定位DNS问题的表现经常是“网页打不开”或者“第一次访问很慢”。抓包时先过滤dns看看查询包和响应包是否成对出现。关键要点一次正常的解析流程是客户端发A记录查询DNS服务器回A记录响应。如果只有查询没有响应说明DNS服务器没有回包或者被防火墙拦截。如果响应里No such name说明域名本身不存在或解析记录被删了。如果响应时间很长几百毫秒以上看响应包里的DNS服务器IP确认是本地区递归DNS还是公共DNS。还有一个容易忽略的点DNS缓存的存在让故障很难复现。假设某次解析失败之后一个小时内所有请求都走本地缓存抓包看解析都很正常。建议清缓存后再抓。Windows下执行ipconfig /flushdnsLinux下执行systemd-resolve --flush-caches或重启systemd-resolvedmacOS下执行sudo dscacheutil -flushcache。6.4 TLS解密——一把钥匙打开加密世界HTTPS流量默认是密的Wireshark直接看只能看到TLS握手和加密数据。但有一个每一版本都支持的办法利用环境变量导出“会话密钥”。原理是TLS 1.2/1.3握手时客户端/服务端会生成会话密钥用于对称加密。把会话密钥记录到文件里Wireshark就能用它解密抓到的TLS流量。操作步骤以Chrome为例在系统环境变量里新建变量SSLKEYLOGFILE值设为某个可写的文件路径比如/home/用户名/sslkeys.log。重启浏览器访问HTTPS网站。Wireshark的“首选项-Protocols-TLS”里把(Pre)-Master-Secret log filename指向同一个文件。重新抓包或者打开之前抓的文件TLS载荷会直接以明文显示。这个方法在开发联调、排查HTTPS接口问题时非常救命。因为这个方法需要浏览器或客户端程序支持导出密钥很多自研客户端程序并不支持。不支持时也有后备方案——在服务端用反向代理解密后再转发给抓包器或者直接在服务端直接抓应用进程发给本机回环的明文流量。7. 实战场景拆解——三套排障思路直接抄作业7.1 场景一网页加载慢怎么定位是哪个环节的问题某次接到报障业务后台页面打开要10秒左右其他页面都正常同一台服务器上的服务接口也都是秒回。所有后端的访问日志、耗时监控都看不到异常。我的排查路径是这样的先在客户端抓包过滤http或tls看这个页面的资源请求列表。重点观察关键资源主HTML、核心JS的请求时序。发现现象主文档请求发出后需要等4秒才收到响应而且这个4秒重复出现在好几个关键资源上。然后查询对应TCP流在tcp.stream里看请求发出前的TCP握手是正常的、没有重传请求之后的ACK也正常说明链路本身没啥问题。再往后看服务端的响应包在TLS握手完成后就粘连着数据发出说明服务端处理没花太多时间。到这里耗时应该出在客户端和服务端之间逻辑层。检查应用服务器后发现接入层网关针对该页面的会话在处理时加了同步锁锁的等待队列积压导致每个请求都被排队多秒。去掉锁后立刻恢复。这个案例的启发是Wireshark能帮你把问题从“网络层”证伪从而把视线聚焦到“应用层”。这种排障思路比翻代码来得更快、更有说服力。7.2 场景二内网传输文件很慢检查是丢包还是带宽公司内部经常有人要在两地之间传大文件百兆/千兆网络却跑出了几MB/s的速度。抓包路径在接收端抓包过滤TCP然后开启“统计-TCP流图-时间序列图”。这里有一组非常实用的判断方法看吞吐曲线是否接近线速如果中间有一段长时间平台期说明拥塞控制被触发。看是否频繁出现TCP重传红色/黑色包有重传基本等于丢包。看是否大量DUP ACK这往往意味着链路不对称或者中间有设备丢包。看TCP Window是否被频繁拉低——如果接收方的可用窗口长期为0说明接收端的应用消费太慢程序问题如果窗口很大但吞吐却上不去说明链路或中间设备是瓶颈。再分享一个重要的细节抓包点位置不同看到的“事实”可能不同。在接收端抓包看不到发送端是否真的发出去了。想要准确判断丢包方向最佳做法是两端同时抓包把同一时间段的包进行对比。7.3 场景三设备掉线——抓包定位ARP和IP冲突办公室设备经常“莫名其妙掉线”换个IP就好过一段时间又出问题。这种经典问题十有八九是IP地址冲突。排障思路在交换机镜像端口或者核心交换机上抓包过滤arp。重点看有没有两个不同MAC地址回同一IP的ARP应答。比如IP是192.168.10.50正常情况下ARP询问后只有一台设备回“192.168.10.50 在 MAC-A 上”。如果在抓包里看到MAC-B也宣称自己持有这个IP基本就是冲突了。还有个线索是“ARP欺骗”类问题——虽然大多数情况下不是恶意攻击而是某台设备配置了同IP静态地址。找到冲突源后隔离该设备的网线或关停对应网卡即可。8. 高频问题的排查技巧实录8.1 为什么我用Wireshark抓不到任何包最常见的几个原因选错了网卡。尤其Windows笔记本上多个虚拟网卡、蓝牙网卡并存时容易选到空闲的那个。使用了捕获过滤器但条件写错了。比如只抓host 1.2.3.4但实际流量走的是别的IP。抓的是回环流量本机访问本机服务普通网卡抓不到。需要安装Npcap时勾选回环接口支持然后选“Loopback: lo”接口。网卡上有系统防火墙或杀毒软件阻止Npcap驱动加载。排查步骤先取消所有过滤器选择“所有网卡接口”模式即多接口抓包看是否有流量。如果还是没有直接看网卡是否插网线、Wi-Fi是否连接正常。8.2 为什么抓包显示的端口和程序配置的端口不一致有时你在抓包中看到某个HTTP请求走了TCP 8080但服务端配置明明监听80端口。这种“不匹配”多半是因为客户端连接的是中间代理的8080端口代理再转给后端的80端口。抓包点位于客户端和代理之间看到的就是8080。还有一种情况是端口复用——服务端同一个端口上前端负载均衡设置为四层转发客户端看到的目标端口和后端服务真实端口不同这是很正常的。所以在分析时必须明确“我在哪个点抓包”。建议养成的习惯是动手之前先画一条简易的流量路径草图标出抓包点再解释包里的现象。8.3 Wireshark打开很卡或者抓包不稳我在性能调优上常用的几个办法关闭实时更新在“捕获选项”里打开“使用多个文件”后实时刷新负担下降很多。关闭名称解析前面说了重要。缩短“包列表刷新间隔”默认是100ms改成1000ms或者手动暂停刷新。减少不必要的着色规则。过滤日志限流不把分布式链路追踪的日志流量和业务流量混在一台机器上抓。如果同时抓多个网卡或大流量环境建议数据包捕获时顺手保存成pcapng文件分析时再打开文件避免界面Live刷新带来的性能压力。8.4 常见显示过滤器的速查表这里整一张实际干活时用得最多的表直接抄需求显示过滤器写法只看某个IP的双向流量ip.addr 192.168.1.10只看某两台主机的对话ip.addr 192.168.1.10 ip.addr 192.168.1.20只看所有TCP重传包tcp.analysis.retransmission只看TCP快速重传tcp.analysis.fast_retransmission只看零窗口包tcp.analysis.zero_window只看TLS握手包tls.handshake.type 1只看HTTP 500状态http.response.code 500只看DNS响应dns.flags.response 1只看请求时间大于1秒的包frame.time_relative 1过滤掉HTTP健康检查流量!http.request.uri contains /healthz这些条件可以自由组合括号和、||的用法跟大多数编程语言一致。遇到复杂的组合建议先在Wireshark编辑框里测试观察结果不满意再调整。8.5 抓包文件太大怎么快速找到目标包抓了30分钟的包文件可能有几百MB到几个GB。这时不要直接开着全量列表慢慢翻。推荐的操作路径先打开“统计-协议层次”窗口快速看整体流量构成哪个协议占多少比例。再打开“统计-对话”按IP地址汇总每条会话的数据量。异常大的会话往往是问题的中心。打开“统计-流量图Flow Graph”或者“I/O图”看整体流量是否有尖峰或空洞。根据这些汇总信息确定了需要深入的方向再用显示过滤器精确切入。这套“从统计到明细”的路径能在几分钟之内把一个几GB的抓包文件的疑点圈定到个位数的包里比从头翻要高效得多。9. 谈谈几个值得长期坚持的使用习惯抓包分析这个技能工具本身不难难的是分析思路和对协议的理解深度。我建议想长期吃这碗饭的朋友保持三个习惯第一每一次排障都留一份抓包文件和相关说明存成一个按日期命名的目录。哪怕当次问题已经定位解决了后续出现类似现象时能拿出来对照价值会超出你的预期。第二多花时间读RFC、看协议规范原文。Wireshark把协议解析得再清楚也只是工具层面的呈现真正要懂得为什么TCP这么设计、为什么三次握手不是两次、为什么TIME_WAIT要等2MSL还得回到协议原理本身去理解。第三遇到复杂的故障在两个端同时抓包形成对比视角。只在单端抓包很容易被一叶障目尤其是中间设备行为导致的丢包、乱序、重复包两端各抓一份才能画出完整的因果链。我在第一次用Wireshark排查生产故障时面对满屏花花绿绿的包完全不知道该先看哪里。后来慢慢养成了先关解析、看统计、追关键流、对比两端、结合日志的一个固定套路效率才真正上来。工具最终是为人服务的形成属于你自己的分析框架比记住几十条过滤器语法更值钱。
