企业官网建设流程全解析

简介：《Wireshark网络分析的艺术》电子书及配套资料包，面向网络管理员、运维工程师与安全分析人员，帮助读者系统掌握Wireshark的安装配置、捕获过滤器与显示过滤器、数据包解析等核心技能，并能用于网络延迟、丢包、异常TCP连接等故障定位，以及嗅探、中间人攻击、SQL注入等安全威胁检测。内容涵盖从物理层、数据链路层到网络层、传输层及应用层的协议解析，对以太网、IP、ICMP、TCP、UDP以及HTTP、FTP等协议字段进行了实例讲解，尤其细化TCP连接建立、数据传输、关闭过程与HTTP请求响应的分析思路。包内共5个文件，以PDF电子书为主，辅以docx、htm和txt文档，其中包含必读Linux书籍推荐、VM虚拟机下载地址及资料解压密码，整体约28.8MB，轻量便于下载。目前已有587人学习使用。读者通过实战练习可巩固排错思路，深入理解网络通信本质，快速提升网络分析与问题解决能力。

1. 抓包不是玄学：Wireshark 把网络问题变成一张可复现的清单

网页打开慢、文件传不上去、接口偶发超时，这类问题最难的地方在于：IP 能 ping 通、端口能 telnet 通，但业务就是慢。Wireshark 是把这个“慢”拆成一张可见清单的工具——哪一次握手慢了、哪个请求阻塞了、哪段数据被重传了，全都有据可查。《Wireshark网络分析的艺术》就是围绕这个目标展开的：从捕获接口讲起，一路讲到 TCP 三次握手、HTTP 状态码、显示过滤器、重传定位、TLS 解密和基础安全分析。它不是把几百个协议字段罗列出来让人背，而是用真实案例告诉你，抓包分析是怎么一步步缩小问题范围的。网络管理员、后端开发、运维和安全测试都会用到这本书；如果你刚入门，只要会装软件、看得懂命令行，就能按书里的思路把最常见的网络故障复现出来。

2. 环境与界面：先把捕获接口、过滤器、追踪流这三件事做实

这本书开头几章最值得反复看，它把很多人用了一两年 Wireshark 可能都没搞清楚的事讲明白了：你抓到的包是否完整、过滤是否有效、会话能不能还原。很多新手抓包抓了半小时，最后发现抓错了接口或者过滤条件写错，白干一场。这一章把这三件事拆开讲。

2.1 捕获接口与捕获过滤器：别把整个网络都收进来

选接口是第一道坎。Wireshark 打开后能看到一堆接口：以太网、WLAN、Loopback，以及各种虚拟网卡。抓包前先确认流量真正走哪个接口。比如笔记本连着 Wi-Fi 排查网页打开慢，接口就该选 WLAN 而不是以太网；如果选错，抓到的包和故障完全无关，排查方向直接跑偏。

选好接口后，还要决定是不是把所有流量都存下来。pcap 文件越大，后面分析越费劲。捕获过滤器的作用是在抓包那一刻就生效，语法是 BPF（Berkeley Packet Filter）。在捕获选项里可以这样填：

host 10.0.0.5 and tcp port 80

含义是只抓源地址或目的地址为 10.0.0.5、且 TCP 端口为 80 的报文。BPF 语法里host是主机过滤，port是端口过滤，and表示两个条件同时满足。另一个常见写法是tcp port 80 or udp port 53，同时收 HTTP 和 DNS 流量。

注意host同时匹配源和目的，而ip src host只看源地址。大多数排查场景用host就够了。我一般会在确认问题主机和端口后先把捕获条件收紧，抓到那几十秒的故障现场就停，而不是开着抓几个小时——文件太大后面处理起来全是麻烦。

配套资源里有 Linux 系统与 VM 虚拟机下载地址。如果手头没有独立的测试环境，装一台 Linux 虚拟机，再从宿主机用 Wireshark 抓虚拟机的流量，是练习抓包分析比较稳妥的方式。不建议直接在生产网关上练手，风险太大。

2.2 显示过滤器：从“看不到”到“只看这一条”

捕获过滤器能缩小“入账”的流量，但真正定位问题靠的是显示过滤器。显示过滤器是 Wireshark 自己的语法，作用在已经抓到的一堆报文上，随时改随时生效。

最基本的用法是直接查 IP 和端口：

ip.addr == 192.168.1.10 and tcp.port == 443

