企业官网建设流程全解析

简介：这份资源是计算机网络原理课程的Wireshark实验报告，面向正在学习HTTP协议、需要完成抓包分析作业的高校学生与网络初学者。报告以访问www.baidu.com为例，完整呈现了从清除浏览器缓存、抓取WLAN端口数据包到逐层解析Frame、Ethernet II、IP、TCP与HTTP的过程，并给出请求报文与响应报文的固定格式说明。内容重点拆解了请求行中的请求方法、URI与协议版本，请求头部的Host、User-Agent、Connection、Content-Type等字段，以及状态行中的状态码含义、响应头与响应体的作用，还结合POST请求实例逐项标注各数据单元。资源包为1个docx文档，约223KB，结构紧凑、图文对照，适合直接参考撰写实验报告或复习HTTP报文格式。目前已有9260人学习下载，可帮助读者快速掌握抓包分析流程与协议字段含义，理解三次握手、状态码200与302差异等常见考点。

1. 从一次“网页打不开”说起：Wireshark 抓 HTTP 到底在抓什么

浏览器转圈、页面白屏、接口 502，运维群里一句“网络有问题”往往没人能立刻说清问题出在哪一层。这时候把 Wireshark 打开，选对网卡，过滤框里敲下http，点一次刷新，几十个报文瞬间刷屏——这就是计算机网络原理实验里最经典的一幕：用 Wireshark 做 HTTP 协议分析。它解决的不是“怎么修网络”，而是“怎么看见网络”：把 HTTP 请求行、请求头、响应码、响应体这些平时藏在浏览器开发者工具背后的东西，还原成一个个可逐字节检查的 TCP 载荷。适合正在做计算机网络实验报告的学生，也适合刚接触抓包、想搞懂 HTTP 协议分析到底怎么落地的后端和测试同学。抓包不是玄学，但选错网卡、抓错端口、看不懂 TCP 流重组，翻车是常事。

2. 抓包前的环境准备：网卡、过滤器与 HTTPS 的现实边界

2.1 选对网卡：为什么你抓到的全是“背景噪音”

Wireshark 安装完成后第一件事不是点开始，而是确认抓哪块网卡。笔记本通常同时存在有线网卡、无线网卡、Loopback（回环）以及一堆虚拟网卡（VMware、Docker、VirtualBox 各占一个）。如果实验要求分析本机浏览器访问外部 Web 服务器的 HTTP 流量，就必须选当前实际承载上网流量的那块——有线插着就选以太网，连 Wi-Fi 就选 WLAN。选错网卡的典型现象是：过滤器写了http，抓了半天一个包都没有，或者全是 ARP、mDNS、SSDP 这类局域网广播。

判断方法很直接：在 Wireshark 主界面看每块网卡右侧的实时波形，有流量起伏的那块就是目标网卡。更稳妥的做法是先打开命令行执行一次ping，观察哪块网卡的波形跟着跳动。

# Windows 下查看本机网卡与 IP 对应关系 ipconfig /all # Linux/macOS 下查看网卡列表与状态 ifconfig -a # 或 ip link show

上面命令的作用是把“网卡名字”和“IP 地址”对应起来。Wireshark 里显示的Intel(R) Wi-Fi 6 AX201这类名称，和ipconfig里的“无线局域网适配器 WLAN”是同一块。参数上重点看两点：一是网卡是否处于UP状态，二是它拿到的 IPv4 地址是不是你上网用的那个网段。如果一块网卡显示media disconnected，抓它没有任何意义。

提示：实验环境里如果用的是虚拟机，抓包位置决定你能看到什么。在宿主机抓，看到的是虚拟机 NAT 之后的流量；在虚拟机内部抓，看到的才是虚拟机自己发出的原始 HTTP 请求。做实验报告时要说清楚抓包点，否则分析结论会对不上。

2.2 过滤器怎么写：抓 HTTP 的三种粒度

Wireshark 的过滤器分两类，混淆它们是新手第一个大坑。捕获过滤器（Capture Filter）在抓包开始前设置，语法是 BPF，写错了直接抓不到；显示过滤器（Display Filter）在抓包后设置，语法是 Wireshark 自己的，写错了只是显示为空，原始数据还在。做 HTTP 协议分析，我一般捕获阶段不设限或只限端口，显示阶段再精确过滤。

这里必须点破一个现实边界：现代网站绝大多数已经全站 HTTPS。你在浏览器里访问百度、淘宝、GitHub，抓到的都是 TLS 加密流量，显示过滤器写http一个包都出不来。这不是 Wireshark 坏了，而是 HTTP 被包进了 TLS 里。要做明文 HTTP 协议分析，常见做法有三种：一是访问明确提供 HTTP 的测试站点（如http://example.com、http://neverssl.com）；二是自己在本机用 Python 起一个 HTTP 服务；三是在实验允许的范围内配置浏览器信任的抓包证书做解密——但这一步涉及证书安装，很多教学实验并不要求，报告里也不必展开。

