企业官网建设流程全解析

简介：这份PDF教程面向网络协议分析初学者与运维、开发人员，系统讲解Wireshark抓包工具的使用方法，帮助读者理解TCP/IP中各协议的实际工作过程。内容涵盖启动界面、菜单栏、工具栏、过滤工具栏、封包列表、封包详细信息与十六进制数据面板等核心模块，并重点展开捕捉过滤器与显示过滤器的语法差异与配置步骤，便于在庞杂抓包结果中快速定位目标数据。资源包共1个PDF文件，大小约2.26MB，单文件结构便于随时查阅与打印学习。目前已有556人学习下载，适合需要掌握抓包分析、协议排查与网络监控技能的读者作为入门与查阅手册使用。

1. 从一份被传来传去的 PDF 说起：wireshark 到底该学什么

很多人第一次接触抓包，是因为一份叫「wireshark的使用教程[整理].pdf」的文件在群里、网盘里被反复转发。下载下来翻两页，发现全是菜单截图和按钮说明，看完还是不知道遇到真实问题该点哪里。这不是你的问题，是这类整理文档的通病——它把 wireshark 当成一个软件来介绍，而不是当成一个排查工具来教。wireshark 真正的价值在于：当你的程序连不上服务、接口返回异常、设备通信时断时续，你能打开它，看到网线上到底跑了什么，然后定位到具体是哪一层出了问题。这份教程类 PDF 适合谁？适合已经会写代码、会配服务，但一遇到网络问题就只能靠猜和重启的工程师。接下来的内容，我按自己带人排障的顺序，把 wireshark 从装到用、从抓到看懂、从看懂到定位，一步步拆开讲。

2. 装好之后先别急着抓：wireshark 的捕获与显示两层过滤体系

2.1 捕获过滤器与显示过滤器的分工

wireshark 的过滤器分两层，这是新手最容易混淆的地方。捕获过滤器（Capture Filter）在抓包开始前生效，用的是 BPF 语法，决定哪些包被写进内存和磁盘；显示过滤器（Display Filter）在抓包之后生效，用的是 wireshark 自己的语法，决定哪些包显示在列表里。两者的语法完全不同，写错了不会报错，只会让你什么都看不到。

我一般的原则是：捕获阶段尽量少过滤，除非流量大到机器扛不住。因为一旦捕获过滤器写错，丢掉的包就再也找不回来了，没有后悔药。显示过滤器则可以随便改，随时调整观察角度。比如你怀疑某个 TCP 连接有问题，捕获时不过滤，抓完之后在显示过滤器里输入tcp.port == 8080，立刻就能聚焦。

常见做法是：捕获过滤器只用来排除明显无关的大流量，比如你在抓本机和服务器的通信，可以写host 192.168.1.100，把其他机器的广播包挡掉。显示过滤器才是你分析的主力工具。

2.2 显示过滤器的常用语法与组合逻辑

显示过滤器是 wireshark 使用频率最高的功能，必须练到条件反射。基本语法是协议.字段 运算符 值，比如ip.addr == 10.0.0.1、tcp.port == 443、http.request.method == "POST"。运算符支持==、!=、>、<、contains、matches。组合逻辑用and、or、not，也可以用&&、||、!。

几个高频场景的过滤器写法：

# 只看某个 IP 相关的所有流量 ip.addr == 192.168.1.50 # 只看 TCP 端口 8080 且不是 SYN 包 tcp.port == 8080 and not tcp.flags.syn == 1 # 只看 HTTP POST 请求 http.request.method == "POST" # 只看包含特定字符串的包（比如某个接口路径） frame contains "api/v1/order" # 只看 DNS 查询失败的响应 dns.flags.rcode != 0

这些过滤器写进显示栏回车即可生效，支持自动补全。我建议把常用的几个存成书签，下次直接点。注意contains是区分大小写的，找路径时大小写要匹配。

2.3 抓包前的三个必调参数

装完 wireshark 直接点开始，往往会遇到两个问题：抓到的包太多看不过来，或者抓到的包不完整。有三个参数我每次都会先检查。