这条表达式会显示所有与 192.168.1.10 通信的 TCP 443 端口报文。ip.addr同时匹配源和目的地址，tcp.port同理。写的时候字段名大小写要小心，ip.addr写成IP.addr在 Wireshark 里会被标红报错。

捕获过滤器和显示过滤器最常被搞混：捕获过滤器用host、port这种 BPF 写法，显示过滤器用ip.addr、tcp.port这种字段写法。记住一句话：捕获过滤器在抓包之前决定收不收，显示过滤器在抓包之后决定看不看。

配合显示过滤器还有一个高频操作——加自定义列。在报文列表的表头右键，选“列首选项”，可以增加Source port、Destination port、TCP Stream index等列。排查 HTTP 慢请求时，把Time since previous displayed packet加出来，两条报文之间的时间差立刻可见，不用在详情面板里翻来翻去找。

2.3 追踪流：一条 HTTP 请求的前后文一眼看清

显示过滤器能筛出某台主机的报文，但一个 HTTP 请求会被 TCP 拆成几十上百个报文，散落在列表里，肉眼很难拼出全貌。这时用“右键 -> 追踪 TCP 流”，Wireshark 会把同一个 TCP 连接的所有报文按顺序重组，还原成左右两栏的完整会话，左边是客户端发的，右边是服务端回的。

命令行下用 tshark 也能拿到同样的流内容：

tshark -r http.pcapng -Y "tcp.stream eq 0" -z follow,tcp,ascii,0

-r指定读取的抓包文件，-Y用显示过滤器直接选中某条流，-z follow,tcp,ascii,0表示以 ASCII 格式输出第 0 号 TCP 流的内容。注意tcp.stream eq 0里的数字不是固定的，排查时先在 Wireshark 里看目标报文所属的流编号，再把这个数字替换进去。

追踪流是排查“接口通但业务不通”类问题最实用的功能。比如一个 POST 请求在服务端总是返回 400，看单个报文只能看到状态码，追踪流以后能看到完整的请求头，哪一行写错了一目了然。

3. 协议解析：从三次握手到 HTTP 耗时，一层层拆给你看

这本书的主干是协议解析，但它不是把 RFC 文档搬进书里，而是用“一次用户访问”作为线索，把 TCP/IP 协议栈每一层在 Wireshark 里的表现讲清楚。这一章按最容易遇到的三种场景展开：TCP 连接建立与拆除、HTTP 请求响应、UDP/DNS。

3.1 TCP 三次握手与连接拆除：SYN、ACK、FIN 的时序怎么读

TCP 连接建立的标志是三次握手。在 Wireshark 里找一个 HTTP 请求，展开传输层能看到 SYN、SYN-ACK、ACK 三个报文。用显示过滤器可以直接把它们挑出来：

tcp.flags.syn == 1 and tcp.flags.ack == 0

这条表达式过滤出 SYN 标志位置位、且 ACK 标志位为 0 的报文，也就是三次握手的第一个报文。同理，tcp.flags.syn == 1 and tcp.flags.ack == 1能筛出第二次握手的 SYN-ACK。tcp.flags是 TCP 标志位字段，syn、ack、fin、rst分别对应标志位，值为 1 表示置位。

正常情况下连接以三次握手开始、四次挥手结束，断开时能看到 FIN、ACK、FIN、ACK 四个报文：

tcp.flags.fin == 1

如果连接不是正常关闭，而是中间突然出现一个 RST 报文，说明某端直接放弃了连接。RST 出现的位置很关键：客户端发出请求后立刻收到 RST，多半是服务端端口没监听或者防火墙拒绝；数据传输过程中出现 RST，则要检查连接是否超时、负载均衡是否踢掉了后端。

书里有个案例印象很深：应用频繁报“连接被重置”，抓包后发现客户端发三次握手，服务端回了 SYN-ACK，但客户端在第三次握手时直接发 RST。问题不在服务端，而是客户端本地的安全组件在拦截。看到 RST 先别急着甩锅给服务端，用tcp.flags.rst == 1把所有 RST 报文筛出来，再看是谁先发起 RST 的。

3.2 HTTP 请求与响应：状态码、时间列和一条慢请求的定位

HTTP 是应用层里最好入手的协议。Wireshark 对 HTTP 有专门的解析器，报文列表的协议列会显示 HTTP，点开以后能看到请求行、请求头、响应状态行等。用过滤表达式可以只显示 HTTP 请求：

http.request