# 本机起一个最简 HTTP 服务，专门用来抓包 # Python 3 自带 http.server，无需额外安装 import http.server import socketserver PORT = 8000 # 指定一个目录作为服务根目录，放一个 index.html 进去 handler = http.server.SimpleHTTPRequestHandler with socketserver.TCPServer(("", PORT), handler) as httpd: print(f"Serving at port {PORT}") httpd.serve_forever()

这段代码的作用是在本机 8000 端口起一个静态文件服务。参数PORT可以改成任意未被占用的端口，handler默认会把当前目录作为根目录。启动后浏览器访问http://127.0.0.1:8000，Wireshark 选 Loopback 网卡（Windows 上是Adapter for loopback traffic capture，Linux 上是lo），显示过滤器写http，就能抓到完整的请求与响应。这是最可控的实验方式，因为流量不经过外部网络，不受 HTTPS 干扰。

2.3 抓包时机与 TCP 流跟踪：别只看单个包

HTTP 是应用层协议，但它跑在 TCP 之上。一个 HTTP 响应往往被拆成多个 TCP 段传输，单个包里的HTTP字段可能只显示[TCP segment of a reassembled PDU]。这时候要右键任意一个相关包，选Follow → TCP Stream，Wireshark 会把整条 TCP 连接上的载荷按方向拼起来，红色是客户端发往服务器，蓝色是服务器发往客户端。这是 HTTP 协议分析最核心的操作，没有之一。

抓包时机上，正确顺序是：先点开始抓包，再在浏览器触发请求，请求完成后停止抓包。反过来先操作后抓包，请求早就结束了，抓到的只有后续心跳。如果页面加载慢，可以边抓边刷新，但要注意过滤掉图片、字体等静态资源的干扰，聚焦到 HTML 文档或 API 接口那一条流上。

3. 逐层拆解一个 HTTP 请求：从请求行到响应体的完整链路

3.1 请求报文：GET 与 POST 在抓包里的样子

在 Wireshark 里选中一个 HTTP 请求包，中间协议树展开Hypertext Transfer Protocol，能看到请求行和各个头部字段。一个典型的 GET 请求长这样：

GET /index.html HTTP/1.1\r\n Host: 127.0.0.1:8000\r\n User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)\r\n Accept: text/html,application/xhtml+xml\r\n Accept-Encoding: gzip, deflate\r\n Connection: keep-alive\r\n \r\n

请求行由方法、URI、版本三部分组成，\r\n是行结束符，最后的空行表示头部结束。Wireshark 会把Request Method、Request URI、Request Version分别列出来，鼠标悬停就能看到原始字节。POST 请求的区别在于多了一个Content-Length头部和请求体，请求体在协议树里显示为Line-based text data或HTML Form URL Encoded。

做实验报告时，建议把同一个请求的“Wireshark 协议树截图”和“原始十六进制”对照着写。原始字节视图在 Wireshark 底部面板，能看到47 45 54 20 2f ...对应GET /。这一步是理解“协议就是约定好的字节序列”最直观的方式。

3.2 响应报文：状态码、响应头与内容编码

响应报文的结构是状态行 + 响应头 + 空行 + 响应体。状态行形如HTTP/1.1 200 OK，Wireshark 会拆出Status Code和Response Phrase。常见的状态码在抓包实验里都会遇到：200 正常、301/302 重定向、304 缓存命中、404 资源不存在、500 服务器内部错误。

响应头里几个字段值得重点分析：

• Content-Type：告诉浏览器响应体是什么类型，text/html和application/json的处理方式完全不同。
• Content-Length：响应体的字节数，和实际 TCP 载荷长度对不上时，要么是分块传输，要么是抓包不完整。
• Content-Encoding：常见值gzip，表示响应体被压缩过。Wireshark 默认不会自动解压，看到乱码是正常的，可以在偏好设置里开启解压。
• Set-Cookie：服务器下发的 Cookie，是理解会话机制的关键。

# 用 curl 发起请求并只看响应头，和 Wireshark 抓到的做对照 curl -I http://example.com # 输出示例： # HTTP/1.1 200 OK # Content-Type: text/html; charset=UTF-8 # Content-Length: 1256 # ...

curl -I只发 HEAD 请求拿响应头，适合快速验证。把它和 Wireshark 抓到的同一次请求对比，能确认抓包没有丢包、没有截断。参数-I换成-v会打印完整请求响应过程，适合排查“为什么 Wireshark 里看到的和预期不一样”。

3.3 用 Follow TCP Stream 还原一次完整会话

选中任意一个 HTTP 包，右键Follow → TCP Stream，弹出的窗口会把整条 TCP 连接的应用层数据按时间顺序拼好。窗口底部有过滤按钮，点Filter Out This Stream可以把这条流从主界面隐藏，方便聚焦其他连接。

这个功能在分析“一次页面加载到底发了几个请求”时特别有用。现代网页一个 HTML 文档会引用 CSS、JS、图片，浏览器会并发开多条 TCP 连接。在 Wireshark 里用tcp.stream eq 0、tcp.stream eq 1逐个查看，能数清楚一共几条流、每条流上跑了什么。实验报告里如果能画出“一次页面加载的 TCP 流数量与用途”表格，分析深度会明显高于只贴一张截图。

