企业官网建设流程全解析

直接抓包这件事，很多刚接触网络协议或者搞运维、开发的朋友，第一反应就是装个 Wireshark 然后点开始，看到一堆花花绿绿的列表瞬间懵掉。这工具确实是网络分析里的“瑞士军刀”，但它的问题从来不是功能不够强，而是上手门槛容易劝退人。我最早用 Wireshark 的时候，光是被“混杂模式”和“过滤器语法”这两个概念就绕了好几天，后来把常见场景捋顺了，才发现这工具的核心用法其实特别套路化。

这篇就基于我实际使用的经验，把 Wireshark 从下载安装到抓包、过滤、分析、排障的完整路径讲清楚。适合零基础的小白照着操作，也适合用过但一直停留在“只会双击网卡看列表”阶段的朋友，帮你把这块短板补上。

1. 装之前先搞清楚 Wireshark 到底在抓什么

很多人一上来就装软件，但没搞明白 Wireshark 工作的基本原理，导致后面遇到“为什么抓不到包”这种问题的时候完全找不到方向。

1.1 网卡、数据包和抓包三者之间的关系

Wireshark 本质上是一个被动监听工具，它依赖操作系统把网卡上流经的数据包复制一份交给上层应用处理。它本身不发送任何数据（除非你用它的辅助工具），也不修改数据包内容，只是安安静静地把线路上跑的数据“拍照留存”。

这里有个关键概念叫混杂模式（Promiscuous Mode）。默认情况下，网卡只会把发给本机的数据包交给系统处理，其他机器的数据包直接丢弃。开了混杂模式之后，网卡就会把链路上所有能收到的数据包都交给系统——这也是抓包工具能不能“看到”更多流量的分水岭。

注意：现在很多交换机端口默认做了隔离，就算开了混杂模式，也只能抓到本机进出的流量和广播报文。想抓整个局域网的所有流量，得靠交换机端口镜像或者分光器，那是另一套玩法，入门阶段不用纠结。

打开 Wireshark 主界面之后，你会看到一个网卡列表，每张网卡旁边还有个实时跳动的波浪线图，那个就是该网卡当前的流量曲线。选好网卡双击就开始抓包了，就这么简单。

1.2 安装时容易被忽略的选项

Windows 上安装 Wireshark 的时候，它会顺带安装一个叫 Npcap（新版）或 WinPcap（老版本）的底层驱动库，这个库才是真正负责抓包的那一层。很多人安装到一半看到弹窗提示“Install Npcap？”直接点 Next，结果装完之后发现抓包列表里有网卡但点开始没反应，大概率就是这步出了问题。

安装 Npcap 时有两个选项值得注意：

• 勾选“Support raw 802.11 traffic”（支持原始 802.11 流量）：如果你打算抓 Wi-Fi 的空中报文（比如分析无线协议交互），需要这个选项。
• 不勾选“Restrict Npcap to Admin users only”（仅限管理员使用 Npcap）：如果你平时用普通用户身份运行 Wireshark，建议取消这个勾选，否则每次抓包都要右键管理员运行。

macOS 上 Wireshark 首次启动会要求你授权安装一个系统扩展（ChmodBPF），这个扩展的作用是给普通用户访问 BPF（Berkeley Packet Filter）设备的权限。如果不装，Wireshark 会提示你没有权限打开接口列表。授权完之后重启 Wireshark 就能正常看到网卡了。

Linux 下最简单，发行版软件源里通常直接有 wireshark 包，但 Debian/Ubuntu 系装完之后有个对话框问你“允许非 root 用户抓包吗？”，选“是”就会把用户加进 wireshark 用户组，重登一次生效。不然每次都要 sudo 运行，权限问题能烦死你。

2. 第一次抓到包之后该怎么看

双击网卡抓了几秒，点一下红色方块停止抓包，这时候主界面会变成三段式布局：上半部分是一行一行的数据包列表，中间是某个数据包的协议树，下面是这个数据包的原始十六进制数据。大部分新手就是卡在这一步——看到列表不知道看哪里，也不知道每个字段什么意思。

2.1 三窗格布局其实是在拆解同一个包

三个窗格不是三份独立的数据，而是对同一个数据包从总览到细节再到原始字节的逐层展开。