第一个是捕获接口的选择。有线网卡、无线网卡、虚拟网卡、回环接口（Loopback）是分开的。如果你在本地跑了一个服务，用 127.0.0.1 访问，必须选回环接口才能抓到。Windows 上回环接口需要额外安装 Npcap 的 loopback 支持，Linux 上直接选lo即可。

第二个是抓包缓冲区大小。默认值在流量大时容易丢包，可以在捕获选项里把 Buffer size 调到 100MB 以上。如果还是丢，就要考虑用捕获过滤器先缩小范围。

第三个是实时滚动显示。抓包时如果勾选「Update list of packets in real time」，包多了界面会卡。我一般关掉实时更新，抓完再分析，或者用tshark命令行抓包，性能更好。

# 用 tshark 抓包，指定接口和过滤器，写文件 tshark -i eth0 -f "tcp port 8080" -w capture.pcapng -b filesize:102400 # 抓完后用 wireshark 打开 capture.pcapng 分析

-i指定接口，-f是捕获过滤器，-w写文件，-b filesize设置单个文件大小上限，超过就滚动。这样抓长时间流量不会把内存撑爆。

3. 看懂一个 TCP 会话：从三次握手到四次挥手

3.1 用 Follow TCP Stream 还原一次完整对话

wireshark 最实用的功能之一是 Follow TCP Stream。右键任意一个 TCP 包，选择 Follow → TCP Stream，wireshark 会把这条连接的所有应用层数据按方向拼在一起，用不同颜色区分客户端和服务端。这相当于帮你把散落的包还原成一次完整的对话。

我排查接口问题时，第一步就是找到对应的 TCP 流，Follow 一下，看请求体和响应体到底长什么样。很多时候问题不在网络层，而在应用层——比如请求头少了一个字段，或者响应体被截断了。这些在包列表里看不出来，Follow 之后一目了然。

注意 Follow 窗口里显示的是原始字节流，如果内容是二进制或者压缩过的，需要切到 Hex Dump 模式看。另外，如果连接中途断了，Follow 只能看到断之前的数据，断之后的新连接要重新找。

3.2 三次握手与四次挥手的包特征

TCP 连接的建立和断开，在 wireshark 里有非常明显的标志。三次握手是：客户端发 SYN，服务端回 SYN+ACK，客户端再发 ACK。在包列表里，你会看到第一行的 Info 列写着[SYN]，第二行[SYN, ACK]，第三行[ACK]。如果只看到 SYN 没有后面的 SYN+ACK，说明服务端没响应，问题可能在服务端没监听、防火墙拦截、或者路由不通。

四次挥手是：主动关闭方发 FIN，对方回 ACK，对方也发 FIN，主动方再回 ACK。在 wireshark 里表现为[FIN, ACK]和[ACK]交替。如果看到大量 FIN 之后没有对应的 ACK，可能是对方已经异常断开。

一个常见的排查场景：用户反馈接口偶尔超时。抓包后发现，客户端发了 SYN，服务端回了 SYN+ACK，但客户端没有回最后的 ACK，而是过了一会重新发 SYN。这说明客户端的 ACK 丢了，或者客户端在收到 SYN+ACK 之前就超时了。这种情况通常是网络中间设备丢包，或者客户端负载太高处理不过来。

3.3 用专家信息快速定位异常包

wireshark 底部有一个「Expert Information」面板，会把所有异常包按严重程度分类：Error、Warning、Note、Chat。点开之后可以直接跳到对应的包。这个功能相当于一个自动体检报告，能帮你快速发现重传、乱序、零窗口、连接重置等问题。

我一般抓完包先看 Expert Information，如果有大量红色 Error，先处理这些。比如看到TCP Retransmission，说明有包丢了在重传；看到TCP Zero Window，说明接收方缓冲区满了，发送方要等；看到TCP RST，说明连接被强制重置，通常是服务端主动断开的。

注意 Expert Information 不是万能的，有些异常是正常的协议行为。比如 HTTP 长连接里偶尔的 Keep-Alive 包，可能被标记为 Note，但不用管。关键是看 Error 级别的，那些通常意味着真正的问题。