这条表达式筛出所有 HTTP 请求报文。配合http.response.code字段，还能按状态码进一步缩小范围：

http.response.code >= 500

只看服务端返回 5xx 错误的响应。http.response.code是 Wireshark 解析出的 HTTP 状态码字段，取值范围 100 到 599，写成>= 500一次覆盖所有 5xx 错误。

排查“某个接口很慢”时，我一般先在列配置里加两列：Time since previous displayed packet和http.time。前者看两条报文之间的间隔，后者是 Wireshark 直接算出的请求到响应总耗时。如果请求发出后http.time很大，说明服务端处理慢；如果http.time不大但页面还是卡，问题多半不在这个请求本身。

举一个实际例子：页面里一张图片请求耗时 2 秒，过滤出该图片的 TCP 流后，发现 HTTP 请求响应的http.time只有 50 毫秒，但 TCP 层显示大量重传。2 秒的延迟根本不是服务器慢，而是链路丢包触发了 TCP 重传。看 HTTP 之前先看 TCP，这个习惯能避掉不少弯路。

3.3 UDP/DNS：一次域名解析超时是如何拖垮整个页面的

很多时候页面打不开，问题出在 DNS。DNS 默认走 UDP 53 端口，Wireshark 里过滤dns就能看到查询和响应。一个典型的解析过程是：客户端发 DNS 查询报文，服务端回 DNS 响应报文，两者通过dns.id字段关联。

dns.flags.response == 1

这条表达式筛出所有 DNS 响应报文。dns.flags.response为 1 表示响应，0 表示查询。配合dns.qry.name可以查特定域名：

dns.qry.name contains "example.com"

contains是字段包含匹配，用于模糊查找域名。

排查 DNS 超时有一条典型路径：客户端发了一个 DNS 查询，但 Wireshark 里看不到响应，先看这个查询走了哪个 DNS 服务器，再确认本机到 DNS 服务器之间 UDP 53 端口是否通。如果能看到响应但响应时间很大，再看dns.time字段。

书里讲 UDP 时特意强调：UDP 没有重传机制，所以“丢包”在 UDP 上表现为客户端发了请求但没有响应，不会像 TCP 那样看到重传。排查基于 UDP 的业务（DNS、NTP、视频流）时，不能用tcp.analysis.retransmission这种过滤，判断依据只能是“发出去了多少、回回来多少”。用 IO Graph 把发出去的请求数和返回的响应数画成两条曲线对比，一眼就能看出丢包率。

4. 过滤语法与性能定位：从几百 MB 报文里捞出那 0.1 秒的异常

抓包容易，分析难。难在几十万条报文里，绝大多数是无关流量。书里后面几章花了不少篇幅讲过滤和性能分析，这一章挑三个最常用的讲：显示过滤器进阶语法、Expert Info、以及重传/延迟定位。这三个技能掌握好，日常排障基本够用。

4.1 显示过滤器语法进阶：比较、逻辑组合与字段函数

显示过滤器除了==和and，还有一批实用运算符。比较运算支持!=、>、<、>=、<=；逻辑运算支持and、or、not；字段函数支持contains、matches。

frame.len > 1400 and ip.src == 192.168.1.10

这条表达式筛出来自 192.168.1.10 且报文长度大于 1400 字节的包。frame.len是整帧长度，常用于找出大包或接近 MTU 的包。ip.src只匹配源地址，想同时匹配源或目的就改用ip.addr。

matches支持正则表达式，适合做安全分析时匹配特征：

http.request.uri matches "^/admin"

这条表达式筛出 URI 以/admin开头的 HTTP 请求。matches本质是正则匹配，比contains灵活，但更消耗 CPU，报文量大时要慎用。

还有两个日常很实用的组合表达式。一个是排除健康检查流量：

not http.user_agent contains "kube-probe"

另一个是找出某个 IP 的所有 TCP 异常：

ip.addr == 192.168.1.10 and (tcp.analysis.flags or tcp.analysis.retransmission)

tcp.analysis.flags是 Wireshark 对专家信息的汇总字段，只要报文有异常就会置位，和tcp.analysis.retransmission一起用，可以一次把该 IP 的所有 TCP 异常报文捞出来。

写过滤表达式时遇到不确定的字段名，不要在输入框里瞎猜。Wireshark 的“表达式”对话框里可以按协议名搜索字段，选出来的字段名不会拼错。过滤输入框会显示红色或绿色背景，绿色表示语法正确，红色表示有错，看到红色先停下来检查。