• 数据包列表窗格：每一行是一个包，默认显示的列包括编号（No.）、时间（Time）、源地址（Source）、目的地址（Destination）、协议（Protocol）、长度（Length）、摘要信息（Info）。对于快速排查问题来说，Protocol 列和 Info 列信息密度最大。
• 协议树窗格：点中列表里的某个包之后，中间窗格会把该包按照协议栈的层次拆开，比如以太网头部（Ethernet II）、IP头部（IPv4/IPv6）、TCP/UDP头部、应用层数据。每一层都可以展开，展开后能看到各个字段的取值。这个窗格是理解协议的最直观入口。
• 十六进制窗格：最下面窗格显示的是数据包最原始的字节内容，左侧是偏移地址，中间是十六进制值，右侧是对应的 ASCII 字符。一般来说，做深度报文分析时才会逐个字节去抠内容，入门阶段这个窗格只需要知道它就是“最原始的样子”就够了。

一个常见的认知误区是：列表窗格里的 Info 列就是完整的内容。实际上 Info 只是 Wireshark 根据协议类型生成的一行摘要，比如 TCP 的 Seq/Ack 号、HTTP 的请求方法加 URI。真正的数据载荷要看协议树里最上层的协议段，或者直接用“Follow TCP Stream”（追踪TCP流）功能，把整条 TCP 连接上传输的数据重组出来，那才是应用层实际收到的内容。

2.2 默认列不够用？自己加一列“相对时间”

排查性能问题的时候，光看主界面默认的时间列（绝对时间）意义不大。我们需要知道的是“相邻两个包之间隔了多久”，比如确认一个 TCP 重传是不是超时太久、一个请求和响应之间的延迟是不是异常。

默认加上一列显示相对时间就能解决这个问题，操作路径是：编辑 → 首选项（Preferences） → 外观（Appearance） → 列（Columns），新增一列，字段类型选择“Relative time”（相对时间），这列会显示从抓包开始到当前包的累计毫秒数。

如果需要的是“和上一个包的间隔”，那在显示过滤器里用frame.time_delta_displayed字段可以做到，稍后会讲过滤器怎么用。总之先把列自定义这件事学会，能帮你省掉大量“肉眼盯表”的时间。

2.3 颜色规则不是花架子

列表里不同颜色的行是有讲究的。Wireshark 默认给某些协议和异常情况分配了颜色，比如 TCP 重传是浅红色，TCP 快速重传是深红色，零窗口是深灰，HTTP 请求是绿色，TCP 的 SYN 包是淡紫色。刚上手的人可能会觉得颜色杂乱影响观读，但看习惯了之后效率反而高很多——你根本不用逐行扫 Info，扫一眼颜色就能判断出链路里有没有异常中段。

想自定义颜色的话，在“视图 → 着色规则”（View → Coloring Rules）里调整。我通常会把“TCP Retransmission”（TCP重传）调成高亮红，把“TCP ZeroWindow”（TCP零窗口）调成亮黄，这两类颜色只要一出现，基本意味着链路有问题，一眼必须看到。

3. 抓包操作的核心思路：先过滤再抓包，而不是抓完再找

很多教程把 Wireshark 的过滤器分成“抓包过滤器”和“显示过滤器”讲，但我觉得更重要的是一种思维转变：抓包之前先想清楚你要分析什么流量，设定好抓包过滤器（Capture Filter），而不是怀着“先全部抓下来再说”的心态把几 GB 文件捞回来，然后开着显示过滤器在大海里捞针。

3.1 抓包过滤器：在源头丢弃无用的包

抓包过滤器用的语法是 BPF（Berkeley Packet Filter），它是在网卡驱动这一层生效的，由内核直接处理，效率极高。因为数据还没进入 Wireshark 内部处理流程就被丢掉了，所以它可以显著减少磁盘写入和内存占用。

常用例子：

• 只抓本机 IP 为 192.168.1.100 的流量：host 192.168.1.100
• 只抓 80 端口的 HTTP 流量：port 80
• 抓 443 端口的 HTTPS 流量：port 443
• 抓特定 IP 和特定端口组合：host 192.168.1.100 and tcp port 443
• 只抓 ICMP 协议：icmp
• 排除某些 IP：not host 192.168.1.1
• 抓广播和多播报文：broadcast or multicast

BPF 支持的协议关键词包括tcp、udp、icmp、arp等，还有方向限定词src、dst。比如src host 192.168.1.100就只抓该地址作为源地址发出的包。