4. 避坑与排查：wireshark 用起来最常翻车的五个地方

4.1 抓不到包：接口选错或权限不够

现象：点开始抓包，一个包都没有，或者只有广播包。

原因：最常见的是接口选错了。比如你在抓本机浏览器访问本机服务，流量走的是回环接口，但你选的是物理网卡。另一个原因是权限不够，Linux 上普通用户没有抓包权限，Windows 上 Npcap 没装好。

解决：先确认流量走哪个接口。本机服务用127.0.0.1访问就选 Loopback；访问外网就选默认路由对应的网卡。Linux 上用sudo wireshark或者把用户加入 wireshark 组。Windows 上重新安装 Npcap，勾选「Install Npcap in WinPcap API-compatible Mode」。

4.2 中文显示乱码：字符编码没设对

现象：Follow TCP Stream 里中文显示成乱码，或者包详情里字符串字段是问号。

原因：wireshark 默认按 ASCII 或 UTF-8 解析，但有些老系统用的是 GBK 编码。另外，HTTP 响应头里如果没有指定 charset，wireshark 也不知道该用什么编码。

解决：在 Follow 窗口里，右下角有一个「Show data as」下拉框，可以切换编码。如果还是乱码，可以手动把数据导出成二进制文件，用其他工具按正确编码打开。对于 HTTP 流量，可以看响应头里的Content-Type字段，里面通常会带 charset。

4.3 抓到的包不完整：缓冲区溢出或过滤太严

现象：明明发了请求，但抓到的包里只有一半，或者关键的应用层数据缺失。

原因：两个可能。一是抓包缓冲区太小，流量大时内核来不及写就丢了。二是捕获过滤器写得太严，把需要的包也过滤掉了。

解决：先去掉捕获过滤器，只留显示过滤器。如果包太多，再逐步加捕获条件。同时把 Buffer size 调大，或者用tshark配合-b参数滚动写文件。另外，有些网卡支持硬件过滤，但配置复杂，一般不用。

4.4 时间戳不准：系统时钟或抓包延迟

现象：包的时间戳和实际发生时间对不上，或者两个包之间的时间间隔看起来不合理。

原因：wireshark 默认用系统时钟，如果系统时间没同步，时间戳就会偏。另外，高流量下抓包本身有延迟，包的时间戳可能比实际晚几毫秒。

解决：抓包前先同步系统时间，Linux 上用ntpdate或chronyd，Windows 上开启自动同步。如果对时间精度要求高，可以用支持硬件时间戳的网卡，或者在捕获选项里调整时间精度。分析时关注相对时间而不是绝对时间，相对时间受延迟影响小。

4.5 解密 HTTPS 失败：密钥没配或协议版本不匹配

现象：抓到的 HTTPS 流量全是加密的，看不到明文。

原因：wireshark 要解密 TLS，需要拿到会话密钥。常见做法是设置环境变量SSLKEYLOGFILE，让浏览器或客户端把密钥写到一个文件里，然后在 wireshark 的 TLS 协议设置里指定这个文件。如果客户端不支持导出密钥，就解不了。

解决：对于浏览器，设置SSLKEYLOGFILE环境变量后重启浏览器，访问目标网站，密钥会自动写入文件。然后在 wireshark 的 Preferences → Protocols → TLS → (Pre)-Master-Secret log filename 里指定该文件。对于自己写的程序，如果用的是 OpenSSL，可以在代码里调用SSL_CTX_set_keylog_callback导出密钥。注意 TLS 1.3 的密钥导出机制和 1.2 不同，wireshark 版本要足够新才能支持。

5. 从抓到看懂：用 tshark 做批量分析与自动化验证

5.1 tshark 常用命令与字段提取

wireshark 图形界面适合交互式分析，但如果你要处理几十个抓包文件，或者要把结果导入其他工具，tshark命令行更合适。tshark是 wireshark 自带的命令行版本，功能几乎一样，但可以脚本化。

几个我常用的命令：

