简介：这是一份面向计算机网络课程学习者与实验备考学生的Wireshark HTTP协议分析实验报告，围绕抓包工具的实际使用与协议报文解析展开，适合正在完成课程实验、准备网络原理考核或希望夯实应用层协议基础的读者。压缩包内共1个docx文档，约223KB，内容以实验步骤、报文截图与逐字段分析为主，结构紧凑便于直接参考。报告完整呈现了访问百度时的抓包过程，涵盖清除浏览器缓存以观察完整三次握手、请求报文与响应报文的固定格式、请求行与状态行组成、常用请求头与响应头含义，以及POST请求与200 OK响应的逐字段解读，并对比302重定向等状态码差异。目前已有9262人学习下载，可作为实验报告撰写模板与HTTP协议复习笔记使用。
1. 从一次「网页明明能开，报告却写不出来」说起
Wireshark 抓包做 HTTP 协议分析，几乎是每门计算机网络课都绕不开的实验。标题里这几个词——Wireshark、HTTP 协议、协议分析、实验报告——看着简单，真动手时翻车的人一大片：抓到的包全是 TCP 重传和乱序，HTTP 请求一条都看不见；或者抓是抓到了，但报告里除了贴几张截图，讲不出请求行、状态码、首部字段到底说明了什么。这个实验真正要练的不是「会点开始按钮」，而是能从一串原始字节里读出 HTTP 的报文结构、请求响应流程和连接行为，并且把结论写成别人能复现的分析。
这篇笔记面向三类人：第一次做这个实验、需要一份能照着跑通的步骤；做过但报告写得虚、想补上参数和判据的；以及想把这套抓包分析方法迁移到排查真实接口问题的。我会按「环境准备 → 抓包 → 报文逐层拆解 → 连接与缓存行为 → 排错」的顺序讲，每个环节给出可抄的命令、过滤表达式和判据。工具版本以你本机安装的为准，Wireshark 官网下载安装即可，不绑定具体版本号。抓包分析这件事，玄学不多，坑基本都在过滤器和时间戳上，下面逐个说清。
2. 环境准备与抓包前的三个关键设置
2.1 选对网卡，别在错误的接口上守株待兔
Wireshark 安装完成后第一件事是选接口。很多人打开软件直接点最上面那个接口就开始抓，结果一个 HTTP 包都没有——因为流量根本没走那块网卡。判断方法很简单：先看本机默认路由走哪个网卡，再抓那个。
Windows 上用ipconfig，Linux/macOS 上用ip route或ifconfig，找到有默认网关的那块。有线网卡通常叫eth0、en0、以太网，无线叫wlan0、Wi-Fi。如果你用的是虚拟机做实验，注意抓包位置：抓宿主机物理网卡看到的是虚拟网卡桥接后的流量，抓虚拟机内部网卡看到的才是虚拟机自己的流量，两者视角不同，报告里要写清楚。
提示：抓本机访问本机（比如本地起的 Web 服务）的流量，物理网卡上往往抓不到，因为流量走的是 loopback。Windows 上需要装 Npcap 时勾选回环支持，Linux 直接抓
lo接口。
2.2 抓包过滤器与显示过滤器，别混用
这是新手最容易翻车的地方。Wireshark 有两套语法完全不同的过滤器：
| 类型 | 位置 | 语法示例 | 作用时机 |
|---|---|---|---|
| 抓包过滤器 BPF | 捕获选项里 | tcp port 80 | 抓之前，决定哪些包被记录 |
| 显示过滤器 | 顶部过滤栏 | http | 抓之后，决定哪些包被显示 |
抓包过滤器用的是 BPF 语法，写错了直接抓不到东西；显示过滤器写错了只是过滤栏变红。做 HTTP 实验，我一般抓包时用tcp port 80先把范围缩小，避免抓到一堆无关流量把缓冲区冲爆，抓完再用显示过滤器精挑。
# 抓包过滤器（BPF 语法），填在 Capture Options 的输入框 tcp port 80 # 如果要同时抓 HTTPS 的握手，可以放宽到 tcp port 80 or tcp port 443逻辑说明：tcp port 80表示只记录 TCP 且源或目的端口为 80 的报文。HTTP 明文默认走 80，所以这一条足够覆盖绝大多数实验场景。参数上，port可以换成host 目标IP来锁定某台服务器，多个条件用and、or连接。注意 BPF 里没有http这个关键字，那是显示过滤器的东西，写进抓包过滤器会报语法错误。
2.3 时间戳改成可读格式，报告才讲得清时序
默认时间列是「距第一个包的秒数」，做时序分析时反而不直观。建议改成绝对时间：菜单 View → Time Display Format → Time of Day（或 Date and Time of Day）。这样报告里写「14:32:07 发出请求，14:32:07.083 收到响应」比写「第 0.083 秒」清楚得多。
另外打开 View → Name Resolution，把「Resolve Network Addresses」关掉。开着的话 Wireshark 会尝试反查 DNS，抓包时可能引入额外流量，还会让 IP 显示成域名，干扰你判断真实的目标地址。做协议分析要的是原始 IP，不是解析后的名字。
注意：如果你在报告里需要展示北京时间，Wireshark 默认按系统时区显示，确认系统时区正确即可，不需要额外装插件。网上有些教程让你改注册表或装扩展，多数场景没必要。
3. 抓一次完整的 HTTP 请求响应：从过滤到定位
3.1 用显示过滤器把 HTTP 报文捞出来
抓完一段流量后，过滤栏输入http，回车。Wireshark 会把所有被识别为 HTTP 的报文列出来。如果一条都没有，先别急着怀疑人生，按这个顺序排查：
第一，确认你访问的是 http:// 而不是 https://。现在大量网站默认跳 HTTPS，浏览器地址栏有小锁头就说明是加密流量，Wireshark 只能看到 TLS 握手，看不到 HTTP 内容。做实验要找一个明确支持明文的站点，或者自己在本机起一个简单的 HTTP 服务。
第二，确认端口。有些服务跑在 8080、8000 等非标准端口，http过滤器默认只认 80 等标准端口。这种情况用tcp.port == 8080先看原始 TCP，再右键报文选 Decode As → HTTP 强制解码。
第三，确认抓包过滤器没把包滤掉。回到 2.2 检查。
3.2 用本机服务做一次可控实验
依赖外部网站做实验有个问题：你控制不了服务器行为，也复现不了。更稳的做法是在本机起一个 HTTP 服务，用 curl 发请求，全程可控。
# 用 Python 起一个最简单的 HTTP 服务，监听 8000 端口 python3 -m http.server 8000 # 另开一个终端，发一次请求 curl -v http://127.0.0.1:8000/逻辑说明：python3 -m http.server 8000会在当前目录起一个静态文件服务，任何 GET 请求都会返回目录列表或文件内容。curl -v的-v打开详细模式，终端里会打印出请求行、请求头和响应头，和 Wireshark 里抓到的内容一一对应，方便对照。
参数说明：端口 8000 可以换成任意未占用端口，但换了之后 Wireshark 的显示过滤器也要跟着改，用tcp.port == 8000。如果抓 loopback 抓不到，参考 2.1 的提示确认回环支持已开启。
3.3 在报文详情里逐层读结构
选中一条 HTTP 请求报文，下方详情面板会按协议栈分层展开。做 HTTP 分析，重点看三层：
Frame / Ethernet：物理帧信息，看帧长度、源 MAC、目的 MAC。报告里如果要写「该请求帧共 XX 字节」，数据从这里取。
IP：看源 IP、目的 IP、TTL。TTL 能粗略反映经过了多少跳，实验里一般不用深究，但写报告时提一句体现你看了。
TCP：看源端口、目的端口、序号、确认号、标志位。HTTP 建立在 TCP 之上，理解请求响应必须先看懂 TCP 这一层。标志位里PSH, ACK表示这是携带数据的报文，SYN是连接建立，FIN是连接关闭。
HTTP：这才是主角。展开后能看到请求方法、URL、协议版本、各个首部字段。Wireshark 会把首部字段名和值分列显示，鼠标悬停还能看到字段含义的简要说明。
提示：右键任意报文 → Follow → TCP Stream，能把整条 TCP 连接上的所有数据拼成一个可读的会话窗口，请求和响应交替显示，做报告截图时比单条报文更直观。但注意这个窗口里显示的是重组后的应用层数据，看不到 TCP 首部，两者要配合看。
3.4 请求行、状态行、首部字段的判读要点
一条典型的 HTTP 请求长这样：
GET /index.html HTTP/1.1 Host: 127.0.0.1:8000 User-Agent: curl/8.4.0 Accept: */*请求行三段：方法（GET）、请求目标（/index.html）、协议版本（HTTP/1.1）。方法里 GET 和 POST 是实验最常考的，GET 把参数放 URL，POST 放请求体。协议版本决定连接行为，1.1 默认长连接，1.0 默认短连接，这一点在分析连接复用时会用到。
响应长这样：
HTTP/1.1 200 OK Server: SimpleHTTP/0.6 Python/3.11 Date: ... Content-type: text/html Content-Length: 1234状态行三段：协议版本、状态码、原因短语。状态码要能说出类别：1xx 信息、2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务端错误。实验里常见的是 200、304、404。304 是协商缓存命中，这个在下一章展开。
首部字段里，Host是 HTTP/1.1 强制要求的，用于虚拟主机区分；Content-Length和Content-Type描述响应体；Connection: keep-alive或close直接决定连接是否复用。报告里挑三到五个字段解释清楚，比把所有字段抄一遍有价值。
4. 连接行为与缓存：把「看得见的包」讲成「说得清的原理」
4.1 用 TCP 流看长连接与短连接的区别
HTTP/1.1 默认长连接，一次 TCP 握手后可以发多个请求。验证方法：在浏览器里打开一个含多张图片的页面，抓包后用http过滤，观察是不是只有一对 SYN/ACK 握手，后面跟着多条 HTTP 请求复用同一个 TCP 连接。
对比实验：用curl --http1.0强制 HTTP/1.0 发两次请求，会看到两次独立的 TCP 三次握手。这个对比写进报告，比单纯描述「HTTP/1.1 支持长连接」有说服力得多。
# 强制 HTTP/1.0，观察短连接行为 curl --http1.0 -v http://127.0.0.1:8000/ > /dev/null curl --http1.0 -v http://127.0.0.1:8000/ > /dev/null逻辑说明：两次独立调用 curl，每次都会新建 TCP 连接。抓包时用tcp.port == 8000过滤，数一数 SYN 报文出现了几次，就能直观看到短连接的开销。参数--http1.0是关键，不加的话 curl 默认用 1.1，会复用连接，实验现象就不明显了。
4.2 304 状态码与协商缓存怎么抓
304 Not Modified 是 HTTP 缓存机制的核心现象，也是实验报告里容易出彩的点。复现步骤：
第一次请求资源，服务器返回 200 并带上Last-Modified或ETag。第二次请求同一资源，浏览器（或 curl）带上If-Modified-Since或If-None-Match，服务器判断资源没变，返回 304 且不带响应体。
# 第一次请求，记录响应头里的 ETag 或 Last-Modified curl -v http://127.0.0.1:8000/ 2>&1 | grep -i -E "etag|last-modified" # 第二次带上条件请求头 curl -v -H "If-Modified-Since: <上一步的时间>" http://127.0.0.1:8000/逻辑说明：-H手动注入条件请求头，模拟浏览器的缓存协商行为。服务器如果支持，会返回 304。注意 Python 自带的 http.server 对条件请求支持有限，可能一直返回 200，这时候换一个支持缓存的服务器（比如 nginx）或者用真实网站做对比实验。
参数说明：If-Modified-Since的值必须是合法的 HTTP 日期格式，直接从第一次响应的Last-Modified复制即可。If-None-Match对应ETag，优先级更高。报告里把两次请求的报文并排贴出来，标出差异字段，就是一份合格的分析。
4.3 用统计功能给报告加一张有信息量的图
Wireshark 的 Statistics 菜单里有几个做报告很好用的功能：
Statistics → HTTP → Requests，会按请求方法、主机、URI 汇总，直接给出请求分布表。Statistics → Conversations，按 TCP 会话列出每条连接的包数、字节数、持续时间，用来证明长连接复用了多少数据非常直观。Statistics → Flow Graph，能生成时序图，展示请求响应的时间关系。
这些图比随手截的报文列表更能体现你理解了流量结构。报告里放一张 Conversations 表，配一句「本次实验共 X 条 TCP 连接，其中 Y 条承载了多个 HTTP 请求，验证了 HTTP/1.1 的长连接特性」，比空谈原理强。
注意：Flow Graph 生成的是基于当前过滤结果的图，生成前先确认过滤栏里的条件是你想要的，否则图里会混入无关流量。
5. 避坑与排查：五个高频翻车现场
5.1 抓不到 HTTP，只有 TCP 和 TLS
现象：过滤栏输入http一条不显示，但tcp能看到大量报文，且端口是 443。
原因：访问的是 HTTPS 站点，HTTP 内容被 TLS 加密，Wireshark 无法解密应用层。
解决：换用明文 HTTP 站点，或本机起 HTTP 服务。如果实验必须分析 HTTPS，那属于 TLS 分析范畴，需要配置密钥日志，超出本实验范围，报告里说明清楚即可，不要硬套 HTTP 分析结论。
5.2 报文乱序、重传一大堆，HTTP 请求被淹没
现象：抓到的包里大量TCP Retransmission、TCP Out-of-Order，找一条完整 HTTP 请求很费劲。
原因：抓包位置不对（比如抓了镜像口但镜像配置有问题），或者网络本身拥塞，或者抓的是无线网卡且信号差。
解决：优先抓本机回环或本机与网关之间的流量，减少中间环节。用显示过滤器http直接跳过 TCP 层噪声。如果重传确实很多，报告里可以作为一个观察点写进去，但不要把它当成 HTTP 分析的主体。
5.3 显示过滤器写对了却提示语法错误
现象：过滤栏输入http and ip.addr == 192.168.1.1变红。
原因：多半是空格或运算符问题。Wireshark 显示过滤器里==和eq等价，但and两边要有空格；ip.addr是合法字段，写成ipaddr就错。
解决：用过滤栏右侧的「Expression」按钮可视化构造，避免手写拼错。常见合法写法：http.request.method == "GET"、http.response.code == 304、tcp.port == 8000。
5.4 时间列显示成奇怪的大数字
现象：时间列不是秒数也不是可读时间，而是一串很大的值。
原因：时间显示格式被设成了「Seconds Since Epoch」或类似格式。
解决：View → Time Display Format 里改回 Time of Day 或 Seconds Since Beginning of Capture。做时序对比用后者，写绝对时间用前者。
5.5 报告里只有截图没有分析
现象：报告交上去被批「只是截图堆砌」。
原因：没有把报文里的字段和 HTTP 协议规范对应起来。
解决：每贴一张截图，配一段文字说明「这条报文的请求方法是 X，协议版本是 Y，首部字段 Z 的作用是……，它体现了 HTTP 的某某特性」。截图是证据，分析才是结论。判据要具体到字段值，不要写「可以看到请求正常」这种废话。
6. 把实验做深：从单次抓包到可复用的分析方法
做完基本流程后，如果想把这个实验做出区分度，我一般会加两件事。
第一件是构造异常场景做对比。正常请求谁都会抓，但 404、500、重定向 301/302 这些状态码背后的报文差异，才是真正考验理解的地方。用本机服务故意请求一个不存在的路径，抓 404 响应，对比 200 响应的首部字段差异——404 通常没有Content-Length对应的实体内容，或者实体是错误页面。再手动构造一个 302 跳转，观察Location首部如何指示浏览器发起第二次请求。这些对比写进报告，深度立刻不一样。
第二件是把过滤表达式整理成一张自己的速查表。下面这几个是我做 HTTP 分析时用得最多的：
| 目的 | 显示过滤器 |
|---|---|
| 只看 HTTP 请求 | http.request |
| 只看 GET 请求 | http.request.method == "GET" |
| 只看某个状态码 | http.response.code == 304 |
| 看某个 Host 的流量 | http.host contains "example" |
| 看含特定首部的报文 | http.header contains "If-Modified-Since" |
| 按 TCP 端口锁定 | tcp.port == 8000 |
这张表建议自己敲一遍，比背下来管用。过滤器的价值在于快速缩小范围，范围越小，你越容易注意到异常字段。
最后一个习惯：每次抓包前先想清楚「我要验证什么」，带着问题抓，而不是抓完一堆再想分析什么。我早期做实验就是先抓一大坨，然后对着几千条报文发呆，最后只能挑几条顺眼的截图交差。后来改成先写下一句假设，比如「HTTP/1.1 会复用 TCP 连接」，再去抓包验证，效率完全不一样。抓包分析的本质是验证假设，不是收集数据。希望帮到你。
本文还有配套的精品资源，点击获取