设置入口：Wireshark 主界面网卡列表上方有一个绿色条，写着“Capture Filter”，点击它就能输入 BPF 表达式。你也可以在“捕获 → 选项”（Capture → Options）里针对指定网卡配置。

一个经验：如果只是临时看看某个服务的交互方式，我建议抓包过滤器先别设太死，最多按端口过滤一下就行。因为 BPF 一旦在源头把包丢了，后面想看任何信息都找不回来了。宁可多抓一点，也不要漏抓关键报文。

3.2 显示过滤器：抓完之后最常用的利器

显示过滤器是在 Wireshark 内部对已经抓到的数据做筛选，它不会删除任何数据包，只是隐藏不符合条件的行。这是你日常用得最多的功能，因为大多数时候你抓下来的流量比实际所需广泛得多，需要反复筛选才能定位到问题。

显示过滤器的语法比 BPF 友好得多，字段名也很直观。举几个典型用法：

• 只看特定 IP：ip.addr == 192.168.1.100
• 只看某个端口：tcp.port == 443
• 只看 TCP 协议，排除其他：tcp
• 只看 HTTP：http
• 只看 DNS 查询：dns
• 筛选出所有 TCP 重传包：tcp.analysis.retransmission
• 筛选出包含特定字符串的包（比如 HTTP 中的 URL）：http contains "login"
• 筛选出长度大于 1000 字节的包：frame.len > 1000

组合逻辑用and、or、not：

• ip.src == 192.168.1.100 and tcp.port == 80
• tcp or udp
• not arp（屏蔽所有 ARP 噪声）

显示过滤器的输入框在抓包主界面正上方，绿色背景表示语法正确，红色背景表示语法错误。输入时可以自动补全字段名，这一点非常方便，不需要背全字段。

从效率角度讲，我建议你把抓包过滤器当作“进水口的水龙头”，把显示过滤器当作“水处理的沉淀池”。水龙头控制进水量防止水漫金山，沉淀池帮你从已经接进来的水里挑出需要的成分。两者配合，而不是只用其中一种，是长期抓包不累的关键。

4. 实战：用 Wireshark 抓一次 HTTPS 握手，看懂 TLS

讲完基础操作，我们用一次典型的 HTTPS 抓包来把之前说的东西串起来。HTTPS 其实就是 HTTP over TLS，数据内容是加密的，但 TLS 握手阶段的很多信息是明文——比如客户端支持的加密套件、服务器证书、双方协商的 TLS 版本。这些信息足够帮助我们排查“为什么 HTTPS 连接失败”之类的问题。

4.1 抓包过程示例

假设我们要抓访问https://www.example.com时的 TLS 握手。

1. 在主界面双击选择当前正在使用的网卡（通常是有互联网流量的那块，比如名称里有“Wi-Fi”或者“Ethernet”）。
2. 点击左上角红色方块旁边的蓝色鲨鱼鳍按钮开始抓包。
3. 在浏览器地址栏输入https://www.example.com并回车。
4. 等页面加载完成后，点红色方块停止。
5. 在显示过滤器中输入tls（Wireshark 4.0 之前的版本里协议名是ssl，注意区分）然后回车。

过滤之后你应该能看到一串 TLS 记录，其中前几个重要的类型是：

• Client Hello：客户端发给服务器的第一条握手消息，包含客户端支持的 TLS 版本、加密套件列表、SNI（Server Name Indication，用来告诉服务器客户端想访问哪个域名）。
• Server Hello：服务器从客户端列出的套件里选择一个双方都支持的，并返回自己的 TLS 版本、本次会话使用的加密套件。
• Certificate：服务器把证书链发给客户端。
• Server Key Exchange / Client Key Exchange：根据密钥交换算法不同，这两步可能同时出现或者只出现其中一种。
• New Session Ticket：服务器给客户端发的一个会话票据，用于会话恢复。
• Application Data：TLS 握手完成后，后面的数据都以密文形式传输，在 Wireshark 里看到的协议就是 Application Data，里面的内容已经不可读。

在协议树窗格里点开 Client Hello 这一层，你会看到 TSL 版本字段、加密套件列表、扩展字段里的 SNI，这些字段在排障时特别有用。比如服务器不支持某个加密套件导致握手失败，看这里通常能找到答案。

