Wireshark抓包实战指南：从入门到网络故障排查

每次有人问“Wireshark抓包分析到底怎么入门”，我都会想起那次线上接口偶发超时的排查经历：前端说请求发出去了，后端说响应也正常返回了，两边都没撒谎，但监控里就是有一批请求超过3秒才结束。后来我在链路里随便抓了几分钟包，真相很简单——一个TCP重传在凌晨的日志里反复出现，问题根本不在应用代码，而在中间那台老交换机上。从那以后，我把Wireshark当成随身工具而不是“网工专用软件”。

这篇内容不打算给你讲完整的菜单使用手册，那种文档官方已经有了。我按自己这几年用下来的真实路径，把装好工具之后真正会卡住你的东西、分析时最常用的破案思路、以及各种特殊协议下容易踩的坑串一遍。不管是刚看完教程还没上手的纯新手，还是已经能抓包但总觉得看不懂的人，都可以从里面找到能直接抄的玩法。

1. 先说说我为什么劝你赶紧学会抓包

1.1 一次把锅甩来甩去的线上问题，最后是网卡说了真话

那次的场景很典型：前端同学说从浏览器Network面板看到请求在等待响应，后端同学拉日志说接口返回200且耗时只有50毫秒，于是大家都觉得是中间代理或者链路抖动。可是代理的同学也很冤，因为他们从自己的监控看转发一切正常，两边一对比，整个问题变成玄学。

我做的其实很简单：在后端服务器上抓了30秒的包，过滤出那台客户端的IP，然后看到一段很清晰的交互过程。客户端发出第二次握手的ACK之后，服务端收到并返回了业务数据，但这个业务数据包的ACK一直没有回来，随后出现了好几次快速重传，最后客户端等不及直接重置了连接。这段包用不着什么高深技巧，顺着TCP流的颜色标记就能发现异常。但正是这段证据，让所有参与排查的人第—次达成共识：数据确实在某个环节“转发了一半就丢”。

这就是抓包的价值。它不关心你用的是哪门语言、框架有多新，只看真实的网络行为。应用层日志会说谎、监控系统会漏采，但网卡收到什么没收到什么，是客观存在的事实。

1.2 它到底适合谁：不是只有网工才需要

很多人觉得Wireshark是网络工程师或者运维专家的工具，自己一个搞后端、搞嵌入式、搞Android的人用不上。我反而觉得，以下几类人越早学会越省事：

• 后端开发者调接口超时、连接被重置、RPC调用失败时，抓包能快速区分是网络问题还是代码问题。
• 嵌入式开发者面对自定义的私有协议、串口转以太网或者工业总线报文，抓包几乎是唯一能看清交互细节的手段。
• 前端开发调试WebSocket、HTTPS证书校验失败，或者本地代理配置混乱时，抓包能直接看到请求到底去了哪里。
• 安全方向的同学做合规测试、恶意流量分析、样本调试，Wireshark是基础吃饭工具。
• 纯粹想真正学会TCP/IP的人。书上看一万遍三次握手，都不如自己抓一个包看一遍SEQ/ACK的变化来得实在。

所以这篇虽然标题叫实战指南，但不会跟你扯太深的网络原理，只讲在真实工作和实验中“你打开Wireshark之后到底该干什么”。

1.3 抓包前必须放在心上的前提

稍微泼一点冷水：抓包能力是把双刃剑。我只建议在自己的服务器、自己负责的应用、测试环境或者明确获得授权的场景下做流量分析。尤其后面说到TLS解密、查看会话密钥的时候，这个边界一定要清楚。任何未经授权去抓取和解析他人流量的行为都不合适，别让工具替自己惹麻烦。合规、安全的调试心态，是使用Wireshark的大前提。

2. 从安装到第一次抓到“有用的包”：环境里的三个坎

2.1 Windows/Linux安装与权限

Wireshark安装本身不难，难的是装完发现抓不到想要的包。Windows下安装时，它会提示装Npcap驱动，这个一定要装。Npcap的作用是让普通应用能拿到网卡上的原始数据帧，相当于给Wireshark装了一个“底层眼睛”。装的时候有个选项问是否限制为管理员权限，如果你希望普通账号也能抓包，可以不勾选限制；但如果考虑更安全的默认配置，保持限制也没问题，只是每次要右键“以管理员身份运行”Wireshark。