# 读取抓包文件，只显示 HTTP 请求的源 IP、目标 IP、URL tshark -r capture.pcapng -Y "http.request" -T fields -e ip.src -e ip.dst -e http.request.uri # 统计每个 TCP 会话的包数量和字节数 tshark -r capture.pcapng -q -z conv,tcp # 提取所有 DNS 查询的域名和响应码 tshark -r capture.pcapng -Y "dns.flags.response == 0" -T fields -e dns.qry.name # 按时间过滤，只看某个时间段 tshark -r capture.pcapng -Y "frame.time >= \"2024-01-01 10:00:00\" and frame.time <= \"2024-01-01 10:05:00\""

-r读文件，-Y显示过滤器，-T fields指定输出字段，-e指定具体字段名。字段名可以在 wireshark 里点开任意包，在详情面板底部看到对应的缩写。-z是统计选项，conv,tcp会输出所有 TCP 会话的汇总表。

5.2 用 Python 调用 tshark 做自动化检查

如果你需要定期检查抓包结果，比如每天跑一次，看有没有异常连接，可以用 Python 调用tshark并解析输出。下面是一个最小示例：

import subprocess import json def analyze_pcap(pcap_file): # 调用 tshark，输出 JSON 格式 cmd = [ "tshark", "-r", pcap_file, "-Y", "tcp.flags.reset == 1", # 只看 RST 包 "-T", "json" ] result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print("tshark 执行失败:", result.stderr) return packets = json.loads(result.stdout) for pkt in packets: layers = pkt["_source"]["layers"] src_ip = layers["ip"]["ip.src"] dst_ip = layers["ip"]["ip.dst"] src_port = layers["tcp"]["tcp.srcport"] dst_port = layers["tcp"]["tcp.dstport"] print(f"RST: {src_ip}:{src_port} -> {dst_ip}:{dst_port}") if __name__ == "__main__": analyze_pcap("capture.pcapng")

这段代码调用tshark读取抓包文件，用显示过滤器tcp.flags.reset == 1筛选出所有 RST 包，然后解析 JSON 输出，打印每条 RST 的源和目的地址。-T json让tshark输出结构化数据，方便程序处理。注意tshark的 JSON 输出层级比较深，字段名要和版本匹配，不同版本可能有细微差异。

5.3 验证抓包结果是否可信的三个检查点

自动化分析的前提是抓包数据本身可信。我一般会做三个检查：

第一，看抓包文件的时间范围是否覆盖了问题发生的时间段。如果问题发生在 10:00，但抓包文件只到 9:55，那分析就没意义。

第二，看丢包率。tshark -r capture.pcapng -q -z io,stat,1可以按秒统计包数量，如果某个时间段包数量骤降，可能是抓包工具本身丢了包。

第三，看关键会话是否完整。比如你要分析一个 HTTP 请求，就要确认三次握手、请求、响应、四次挥手都在文件里。如果只有请求没有响应，可能是抓包在响应到达之前就停了。

这三个检查做完，再跑自动化脚本，结果才靠谱。否则你可能会花大量时间分析一个本身就不完整的数据集。

5.4 一个具体技巧：用着色规则快速标记可疑流量

wireshark 的着色规则（Coloring Rules）可以按条件给包上色，让你一眼看到异常。默认已经有一些规则，比如黑色背景表示 TCP 问题，红色表示 HTTP 错误。你可以自己加规则，比如把所有目标端口是 8080 的包标成黄色，或者把所有包含「error」字符串的包标成红色。

设置路径：View → Coloring Rules → 新建。条件写显示过滤器，颜色选一个醒目的。我一般会加几条：tcp.analysis.retransmission标红，http.response.code >= 400标橙，ip.ttl < 10标灰。这样抓完包扫一眼颜色分布，就能大致判断问题类型。

这个技巧在排查间歇性故障时特别有用。因为间歇性故障的包可能混在大量正常包里，靠手动翻很累。着色之后，异常包会自己跳出来。我自己的习惯是，每次抓包前先检查着色规则有没有开，没开的话先开再抓。这个习惯帮我省了很多翻包的时间。希望帮到你。

本文还有配套的精品资源，点击获取