注意：Follow TCP Stream 显示的是重组后的数据，顺序和实际网络传输顺序可能不同。如果要做时序分析，还是要回到主界面的包列表，看每个包的Time列和Seq列。

4. 实验报告里最容易翻车的五个坑

4.1 抓不到包，过滤器却没问题

现象：显示过滤器写http，抓包界面一片空白，但浏览器明明在访问网页。原因：九成是网卡选错，或者访问的是 HTTPS 站点。剩下的一成是捕获过滤器设了port 80但实际走的是 8080 等非标准端口。解决：先清空捕获过滤器，确认网卡波形有跳动；再访问http://neverssl.com这类强制明文的站点验证。如果还是不行，检查浏览器是否开了代理插件，代理会把流量导向本地端口，抓包位置就变了。

4.2 看到[TCP segment of a reassembled PDU]就以为抓包失败

现象：协议树里 HTTP 字段不完整，只显示 TCP 段。原因：HTTP 响应体较大，被 TCP 拆成多个段传输，Wireshark 需要等所有段到齐才能重组出完整 PDU。解决：右键选 Follow TCP Stream，或者等抓包停止后再看。如果始终不重组，可能是抓包中途停止导致后续段丢失，重新抓一次并确保请求完整结束。

4.3 响应体显示乱码

现象：Follow TCP Stream 里响应体是一堆看不懂的字符。原因：服务器返回了Content-Encoding: gzip，Wireshark 默认不解压。解决：菜单Edit → Preferences → Protocols → HTTP，在Uncompressed entity body处填入支持的压缩格式，或勾选相关解压选项。重启 Wireshark 后重新抓包即可看到明文。

4.4 时间戳对不上，分析时序时结论错误

现象：报告里写的“请求发出后 200ms 收到响应”，和实际体感不符。原因：Wireshark 默认显示的是相对时间（Relative Time），基准是第一个包，不是绝对时间。解决：菜单View → Time Display Format切换为Time of Day看绝对时间，或Seconds Since Beginning of Capture看相对时间。做性能分析时统一用相对时间，做日志对照时用绝对时间。

4.5 实验报告只贴截图，没有字节级证据

现象：报告里全是 Wireshark 界面截图，老师问“请求行第几个字节是空格”答不上来。原因：只看了协议树的友好显示，没看原始字节。解决：每个关键报文都补一张底部十六进制面板的截图，标出GET、HTTP/1.1、\r\n对应的字节。这一步是区分“会用工具”和“懂协议”的分水岭。

5. 从抓包到验证：把 HTTP 分析做成可复现的检查清单

5.1 一套可复用的抓包验证流程

做完一次 HTTP 协议分析，怎么确认结论可靠？我一般按下面这个顺序过一遍：

1. 确认抓包点：在报告里写明是在宿主机、虚拟机还是 Loopback 抓的，对应哪块网卡。
2. 确认流量类型：用http过滤器确认是明文 HTTP，不是 TLS。
3. 确认会话完整：用 Follow TCP Stream 确认请求行、请求头、空行、响应行、响应头、响应体六部分齐全。
4. 确认字节对照：至少挑一个请求和一个响应，把协议树字段和十六进制字节对应起来。
5. 确认时序合理：用Time列确认请求在前、响应在后，中间没有异常重传。

这套流程走下来，实验报告里的每个结论都有抓包证据支撑，不是“看起来是这样”。

5.2 用 tshark 做批量验证

图形界面适合分析单个会话，但如果要验证“10 次请求的状态码分布”这类统计结论，命令行工具tshark更高效。它是 Wireshark 的命令行版本，安装 Wireshark 时自带。

# 抓 100 个包并只输出 HTTP 请求方法和 URL tshark -i eth0 -c 100 -Y "http.request" -T fields -e http.request.method -e http.request.uri # 统计响应码分布 tshark -r capture.pcap -Y "http.response" -T fields -e http.response.code | sort | uniq -c # 导出所有 HTTP 请求的 Host 头 tshark -r capture.pcap -Y "http.request" -T fields -e http.host | sort -u

参数说明：-i指定网卡，-c指定抓包数量，-r读取已有 pcap 文件，-Y是显示过滤器（和图形界面语法一致），-T fields表示按字段输出，-e指定要输出的字段名。字段名可以在 Wireshark 协议树里右键字段选Copy → As Filter查到。这三条命令分别解决“抓了什么请求”“响应码怎么分布”“访问了哪些主机”三个报告里高频出现的问题。

5.3 一个容易被忽略的技巧：给抓包文件加注释

Wireshark 允许给单个包加注释，菜单Edit → Packet Comment。做实验时，抓到关键请求就顺手加一句“这是登录请求”“这是 302 跳转”，导出 pcap 后注释会一起保存。下次打开或者交给同学复现时，不用再靠记忆找包。这个习惯在排查线上问题时同样有用——把异常时间点的包标注好，比事后翻聊天记录靠谱得多。

我自己的习惯是：每次抓包前先想清楚“我要验证哪个字段”，抓完立刻用 tshark 跑一遍统计，确认数据对得上再写报告。抓包这件事，工具只是入口，真正值钱的是你知道该看哪个字节。希望帮到你。

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