Linux下安装更简单，Debian/Ubuntu直接用apt装，RedHat系用yum或dnf装：

bash复制sudo apt install wireshark

装完有个常见坑：普通用户打开Wireshark后发现接口列表全是灰的，提示没有权限。这是因为抓包需要读取内核的raw socket。解决办法是把当前用户加入wireshark用户组，然后重新登录：

bash复制sudo usermod -aG wireshark $USER

如果不想搞用户组，也可以在命令行用sudo直接启动Wireshark，但我不建议日常用root跑图形界面，不够安全。

另外很多新手装好后觉得默认英文界面不习惯，实际不用装汉化包，软件本身就自带中文语言包，在菜单Preferences->Appearance->Language里切到Chinese并重启即可。

2.2 选对网卡，否则你只能看到自己机器的广播

打开Wireshark，第一个界面会列出所有可用接口。常见的问题是：本机明明在访问某个网站，选了一个接口后开始抓包，结果列表中全是ARP和广播，看不到自己想要的HTTP流量。这时候要检查两件事。

第一，是否选对了网卡。电脑上有线网卡、无线网卡、虚拟机的虚拟网卡、蓝牙网卡一大堆，如果你正用WiFi上网却抓了有线网卡的包，那当然什么都看不到。方法是在“捕获选项”里看“IP地址”一列，选择和你业务流量同网段的那块卡。

第二，确认混杂模式是否开启。正常情况下，交换机会把数据帧只发给目标MAC地址对应的端口。混杂模式让本地网卡不过滤目的地不是自己的帧，这样才能抓到经过本机的其它流量。Wireshark默认会打开混杂模式，不用手动设置，但如果你发现抓到的流量特别干净、只有发给自己的包，可以去捕获选项里看一眼“启用混杂模式”有没有勾上。

还有个特殊场景：在Windows上抓本机回环地址127.0.0.1的包。这一般发生在本地开发调试时，比如前端页面请求本机后端接口。Windows的回环流量默认不经过普通网卡驱动，你需要在接口列表里选择名为“Npcap Loopback Adapter”的虚拟接口，或者直接在捕获选项里勾选“捕获所有接口”碰运气。很多人在本地怎么抓都抓不到请求，就是卡在这个点上。

2.3 远程设备抓包：用tcpdump当采集器，Wireshark当分析器

嵌入式设备、云服务器、客户现场的设备往往没有图形界面，更装不了Wireshark。很多人不知道，Wireshark最强的搭档其实是Linux自带的tcpdump。你只需要在远程设备上执行一条命令，让tcpdump把数据通过SSH管道直接喂给本地Wireshark的实时接口，一边抓一边看：

bash复制ssh user@remote 'sudo tcpdump -i eth0 -U -w -' | wireshark -k -i -

这条命令的意思是远程tcpdump把原始包写到标准输出，SSH把字节流传回本地，Wireshark以管道方式读取并实时解析。实际用下来，只要网络带宽够，体感和本地抓包几乎一样。

如果现场不具备实时在线排查条件，也可以先远程抓包保存成文件再带回来分析：

bash复制sudo tcpdump -i eth0 -s 0 -w /tmp/capture.pcap

tcpdump的参数 -s 0 表示不截断数据包，保留完整帧，这个细节很重要。默认的snaplen可能只保留包头部，拿回来之后想看应用层载荷会发现内容被截断了。Wireshark抓包选项里也有对应的“限制每个包的长度”设置，默认65535字节，一般不用动；如果抓的是巨型帧，记得改成更大的值。

3. 抓包界面怎么读：抓到包只是开始，别被上千条列表吓住

3.1 三栏主界面的阅读顺序

第一次抓到包的人，很容易被一个接一个快速滚动的数据包弄得眼花缭乱，感觉每一行都在飘。其实Wireshark主界面就三块区域：上方数据包列表、中间协议详情树、下方原始字节。从上往下看就行。

列表区每一行代表一个数据包，列里最关键的其实是No和Time。No是包序号，Time默认显示从抓包开始到当前包的秒数。分析问题前建议先在“视图->时间显示格式”里改成“自参考时间”，也就是以第一个包为0秒的相对时间，这样算两个事件之间的间隔非常直观。默认的绝对时间只能看墙钟时间，排查性能问题时要自己在脑子里做减法，容易出错。