4.2 TLS 解密：把加密流量“打回原形”

只看到 Client Hello 和 Server Hello 不足以分析应用层问题，好在 Wireshark 支持用会话密钥（Session Keys）解密 TLS 流量。最常用的方式是通过环境变量SSLKEYLOGFILE让浏览器或程序把会话密钥导出到本地文件，然后 Wireshark 用这个文件解密。

以 Chrome 为例，做法是：

1. 新建一个文件路径，比如C:\temp\sslkeys.log。
2. 设置系统环境变量SSLKEYLOGFILE=C:\temp\sslkeys.log。
3. 重启 Chrome。
4. 在“编辑 → 首选项 → Protocols → TLS”里面，把(Pre)-Master-Secret log filename指向这个文件。
5. 重新用 Wireshark 抓包访问 HTTPS 网站。

设置好之后重新抓包，你会看到过滤结果里多了很多HTTP协议的行，应用层内容（比如 GET / 请求、响应头、响应体）直接显示成明文了。这对调试接口联调问题几乎是决定性的帮助。

提示：如果你用 Firefox，设置方法差不多，firefox 也支持读取系统环境变量SSLKEYLOGFILE。但注意这个密钥文件只能用于解你本机导出的流量，无法解密任意第三方抓到的 HTTPS 流量，因为每次 TLS 会话的密钥都是独立生成的。

5. 长时间抓包的正确姿势：环形缓冲区和文件切分

很多人遇到过一个场景：想抓一个偶发问题，但不知道具体什么时候出现。如果从白天挂到晚上，主界面上的包数量可能几十万甚至上百万，文件几个 GB，Wireshark 直接卡成幻灯片。这时候你需要的是“长时间抓包方案”。

5.1 多文件模式

Wireshark 自带的多文件模式可以按大小或时间把抓包结果切分成多个文件，避免单个文件过大导致打不开。

设置路径：捕获 → 选项 → 输出（Output）。

常用配置：

• 按文件大小切分：勾选“每个文件的大小（KB）”并填一个值，比如 100000（100MB），超过这个大小 Wireshark 会自动开新文件。
• 按时间切分：勾选“每个文件的时间间隔（秒）”，比如设为 3600，每小时一个文件。
• 环形缓冲区：勾选“环形缓冲区，文件数量”，比如填 10，表示只保留最近的 10 个文件，新文件生成时会覆盖最老的文件，避免磁盘被塞满。

我有一次排查一个周期性超时问题，就是用“每 30 分钟一个文件 + 保留 20 个文件”的方式抓了一夜，第二天早上把 20 个文件挨个拉进 Wireshark，用显示过滤器tcp.analysis.retransmission扫了一遍，很快就定位到了问题发生的时间窗口。

5.2 用 dumpcap 命令行工具替代 GUI 抓包

长时间抓包还有一个更轻量级的选择：用 Wireshark 自带的命令行工具dumpcap，它只负责抓包写文件，不加载 GUI，内存占用小，稳定性高。

基本用法：

dumpcap -i 2 -w D:\capture\output.pcapng -b duration:3600 -b files:10

解释一下：

• -i 2：抓第二个接口（可以用dumpcap -D查看接口编号）
• -w：输出文件路径
• -b duration:3600：每个文件最大时长 3600 秒（1小时）
• -b files:10：环形缓冲区保留 10 个文件

要停止的话，按Ctrl+C或者直接杀掉进程。dumpcap 写出来的文件可以用 Wireshark 正常打开分析。如果你在服务器上排障不方便开图形界面，这个工具几乎是唯一解。

6. 抓包之后的分析实操：快速定位一个连接慢的问题

工具用熟了，最后还是要回归“怎么用抓包结果解决问题”。这里用一个虚拟场景把整个分析链路走一遍，帮助你建立自己的排查思路。

6.1 问题描述和抓包准备

假设一台服务器收到了某个客户端请求，但接口响应很慢，从客户端日志看每次发请求都要等 3 秒以上。我们想确认延迟到底发生在哪里。

抓包方案：在客户端侧和服务器侧各开一个 Wireshark，同时抓包。客户端侧重在发起请求的机器上抓，服务器侧重在服务端口上抓。显示过滤器用tcp.port == 8080（假设服务端口是 8080）。

6.2 从 TCP 三次握手开始看

过滤结果里先找到三次握手：