4.2 Expert Info 与 IO Graph：不用肉眼扫描几千个包

几十万条报文靠人眼扫是不现实的。Wireshark 提供两个自动分析入口：Expert Info 和 IO Graph。

Expert Info 在“分析”菜单里，把专家系统发现的异常按严重程度分级，分为错误、警告、注意、聊天四个级别。打开后优先看 Error 和 Warning 两类，它们往往直接指向问题根源。TCP 重传、重复 ACK、零窗口、连接重置都会在 Expert Info 里集中展示，不用自己一条条翻。

IO Graph 在“统计”菜单里，可以按时间画出报文数量或特定事件的数量。默认 Y 轴是“所有流量”，更实用的做法是改成重传次数：

tshark -r big_capture.pcapng -z io,stat,10,"tcp.analysis.retransmission"

这条命令按每 10 秒一个区间，统计整个 pcap 文件里的 TCP 重传次数。-z io,stat是 tshark 的统计模块，10是时间区间长度（秒），引号内是统计用的过滤表达式。跑完输出的表格显示每个时间段的包数、平均每秒包数和重传次数，配合界面里的 IO Graph，能快速定位重传集中在哪个时间段。

IO Graph 定位故障的思路是：先把流量总曲线画出来，看有没有异常的尖峰或断崖；再把重传曲线叠加到同一张图上。如果重传尖峰和业务流量尖峰完全重合，说明业务高峰时段链路质量下降，需要检查带宽或交换机端口错误计数。

4.3 重传、延迟与丢包：三个排障表达式解决八成问题

TCP 排障绕不开三个核心指标：重传、往返时延、吞吐。书里给的案例基本围绕这三个指标展开。

tcp.analysis.retransmission

过滤所有重传包。如果重传比例不高，比如几千个包里有个位数，通常是链路偶发丢包，不影响大局；如果重传比例超过 1%，就要认真查了。

tcp.analysis.ack_rtt

这是 Wireshark 计算的 TCP 往返时间，单位是秒。tcp.analysis.ack_rtt字段只在被确认为 ACK 的报文中出现，数值越大表示一次往返耗时越长。通过它可以看到同一连接在不同时段的 RTT 变化，RTT 突然变大的时间段往往对应丢包或网络拥堵。

看吞吐的话，在“统计 -> TCP 流图”里看时间与序号的关系。斜率代表吞吐：平缓说明连接闲置或窗口小，陡峭说明数据在快速传输。

下面用一个表把这三个指标的过滤表达式和用途列清楚：

补一个容易踩的坑：tcp.analysis类字段是 Wireshark 专家系统推算出来的，不是报文里本来就有的字段。说“重传率高”时，先确认用的是tcp.analysis.retransmission，而不是tcp.flags.retransmission——后者根本不存在，不少人在这里写错过。

5. 常见问题与避坑：Wireshark 里五个高频翻车现场

Wireshark 用起来门槛不高，但实际落地的坑不少。下面五条是抓包排障中最常遇到的翻车现场，每条按现象、原因、解决来讲，基本都是实际踩过或帮别人排查过的。

5.1 捕获接口一片空白

现象：打开 Wireshark 后接口列表是空的，一个可选的网卡都没有。

原因：Windows 上多半是 Npcap（或老版本 WinPcap）没装好，或安装时取消了“支持抓包”的选项；Linux 上通常是当前用户对 BPF 设备没有权限，或者内核模块没加载。

解决：Windows 用户以管理员身份重新安装 Npcap，装完重启 Wireshark。Linux 用户先确认dumpcap能不能用，不行就执行sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap给抓包程序授权。这只是让普通用户能抓包，不影响协议分析结果。

5.2 过滤表达式被标红但不生效

现象：输入过滤表达式后文本框变红，按回车没反应；或者语法看起来对，但结果为空。

原因：变红是语法错误，字段名写错、布尔运算符大小写不对最常见。比如ip.addr写成大写、and写成了AND（Wireshark 的布尔运算符是小写）、字段名和值之间少了空格。结果为空则可能是字段名本身不存在，或值类型不对，比如用字符串去跟数字字段比较。

解决：不要在输入框里手敲，从“表达式”对话框里选字段；改一个按一次回车看颜色。确认语法没问题后，先不过滤全部报文，确认目标报文确实存在，再逐步收紧条件。

5.3 抓到的包时间对不上，差 8 小时