中间详情树是按协议层展开的，比如一个HTTP请求包，从上到下是Frame(物理帧）、Ethernet(二层）、IP(三层）、TCP(四层）、HTTP(应用层）。你不需要懂每一层，但要养成一个习惯：先看IP层确认源和目的地址对不对，再看TCP层确认端口和序号，最后看应用层内容。分析问题的时候往往不是从最上面开始，而是先看应用层有没有异常，再往下找网络层原因。

3.2 让颜色和列为你说重点

Wireshark默认的着色规则其实已经帮你标好了重点。淡紫色是TCP重传，黑色底红字往往是坏包或校验错误，浅绿色是HTTP流量，浅蓝色是UDP之类的其它流量。看到淡紫色或者黑底红字时，先停下来，这里大概率有故事。

但光靠颜色不够，建议自定义几个常用列。在列表的表头右键，可以添加列。我每次装完新环境都会加这四列：

• tcp.stream：标记每个TCP流的序号，方便把属于同一次连接的包归到一起。
• tcp.len：TCP载荷长度，用于快速看一个包是否携带数据。
• http.request.uri：如果是HTTP调试，可以直接列显示请求路径。
• dns.qry.name：看DNS查询的域名。

加上这些列之后，列表信息量会变得非常大，你可以快速跳过无关的包，而不是傻傻地盯着一堆源端口和目的端口去猜。

3.3 Follow Stream：把一场对话从几百个包里拉出来

分析一次HTTP请求，如果从头到尾数几百个包，效率太低。更好的方法是找到任意一个相关包，右键选择“追踪流->TCP流”。Wireshark会把属于同一个TCP流的所有双向数据重新组合在一起，显示成一份完整的会话内容，一端是红色，一端是蓝色，像看聊天记录一样。

这个功能在调试接口时极其好用：不用自己拼包，你直接就能看到请求头发送了什么、服务器返回了什么。如果协议是HTTP，还能直接选“HTTP流”，它会按请求响应对重组得更清楚。

很多“接口偶发超时”的排查，我都是从这里开始的。先找到最慢的那个请求，看它在TCP流里处于什么位置，然后看它前后有没有重传、有没有长时间等待、有没有连接被重置，方向基本就出来了。

3.4 可视化快速定位流量异常

Wireshark不是只能看一行行的包列表，它其实内置了不少可视化工具，只是新手很少点开。最容易用的是“统计->流量图”和“统计->IO图”。

流量图会把TCP交互按时间轴画出来，每一条会话一条线，能清楚地看到哪个连接在哪一刻建立、哪一刻断开、有没有重复建连。排查连接被重置、连接无法建立时，这个图比人眼扫列表高效太多。

IO图则适合看流量吞吐和周期性。比如怀疑定时任务每到整点就占用带宽，抓半小时包，打开IO图，把过滤条件设成针对那个任务的IP和端口，马上就能看到有没有规律的流量尖峰。同理，某个接口响应慢，可以在IO图上叠加TCP重传的曲线，看看重传是不是跟响应慢的时间点重合。

4. 别被“过滤”绕晕：显示过滤器与捕获过滤器要分开用

4.1 “加了udp过滤还看到ICMP”到底是哪里出了问题

网上经常有人问：我明明在Wireshark里加了udp过滤条件，为什么还是抓到了ICMP的数据包？第一次遇到这个问题的人往往会怀疑软件坏了，实际上几乎都是把两种过滤器搞混了。

Wireshark捕获界面顶部有一个标着“过滤器”的输入框，启动界面中间也会让你填“捕获过滤器”。这两个地方看着像，但作用完全不同，而且启动界面那个填完会按照BPF语法传给底层驱动，在数据被存入内存之前就丢弃不匹配的包；界面顶部那个则只对已经抓到的包做列表“显示筛选”，并不会影响抓包行为。

如果你是在界面顶部的“显示过滤器”框里输入udp，那列表里确实只显示UDP包，ICMP包不该出现。如果此时还能看到ICMP，通常是以下三种情况：

• 过滤条件没有生效，输入框里的表达式变红、有语法错误，Wireshark不会应用红色表达式，所以列表保持全量。
• 你写的是udp or icmp或者粘贴了包含icmp的复杂表达式，自己没注意。
• 你其实是在启动时设置了捕获过滤器模板，但模板没选对，或者选了之后又点了其它默认项。

排查方法很简单：看主界面左下角状态区域有没有类似“已应用过滤器：udp”的提示；再看过滤输入框的背景色是不是正常白色而不是红色。多数人都是因为表达式小问题导致规则没有真正应用，而不是Wireshark做错了什么。

4.2 两类过滤器的边界：一个管显示，一个管抓取

这两类过滤器记一句话就够了：显示过滤器是事后筛选，相当于从已抓到的几百MB数据里挑出你想看的；捕获过滤器是事前过滤，相当于只让匹配的数据进入内存。

• 显示过滤器：可随时修改，立刻生效，不影响文件里已经存下的包。适合大部分分析场景，因为抓包时可以先把所有流量抓下来，之后再慢慢筛。
• 捕获过滤器：只能在开始抓包前设置，基于BPF语法，会直接减少保存的数据量。适合在流量巨大、磁盘紧张或者只想关注某类协议的时候用。

比如只要UDP，启动前设置捕获过滤器udp，那么抓包过程中ICMP、TCP这类包根本不会被记录下来。你事后怎么翻都找不到它们。而显示过滤器udp，只是把UDP之外的包暂时隐藏，文件里其实还有。

新手建议统一只使用显示过滤器。它对分析没副作用，而且基于字段名，可读性强。捕获过滤器适合你已经明确知道只需要哪类流量、且现场流量大到内存吃不消时再用。

下面给出一张两类过滤器常用写法对照表：

4.3 几个我每次都会用到的过滤器写法

实战中最高频的几类写法固定下来，用顺手了可以大大节省时间。

抓特定请求路径的HTTP接口：

text复制http.request.uri contains "/api/v1/pay"

contains表示子串匹配，不要求完整一致。如果你只想看POST请求：

text复制http.request.method == "POST"

排查DNS解析，想看某个域名解析成了哪些IP：

text复制dns.qry.name == "example.com"

如果你反过来，已经知道某个IP，想确认它是从哪个域名解析出来的，可以用：

text复制dns.a == 93.184.216.34

这会直接命中DNS应答包里包含该IP的记录，比人肉翻列表靠谱。如果用TLS流量，想看某个域名对应哪些会话，则用SNI字段：

text复制tls.handshake.extensions_server_name == "example.com"

追踪某一次的完整会话，用stream号：

text复制tcp.stream eq 15

显示过滤器支持逻辑组合，比如只筛选从特定IP发往80端口、且不是重传的包：

text复制ip.src == 192.168.1.10 && tcp.dstport == 80 && !tcp.analysis.retransmission

注意运算符的大小写。字段名通常是小写加点，比如tcp.port而不是TCP.port；比较值字符串要加引号，IP要加引号，数字不用。输入的时候如果字段名错误，过滤框会变成红色，这时候别急着抓包，先把表达式改对。

5. TCP/IP没那么玄，但抓包时你得有这套“破案”方法

5.1 三次握手与四次挥手：从连接建立判断第一层问题

看懂TCP三次握手是抓包分析的第一道坎，它并不难，找三个包看颜色就明白了：

• 第一个包：客户端发SYN，SEQ是一个随机的初始序号，比如1000。
• 第二个包：服务器回SYN+ACK，自己的SEQ为2000，ACK为1001（表示“我收到了你序号1000的包，下一个请发1001”）。
• 第三个包：客户端回ACK，SEQ为1001，ACK为2001。

这三个包对应着一次完整的连接建立。如果抓包只看到第一个SYN，没有第二个SYN+ACK，说明服务器端没有响应，问题大概率出在服务器防火墙、端口未监听或中间网络丢弃。如果看到前两个包，但第三个ACK一直没出现或反复重发，说明客户端到服务器的回程方向有问题。

TCP的确认机制可以简单理解成收发快递：发的每个包裹都带编号，收件人收到后回执上写着“我收到了多少号之前的所有包裹，请发下一个号”。谁没收到回执，谁就会把快递再发一遍，这就是重传。抓包分析TCP，本质上就是在看这些编号和回执是否对得上。

排查阶段不需要把RFC全背下来，先记住两个最常用的异常颜色：

• 重传：同一个包的SEQ再次出现，说明对端没有及时确认，网络存在丢包或延迟。
• 重复ACK与快速重传：接收端连续收到乱序数据时，会重复告诉发送端“我还在等某个序号”。看到Dup ACK，通常是链路有乱序或丢包。

5.2 偶发超时案例：两端各执一词时，重传与Dup ACK在说什么

回到文章开头那个案例。当时我就是过滤出问题客户端的IP后，按TCP流顺序读包：

第一次正常请求，客户端在0.02秒内收到响应；第二次正常请求，0.03秒；第三次请求发出后，服务端秒回数据包，但客户端没有给ACK，服务端等了一会儿收不到，就重传了业务数据。重传一次没回应，再重传一次，客户端在重传到达前先发了RST，把连接断开了。

从应用日志看，服务端确实返回了200，但从网络看，这个200响应一直卡在服务端到客户端中间那段路上，客户端根本没收到。后来换掉那台老交换机，问题再也没有出现。

这个案例给了一个通用思路：遇到偶发超时，不要只看应用层日志，先去抓包文件里数一下有没有重传。重传本身是TCP的可靠机制，不一定是坏事，但如果重传频繁出现，链路质量一定有问题。你可以用显示过滤器快速统计：

text复制tcp.analysis.retransmission

在“统计->捕获文件属性”里看到重传包数量，或者在列表里把重传包全部过滤出来，看它们的源头是客户端还是服务端。重传的方向能告诉你哪一侧没收到ACK，问题就往哪一侧查。如果重传全是服务端发起，说明服务端到客户端的回程方向有问题，老盯着服务端日志看是查不出真相的。

5.3 DNS与TLS耗时拆解：定位“打开页面慢”到底慢在哪

这类问题的分析套路也不复杂。用户说网页打开慢，在客户端抓包后，你要做的不是看全部流量，而是按时间顺序回答三个问题：

• DNS解析花了多久。过滤出DNS的Query和Response，看时间差。
• TCP连接建立花了多久。看SYN和SYN+ACK的时间差。
• TLS握手花了多久。看Client Hello和Server Hello的时间差。

实际操作可以这样：先用DNS过滤器确认返回时间，再找到一个请求的TCP流，查看时间列里的相对差。你会发现所谓的“打开页面慢”，很多时候根本不是服务器处理慢，而是DNS解析卡了好几秒，或者客户端到服务器之间的TCP握手就花了2秒。应用层优化做得再好，解决不了这些底层耗时。

看TLS握手尤其要注意：如果你抓到之后发现应用层全是TLS，看不到HTTP明文，这是正常的，下一章专门说怎么让它现形。

6. 私密流量、特殊协议和那些抓不到的包

6.1 HTTPS不是不能看，得让会话密钥“借”给你

很多人第一次抓包都会疑惑：为什么我抓支付宝、抓百度，看到的全是TLS协议，内容完全无法阅读？这是TLS加密在起作用。Wireshark不是黑客工具，它不会解密所有加密流量，但如果流量是你自己的应用产生的，你可以主动告诉Wireshark“会话密钥是什么”，它就能在内存里解密并展示明文。

最常见的做法是设置环境变量SSLKEYLOGFILE，让浏览器或curl把每次TLS会话的密钥写到一个本地文件里。Windows和Linux都可以这样设置：

bash复制export SSLKEYLOGFILE=/tmp/keys.log
curl https://example.com

然后用Wireshark打开抓包文件，在“编辑->首选项->Protocols->TLS”里，把“(Pre)-Master-Secret log filename”指定成刚才那个/tmp/keys.log。重新打开抓包后，你会看到之前的TLS流量被解密成HTTP/2明文。

这里必须说清楚：这个办法只适用于你自己的客户端和服务器，或者你明确有权限调试的系统。想靠这个办法去解析别人服务器的HTTPS流量是行不通的——没有服务器私钥和会话密钥，抓再多包也没用。另外，keylog文件里含有敏感信息，用完记得删除，不要随手传到代码仓库。

6.2 Linux上用tshark查看TLS内容

没有图形界面时，可以用Wireshark自带的命令行工具tshark分析TLS。最常用的两个操作：一个是看抓包文件里有哪些TLS握手，另一个是提取SNI域名。

bash复制tshark -r capture.pcapng -Y "tls.handshake.type == 1" -T fields -e tls.handshake.extensions_server_name

这样会把所有TLS Client Hello里的SNI域名列出来。想进一步确认TLS版本、密钥交换方式：

bash复制tshark -r capture.pcapng -Y "tls.handshake.type == 1" -T fields -e tls.handshake.version -e tls.handshake.ciphersuite

不用图形界面时，tshark是处理大文件的一把好手。几百MB的pcap文件在图形界面里翻页会卡，用tshark过滤字段再导出结果，几秒钟就出来了。

6.3 Decode As与“列表里没有RTSP”的处理

正常情况下，Wireshark会根据端口号猜测协议。比如看到TCP 80端口，默认解析成HTTP；看到UDP 53端口，默认解析成DNS。但很多应用协议跑在自定义端口上，这时候Wireshark识别不出来，应用层会显示成“TCP”或“Data”，看起来就是一串乱码。解决办法是告诉它“这个端口上的流量应该按哪种协议解析”。

在数据包列表里选中一个包，右键选择“Decode As”，在弹出窗口里把端口指定成对应的协议即可。RTSP就是一个典型例子。RTSP通常跑在554端口，但很多摄像头、流媒体服务器喜欢把它放在其它端口，比如5540或8554。如果抓到的包没有被识别成RTSP，在Decode As里手动选择RTSP协议就能解析出OPTIONS、DESCRIBE、SETUP这些方法。

有网友反馈说Decode As对话框里根本找不到RTSP选项，这通常不是功能缺失，而是RTSP的dissector没有被启用。去“分析->启用的协议”里搜索rtsp，确认勾选状态，然后再回到Decode As里找。如果协议真没内置，也可以先Follow TCP Stream看看原始文本，手工判断报文结构。RTSP本质上是一个文本协议，看起来很像HTTP，即使Wireshark没能自动解析，你也能从原始载荷里直接读懂请求行和头部字段。

6.4 工业总线与特殊网口抓包：GOOSE/EtherCAT的注意点

Wireshark抓包不止用在传统IP网络上。很多工业现场的抓包需求来自EtherCAT、GOOSE这类不基于IP的二层协议，它们直接使用以太网帧的EtherType来标识，没有IP头。此时普通基于IP的过滤条件不适用，你需要让网卡能收到这些非IP帧，并正确解析。

GOOSE是IEC 61850标准中用于变电站通信的组播报文，它的目的MAC地址通常是01:0C:CD开头的组播地址，EtherType为0x88B8。在交换机组播场景下，普通交换机端口可能不会把这些组播报文转发给分析口，需要在交换机上做端口镜像或配置组播过滤。抓到包后，Wireshark通常能自动识别GOOSE协议，如果没识别出来，可以在Decode As里手动指定。

EtherCAT是工业以太网现场总线，EtherType为0x88A4。它和普通TCP/IP流量完全不同，每个工作站的报文是顺序经过的，抓包时必须注意抓取位置。如果只抓工作站网卡自己发出的数据，看不到完整的总线报文，最好在总线入口位置用支持镜像的交换机或者专用的总线分析仪配合Wireshark分析。Windows下抓这类二层工业报文，Npcap驱动一般能支持有线网卡接收原始帧，但如果网卡驱动本身把非IP帧过滤掉了，就可能出现抓不到的情况。

还有一个高频问题是USB抓包和蓝牙抓包。USB抓包在Windows上需要安装额外的USBPcap驱动，抓取时选择对应的USB根集线器或设备接口；Linux上则通过usbmon内核模块来采集。蓝牙抓包通常要配合专用的蓝牙协议分析器，或者使用Linux的btmon/btproxy等工具，把结果导入Wireshark分析。这些场景有一定门槛，但是通过Wireshark的接口列表就能发现可用的捕获源，并不神秘。真正要做的时候，先查一下目标平台支持哪种抓包驱动，别在普通网卡上干等。

7. 从图形界面走向脚本与数据文件：导出、tshark、还有pcap解析

7.1 导出证据与对象：给别人看包不要截图

排查到问题之后，往往需要把证据发给同事或客户。这时候不要截图，截图没法后续分析。正确做法是把相关流量导出成独立的pcap文件，或者使用“文件->导出特定分组”功能，只保留筛选出的包。导出时记得勾选“显示的分组”，Wireshark会自动把当前过滤条件下的包存成新文件。

如果要从HTTP流量里提取文件，可以用“文件->导出对象->HTTP”，把抓包中传输过的图片、JS文件、下载文件直接导出。这个功能在分析恶意流量、确认某个接口是否泄漏文件时很有用，也可以在调试文件上传接口时快速比对面包和实际传输内容是否一致。

7.2 tshark让Wireshark有了批处理能力

tshark是Wireshark套件里的命令行分析工具，它和Wireshark共用同一套解析器，但适合在服务器上做批量分析。比如有一个几百MB的pcap，想提取所有HTTP请求的URL和状态码：

bash复制tshark -r large.pcap -Y "http" -T fields -e http.request.method -e http.request.uri -e http.response.code

如果想把DNS查询记录以表格形式导出：

bash复制tshark -r dns.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name > queries.txt

tshark的字段和Wireshark显示过滤器字段一致，你会写显示过滤器就会用tshark。两者唯一的区别是tshark默认不打印tcp.stream之类字段，需要你用-e参数把要导出的字段写全。

7.3 用C语言解析pcap文件时容易踩的坑

Wireshark保存的文件最常见的格式是pcapng和pcap。如果你需要在嵌入式环境或者自己的程序里离线解析，pcap格式相对简单：文件头是24字节的全局头，之后每条记录有一个16字节的包头部，再跟着包数据。

用C语言解析时，最容易踩的几个坑分别是：

• 字节序。pcap文件头里的magic number为0xa1b2c3d4时是大端，0xd4c3b2a1是小端。解析之前必须先判断文件字节序，否则时间戳和长度全都会读反。
• caplen和len的区别。caplen是文件中实际保存的长度，len是原始包长度。如果抓包时设置了截断，caplen会小于len，读数据时只能按caplen来读。
• 链路层类型。文件头里的network字段表示链路层类型，1是Ethernet，101是Raw IP。不要写死按以太网帧解析，否则遇到raw IP的文件直接错位。

如果只是想快速处理数据而非学习文件格式，建议直接用libpcap库。它提供了pcap_open_offline()和pcap_next_ex()接口，几行代码就能读完一个pcap文件，Wireshark自身也依赖这个库。只有必须自己实现解析的逻辑时，才需要手工去处理文件头。

8. 一些我自己反复踩过的坑（或者当作最后的工具箱）

8.1 校验和全红不等于网络坏了

刚接触Wireshark时，看到抓包里大量TCP包标注为“校验和错误”，颜色黑底红字，第一反应是网络出大问题了。后来才明白，这很可能是当前网卡开启了硬件校验和卸载功能。数据包在发送时，TCP校验和由网卡硬件计算并填充，而Wireshark在软件层面看到包时，校验和字段还是空的或者已经被硬件改成另一套计算方式，于是它认为校验出错。

遇到这种情况，不要马上判定丢包或坏包。先去捕获选项里关掉网卡的“TCP校验和卸载”，或者在视图菜单里让Wireshark不校验IP和TCP校验和，再看分析结果。如果重传和错误色块依然大量存在，再考虑真正网络问题。

8.2 时间戳是跨端对比时的暗坑

排查跨端问题时，经常会同时抓客户端和服务端两边的包。这时候如果两台机器系统时间没有同步，两边的包时间戳会有偏差，直接对比“客户端发出请求是10:00:00，服务端收到却显示9:59:50”，会得出一些荒谬的结论。抓包分析时建议在两边都用NTP同步时间，并在Wireshark里把时间显示切到相对时间，按数据交互顺序而不是墙钟时间来推断时序。如果一定要用绝对时间对比，也要先确认两台机器相差多少秒，再把这个偏移量算进去。

8.3 常用的“肌肉记忆”清单

最后分享几个我每次拿到Wireshark都会顺手完成的配置，用久了手比脑快：

• 时间格式设为“自参考时间”，快捷键Ctrl+Alt+T可以快速切换。
• 添加tcp.stream列，分析TCP流时直接在列上看到stream号，配合过滤条件很方便。
• 每次抓包前先设置一个短期“显示过滤器”，不要一直全量盯着看。全量看包不但费眼，而且容易错过真正的问题。
• 分析完后用“统计->捕获文件属性”看整体的包速率、平均包长和重传占比，快速评估流量健康度。
• 长按Ctrl+F可以搜索分组内容，查找某个特定字符串时比人肉翻包高效得多。

抓包这件事，看起来只是打开软件点一下开始按钮，但真正值钱的是拿到数据之后能不能讲出一个完整的故事：谁在什么时间给谁发了什么，对方有没有收到，如果没收到中间发生了什么。多抓几次、多跟实际现象对几次，你很快会发现，许多“玄学网络问题”在包面前根本没有悬念。