第一行：客户端发 SYN（Seq=0），请求建立连接 第二行：服务器回 SYN+ACK（Seq=0，Ack=1） 第三行：客户端发 ACK

从时间列看第二行和第一行的间隔，如果超过几十毫秒甚至达到秒级，那问题大概率出在网络路径上（中间有设备丢包、拥堵等）。如果三次握手很快，问题往后看。

然后找到 HTTP 请求和响应的那几行。用“右键 → 追踪 TCP 流”（Follow → TCP Stream）把这条连接的内容重组出来，可以直观看到客户端发了什么、服务器回了什么、中间有没有长时间空白。

如果看到请求包发出后，过了一段时间才有响应包回来，那问题可能在服务器处理逻辑上；如果响应包回来后客户端又过很久才发下一个请求，问题可能出在客户端应用逻辑上。

6.3 用 Time Sequence 图看全局延迟分布

Wireshark 自带的“统计 → TCP 流图 → 时间序列图”（Statistics → TCP Stream Graphs → Time-Sequence）是一个非常直观的图表工具。横轴是时间，纵轴是包的序列号，它可以画出 TCP 传输过程中序列号随时间的变化曲线。

如果图表近似一条平滑上升的直线，说明数据在持续稳定传输；如果出现明显的水平平台，说明那段时间没有数据流动，很可能就是延迟的源头。

在长时间抓包里，把鼠标悬停在平台区间，可以找到对应时间点附近的包级线索，再结合显示过滤器tcp.analysis.retransmission、tcp.analysis.zero_window检查是否有重传或接收窗口耗尽现象。

6.4 常见的几个定位结论

• TCP 重传多：链路丢包严重，可能是网络线路质量差、中间设备队列满、MTU 设置过大导致分片问题。
• TCP ZeroWindow：接收端应用处理不过来，接收缓冲区满了，发送端被卡住。问题在接收端应用处理速度，不在网络。
• TCP Dup ACK：通常伴随重传出现，说明对方没有收到序号对应的包，或者收到了乱序的包。需要重点排查中间链路是否存在负载均衡、多路径等机制导致的乱序。
• TLS 握手完成到首个 HTTP 请求之间延迟高：问题可能在应用层初始化、数据库连接建立等服务器内部流程上，抓包只能定位到“延迟出现在这个阶段”，具体还得靠应用日志去深挖。

这些结论并不是机械套用，需要结合两端的日志和实际业务逻辑综合判断。抓包的价值在于把“哪个环节慢”这颗钉子钉死，让后面的优化方向不再靠猜。

7. 一些 Wireshark 使用中的常见问题和操作细节

最后把平时被问得最多的几个问题集中答一遍，这些点单独拿出来都不复杂，但容易耽误时间。

7.1 为什么抓包列表里看不到某些包？

最常见的原因有三个。

第一是登录权限不足：Windows 上没以管理员身份运行 Wireshark，Npcap 驱动拒绝非管理员进程访问网卡，表现是网卡列表能看到，但抓包后列表一直空白或者直接报错。

第二是混杂模式没开：抓网卡前检查一下捕获选项里是否勾选了“启用混杂模式”。某些 USB 无线网卡驱动对混杂模式支持不好，也会导致只能抓到本机流量。

第三是目标流量根本没经过本网卡：比如你要抓两台物理机之间的通信，但抓包软件装在第三台机器上，除非设置了端口镜像或者流量经过该机器转发，否则当然抓不到。

7.2 为什么只显示了 520 字节，数据长度不对？

这个问题在最近的热搜词里出现过。抓包列表里看到的 Length 是当前这个包的链路层长度，如果存在 IP 分片，一个应用层大报文会被分成多个 IP 分片传输，每个分片在列表里都是独立一行，各自长度不同。

Wireshark 默认会把 IP 分片重组成完整报文，但有些场景下（比如抓包时机器性能不够或文件损坏）重组会失败，列表里就只能看到分片后的样子。想看重组后的数据长度，可以在显示过滤器里用frame.len字段，或者在“编辑 → 首选项 → Protocols → IPv4”里检查“重组分片的数据包”选项是否被关闭了。

至于怎么显示完整的 2090 字节：确认这个协议本身支持重组（TCP 默认支持，UDP 某些场景下不支持），然后在 IPv4 协议首选项里打开重组，再重新抓一次。如果还是不显示，那是抓包点的问题——数据在链路上真实传输时可能就是在中间被路由器分片了，到达抓包点时本来就不是完整包。