现象：Wireshark 里报文显示的时间和业务日志、服务器日志对不上，普遍差 8 小时。

原因：Wireshark 默认按 UTC 显示时间，国内业务日志一般用北京时间（UTC+8）。这是显示问题，不是抓包数据有问题。

解决：在“视图 -> 时间显示格式”里选择本地时区，或者在捕获选项里把时间格式改成“日期和时间（本地）”。改完以后所有报文的显示时间变成北京时间，能和业务日志逐条对上。

5.4 HTTPS 只看到 TLS，看不到 HTTP 明文

现象：抓 HTTPS 流量时只能看到 Client Hello、Server Hello 这些 TLS 握手报文，看不到请求和响应内容。

原因：HTTPS 用 TLS 加密，Wireshark 默认拿不到会话密钥，只能解析出 TLS 层框架。

解决：让浏览器导出密钥日志。在 Chrome/Firefox 中设置环境变量SSLKEYLOGFILE指向一个文件，浏览器会把 TLS 会话密钥写进这个文件。然后在 Wireshark 的“协议首选项 -> TLS”里配置密钥日志文件路径，重新抓包或重新读 pcap，就能看到解密后的 HTTP 明文。注意抓包文件里必须包含完整的 TLS 握手过程，否则即使有密钥也无法解密。

5.5 混用模式没开，漏抓了一堆包

现象：抓包时只看到本机发起的流量和广播流量，其他主机的通信一概看不到。

原因：普通网卡默认只接收发往自己地址的帧，交换机也不会把别的端口流量复制过来。要覆盖其他主机，必须打开混用模式（Promiscuous Mode），并配合交换机的端口镜像或 TAP 设备。

解决：在捕获选项里勾选“在所有接口使用混用模式”。如果抓的还是不全，说明核心交换机默认隔离端口，需要在交换机上配置 SPAN/RSPAN 端口镜像，或者在网络出口串一个集线器/TAP。混用模式不是万能的，办公网这类有端口隔离的环境，不开镜像就是抓不全。

6. 进阶：把 tshark 和配置固化成本地的排障工具箱

Wireshark 的界面交互做得好，但遇到这两种情况就得换工具：一是 pcap 文件特别大，打开界面就卡死；二是要重复跑同一个过滤分析几十个文件。tshark 正好解决这两个问题。

6.1 用 tshark 把 pcap 变成可批量统计的文本

tshark 是 Wireshark 的命令行版本，同一套解析引擎，跑起来比界面轻量得多。比如想知道一个 pcap 里所有 HTTP 请求的源 IP、目的 IP、URI 和响应状态码：

tshark -r http.pcapng -Y "http.request or http.response" -T fields -e ip.src -e ip.dst -e http.request.uri -e http.response.code -E separator=,

-r读取文件，-Y应用显示过滤器，-T fields指定输出为字段列表，-e按顺序指定要输出的字段，-E separator=,把分隔符设为逗号。输出直接可以导入 Excel 或进一步用脚本处理。一个几百 MB 的文件，这个命令几秒钟就能出结果，不用打开界面慢慢翻。

6.2 把常用过滤表达式存成配置文件

每次重新输入过滤表达式既慢又容易出错。更可靠的做法是把过滤器写进一个纯文本配置文件，跟着自己的工具箱一起同步：

# tshark_filter.txt # 常用显示过滤器，配合 -Y 参数使用 HTTP_ERR="http.response.code >= 500" TCP_RETRANS="tcp.analysis.retransmission" DNS_QUERY="dns.flags.response == 0"

用的时候直接tshark -r file.pcapng -Y "${HTTP_ERR}"引用。这样省去了每次回忆字段名的成本，也避免了拼写错误。

6.3 用 profile 和着色规则保存常用视图

Wireshark 支持多套 profile（配置集），每套 profile 可以有自己的列配置、着色规则和过滤按钮。我会建一个 troubleshooting 的 profile：列配置里加好Time since previous displayed packet、TCP Stream index、http.response.code，着色规则把重传标红、RST 标紫、DNS 查询标蓝。排障的时候切到这套 profile，所有配置一次到位，不用每次重新调。

从那以后，我每次拿到一个不明原因的 pcap，都强制走一遍这个流程：先看 Expert Info 里的 Error 和 Warning，再用 tshark 拉一遍统计，最后才回到界面看具体报文。这套流程相当于给排查过程上了保险，希望帮到你。

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