7.3 Wireshark 为什么一直卡住？

我遇到过几次，大概率是流量吞吐量太大，而 Wireshark 实时渲染界面扛不住。解决办法有几种：

• 抓包前先用抓包过滤器把流量缩小到需要的范围
• 关闭实时更新的“实时捕获数据包”选项（在捕获选项中）
• 改用 dumpcap 抓文件，抓完再打开分析
• 更新网卡驱动，部分老驱动在高 PPS 场景下有明显性能问题

另外，如果 Wireshark 打开一个超大的 pcapng 文件时卡住，可以试试在“编辑 → 首选项 → 显示”里限制自动展开的包数量、关闭实时校验，或者干脆用mergecap或editcap先把文件切分，再分段分析。

7.4 如何看 UDP 前后两个包的时间间隔

热搜词里有“wireshark如何筛选出udp前后两包的时间间隔”。处理思路是这样的：显示过滤器里可以引用上一个同组包的字段，具体做法是用frame.time_delta_displayed这个字段，它表示当前包和显示出来的上一个包之间的时间差（秒），单位是秒，小数位可以显示到微秒。

过滤条件加上udp and frame.time_delta_displayed > 0.5，就能筛选出“离上一个可见 UDP 包超过 0.5 秒”的包，间接定位间隔异常的 UDP 报文。如果还需要更精确的“同一个五元组前后包间隔”，建议先按udp.port == 某个端口过滤，再看frame.time_delta_displayed。

7.5 抓到的 WiFi 包怎么都是乱码一样的 802.11 帧？

因为 Wi-Fi 的空中报文本来就带有 802.11 管理帧、控制帧，这些帧不是标准的 IP/TCP 数据结构。如果安装 Npcap 时没有勾选“Support raw 802.11 traffic”，Wireshark 只能看到空中的数据包；勾选之后才能看到完整的 802.11 帧，包括 Beacon、Probe Request 等。

这时候的显示过滤器要配合 802.11 的字段，比如wlan.fc.type_subtype == 0x08是 Beacon 帧，wlan.fc.type == 2是数据帧。分析 Wi-Fi 空口问题时，这些帧的序列号（Sequence Number）和重传标志位（Retry）是非常关键的字段。

7.6 抓包蓝牙数据怎么做？

用 Wireshark 抓蓝牙数据和抓以太网完全是两码事。普通的 Wireshark 只能抓本机已经交给操作系统网络栈的蓝牙数据流，比如通过蓝牙 PAN（个人区域网）上网的 IP 流量。如果想抓 HCI 层甚至空中的蓝牙协议包，需要安装专门的扩展，在 Windows 上一般借助 Wireshark 的extcap插件配合蓝牙适配器驱动实现。

常见的做法是在 Windows 上安装 Microsoft 的 Bluetooth Test Platform（BTP），它提供 Wireshark 的 extcap 插件，可以抓取 HCI 层的日志。也可以在 Linux 上用btmon抓 HCI 日志，再用 Wireshark 打开。这部分属于进阶玩法，入门阶段知道路径就行，真做蓝牙协议开发的时候再深入也不迟。

8. 把抓包培养成一种工作习惯

Wireshark 的能力上限是很高的，它支持上千种协议解析、完整的表达式引擎、TShark 命令行批处理、Lua 脚本扩展等等。但对于绝大多数非专职网络分析的人来说，把“抓包、过滤、看时间戳、追踪流、查重传”这几个动作做到肌肉记忆，就已经能解决工作里 80% 以上的网络协作问题。

我自己的习惯是：但凡联调出问题，先别急着让开发看日志，先在两端各开一个 Wireshark 抓 10 秒。用tcp.analysis.retransmission和frame.time_delta_displayed两个过滤器快速扫一遍。大多数时候，问题到底在客户端、服务端还是链路中间，五分钟之内就能判断个大概。

根据我接触过的情况，很多被网络问题搞得焦头烂额的工程师，其实不是缺排查工具，而是缺一套“该在哪里抓、抓完看什么、看完怎么判断”的方法。希望这篇把入门到进阶的路径捋清楚之后，你下次打开 Wireshark 时，不再是对着一堆彩色行发呆，而是能带着明确的问题去抓、去看、去定位。