简介：本资源是一份面向计算机网络专业本科生及初学者的Sniffer工具实践教学实验报告，聚焦网络协议分析、流量捕获与安全机制验证等核心能力培养。报告完整覆盖ICMP抓包分析、HTTP/HTTPS流量监控、ARP包构造与发送、ARP欺骗模拟及交换机端口镜像配置五大实验模块，辅以Wireshark实操细节、过滤器设置、协议字段解析及异常流量研判方法，助力读者深入理解TCP/IP栈各层通信原理与常见网络问题排查路径。资源为单个Word文档（.doc格式），文件大小1.02MB，内容结构清晰，含实验目的、平台说明、分步过程、数据截图分析及实验心得，便于直接用于课程作业参考或自学复盘。目前已有849人学习下载，适合网络工程实训、信息安全入门及协议分析能力提升场景使用。
1. 为什么一份 Sniffer 工具使用实验报告，比「抓到包」本身更难写对？
很多刚接触网络协议分析的人以为：装个 Wireshark，点开始捕获，看到一堆 ARP、ICMP、DNS、HTTP 包就等于“会用了”。但真实场景中，你可能在 GNS3 里搭好双路由器+主机拓扑，却抓不到预期的 ARP 请求；用arp -a查到缓存条目，却无法对应到抓包窗口里某次广播的源 MAC；DNS 查询在命令行能解析成功，Wireshark 却只显示 UDP 发送没收到响应——这时问题不在工具，而在你是否理解每个协议在链路层、网络层、传输层和应用层的真实交互节奏。这份《Sniffer 工具使用实验报告》的本质，是把「被动观察」转化为「可验证的因果推断」：不是记录“我看到了什么”，而是通过时间戳、序列号、标志位、TTL、校验和等字段，反向还原出操作系统如何发 ARP、内核如何封装 ICMP Echo、glibc 如何调用 DNS 解析器、浏览器如何复用 HTTP 连接。它面向的是需要独立完成网络排错、协议教学演示或安全基础验证的 IT 实践者——无论你是备考 HCIA 的学生、排查华三防火墙 DNS 代理异常的运维，还是在 Linux 下调试resolv.conf修改后未生效的开发。
2. 用 Wireshark 在本地跑通 ARP/ICMP/DNS/HTTP 的最小命令与关键过滤表达式
2.1 为什么必须从本地环回（lo）和物理网卡（如 eth0）双视角捕获？
Sniffer 工具的底层原理决定了：不同协议的数据路径差异极大。ARP 是纯二层协议，永远不经过 lo 接口，只出现在物理网卡；而curl http://127.0.0.1:8080的 HTTP 流量默认走 lo，根本不会触发网卡驱动的收发逻辑；DNS 查询若配置了127.0.0.1作为上游（如 dnsmasq 或 systemd-resolved），其 UDP 报文也仅在 lo 上流转。因此，一份合格的实验报告必须明确标注捕获接口。常见误操作是全程只选any，导致 ARP 包被混在大量 lo 流量中难以定位。
提示：Linux 下用
ip link show查看可用接口名；macOS 用ifconfig | grep "^[a-z]"；Windows 在 Wireshark 接口列表中认准Ethernet或Wi-Fi，避免选Npcap Loopback Adapter（它虽能捕获部分本地流量，但对 ARP 无效）。
2.2 四类协议的最小触发命令与对应 Wireshark 显示过滤器
以下命令均在终端执行，要求环境干净（无其他后台服务干扰 DNS/HTTP）：
# 1. 触发 ARP：清空缓存后 ping 同一子网内未通信过的 IP（如网关） sudo ip neigh flush all ping -c 1 192.168.1.1 # 2. 触发 ICMP：发送带自定义 TTL 的 Echo 请求（便于观察中间设备响应） ping -c 1 -t 2 8.8.8.8 # 3. 触发 DNS：强制使用 TCP 查询（绕过 UDP 截断重试干扰，清晰看到完整报文） dig @114.114.114.114 www.baidu.com A +tcp # 4. 触发 HTTP：禁用连接复用，确保每次请求新建 TCP 连接（避免 HTTP/1.1 keep-alive 混淆时序） curl -H "Connection: close" http://httpbin.org/get对应 Wireshark 显示过滤器（Display Filter）必须精确到协议字段，而非简单关键词：
| 协议 | 推荐过滤表达式 | 关键说明 |
|---|---|---|
| ARP | arp.opcode == 1 or arp.opcode == 2 | opcode == 1是请求（who-has），== 2是响应（is-at）；避免用arp，它会匹配所有含 ARP 字段的帧（包括 gratuitous ARP） |
| ICMP | icmp.type == 8 or icmp.type == 0 | type == 8是 Echo Request，== 0是 Echo Reply；注意icmp.code在 type=3（Destination Unreachable）时才有意义 |
| DNS | dns && udp.port == 53 | 必须限定udp.port == 53，否则会混入 DNS-over-HTTPS (DoH) 的 TLS 流量；TCP DNS 需改为tcp.port == 53 |
| HTTP | `http.request.method == "GET" |
2.3 捕获前必设的三个核心参数（影响后续分析深度）
Wireshark 默认设置会丢失关键信息。实验报告中需记录以下三项修改：
- Capture Options → Capture Filter：输入
host 192.168.1.100 and port 53（将192.168.1.100替换为本机 IP）。这在内核层过滤，大幅降低 CPU 占用，避免海量无关包淹没目标流量。 - Edit → Preferences → Protocols → IPv4 → Enable “Validate checksum if possible”：勾选此项。当抓到校验和错误的 ICMP 包（如 TTL=1 时路由器返回的 ICMP Time Exceeded），Wireshark 会标红并注明
Bad checksum，这是判断路径中设备行为的关键线索。 - View → Time Display Format → Seconds Since Beginning of Capture：切换为相对时间。ARP 请求与响应之间通常间隔 < 1ms，HTTP 建连与首字节延迟常在 10–100ms 级别，绝对时间戳（如
Jan 1 00:00:00）无法体现这种微秒级时序关系。
3. 解析 ARP/ICMP/DNS/HTTP 报文的四个必查字段与典型异常模式
3.1 ARP 报文：从arp.src.proto_ipv4和arp.dst.hw_mac看地址解析全过程
ARP 报文结构极简，但字段含义直指网络层本质。在 Wireshark 中展开Address Resolution Protocol层，重点检查：
Hardware type: 必须为1（以太网），若为6（IEEE 802）则说明抓包点位于特殊网络设备（如某些虚拟交换机）。Protocol type: 必须为0x0800（IPv4），若为0x86dd（IPv6）则属于 NDP 协议，不应归入 ARP 分析。Sender MAC address（arp.src.hw_mac）：发出 ARP 请求的设备 MAC。若此值为全00:00:00:00:00:00，说明是gratuitous ARP（免费 ARP），常用于 IP 冲突检测或高可用 VIP 切换。Sender IP address（arp.src.proto_ipv4）：请求方声称的 IP。若该 IP 与本机 IP 不同，且Target IP address（arp.dst.proto_ipv4）却是本机 IP，则表明有设备在进行ARP 欺骗扫描（如arpscan工具行为）。
注意：
arp -a命令输出的缓存表，其Type列为dynamic表示由 ARP 响应自动学习，static表示手动添加（如arp -s 192.168.1.1 00-11-22-33-44-55）。实验中若ping后arp -a无新增条目，大概率是目标主机已关闭 ICMP 响应或防火墙丢弃了 ARP 请求。
3.2 ICMP 报文：用icmp.type和icmp.code定位网络路径中断点
ICMP 并非“只是 ping”，它是 IPv4 的故障反馈信使。icmp.type和icmp.code组合定义了具体错误类型。例如：
type == 3（Destination Unreachable）时，code值决定原因：code == 0：Network Unreachable（路由表无匹配项）code == 1：Host Unreachable（路由可达，但目标主机无响应，如关机）code == 3：Port Unreachable（UDP 目标端口无进程监听，常用于nmap -sU扫描）
type == 11（Time Exceeded）时，code == 0表示 TTL=0，code == 1表示分片重组超时（极少出现）。
实际案例：执行traceroute -n 8.8.8.8时，Wireshark 中会看到连续的icmp.type == 11 and icmp.code == 0报文，其IP Header → Time to live字段值从 1 递增至最终跳数。若某跳返回type == 3, code == 1，说明该路由器能到达目标网络，但目标主机本身不可达。
3.3 DNS 报文：从dns.flags.response和dns.qry.name识别查询-响应配对
DNS 查询（Query）与响应（Response）通过dns.id字段关联，但更可靠的判断依据是dns.flags.response标志位：
dns.flags.response == 0：查询报文（Query），此时dns.qry.name显示请求的域名（如www.baidu.com），dns.qry.type为1（A 记录）或28（AAAA）。dns.flags.response == 1：响应报文（Response），此时dns.flags.rcode决定结果：rcode == 0：NoError（正常响应）rcode == 3：NXDomain（域名不存在）rcode == 2：ServerFailure（权威服务器内部错误）
关键技巧：在 Wireshark 中右键点击任意 DNS 查询报文 →Follow → UDP Stream，可完整查看一次查询-响应的原始字节流，验证dns.id是否一致、响应是否包含Answers段（dns.count.answers > 0）。
3.4 HTTP 报文：用http.content_length和http.connection验证连接复用行为
HTTP/1.1 默认启用持久连接（Keep-Alive），但客户端/服务端可主动关闭。判断连接是否复用，不能只看 TCP 端口号，而要看 HTTP 层字段：
http.connection == "keep-alive"：客户端声明希望复用连接（HTTP/1.1 默认，可省略）。http.connection == "close"：任一方声明本次请求后关闭连接（如curl -H "Connection: close"）。http.content_length：响应体长度。若为0，可能是 HEAD 请求或 304 Not Modified；若为正整数，需与 TCP 层tcp.len对比——若tcp.len大于content_length + HTTP header length，说明该 TCP 段还携带了下一个 HTTP 请求（即复用连接下的管道化，pipelining，现代浏览器已弃用）。
提示：在 Wireshark 中，HTTP 请求与响应自动按
tcp.stream分组。右键tcp.stream eq 5→Apply as Filter，即可聚焦单次 TCP 连接内的全部 HTTP 交互，直观看到Connection: close后 TCP FIN 包的出现时机。
4. 在 GNS3 中构建双路由器拓扑并分析 ARP/IP 转发的三步验证法
4.1 拓扑设计与设备角色定义（避免常见配置陷阱）
GNS3 中两个路由器（R1、R2）分别连接一台主机（PC1、PC2），典型拓扑为：PC1 — R1 — R2 — PC2，其中 R1 与 R2 间用串口（Serial）或千兆以太（GigabitEthernet）互联。关键配置点：
- PC1 与 PC2 的网关必须指向直连路由器的接口 IP：
PC1 的网关 = R1 的f0/0IP（如192.168.10.1）；
PC2 的网关 = R2 的f0/0IP（如192.168.20.1）。 - R1 与 R2 必须启用 IP 转发：Cisco IOS 中执行
ip routing（默认开启）；若用 Linux 路由器镜像，需echo 1 > /proc/sys/net/ipv4/ip_forward。 - R1 与 R2 间必须配置静态路由或动态路由协议：
R1 上：ip route 192.168.20.0 255.255.255.0 10.0.0.2（10.0.0.2是 R2 互联接口 IP）；
R2 上：ip route 192.168.10.0 255.255.255.0 10.0.0.1。
注意：若
ping PC2从 PC1 失败，先在 R1 上show ip route确认是否有192.168.20.0/24路由；再在 R1 上ping 10.0.0.2测试直连链路；最后在 R1 上debug ip icmp查看是否收到 PC2 的 ICMP Echo Reply 却无法转发回 PC1（此时检查 R2 的反向路由）。
4.2 在 R1 的 f0/0 接口捕获：分离三层转发与二层 ARP 的时序
在 R1 的f0/0接口（连接 PC1）启动 Wireshark，执行PC1 ping PC2。此时捕获到的报文流严格遵循以下顺序：
- PC1 发送 ARP 请求：
who-has 192.168.10.1（R1 的 f0/0 IP），目标 MACff:ff:ff:ff:ff:ff。 - R1 发送 ARP 响应：
is-at 00:00:00:00:00:01（R1 的 f0/0 MAC）。 - PC1 发送 ICMP Echo Request：源 IP
192.168.10.10，目的 IP192.168.20.10，源 MACPC1_MAC，目的 MACR1_f0/0_MAC。 - R1 转发 ICMP：R1 查路由表，决定下一跳为
10.0.0.2（R2），于是：- 修改 IP 层 TTL 减 1；
- 在数据链路层，将源 MAC 改为
R1_s0/0_MAC，目的 MAC 改为R2_s0/0_MAC（需 R1 先对10.0.0.2发起 ARP）； - 将整个 IP 包封装进新的以太帧，从
s0/0接口发出。
关键验证点：在步骤 4 的转发帧中，Wireshark 的Ethernet II → Destination字段必须是 R2 的串口 MAC（非 R1 自身 MAC），且IP → Source仍为192.168.10.10（源 IP 不变），IP → Destination仍为192.168.20.10（目的 IP 不变）——这证明是纯粹的三层转发，而非 NAT。
4.3 使用tshark命令行批量提取关键字段生成实验报告表格
Wireshark GUI 适合交互分析，但实验报告需结构化数据。在 GNS3 虚拟机或宿主机上，用tshark导出 CSV：
# 从捕获文件中提取 ARP 请求/响应的时间、源IP、目的IP、MAC tshark -r capture.pcapng \ -Y "arp" \ -T fields \ -e frame.time_epoch \ -e arp.src.proto_ipv4 \ -e arp.dst.proto_ipv4 \ -e arp.src.hw_mac \ -e arp.dst.hw_mac \ -e arp.opcode \ -E header=y \ -E separator=, \ > arp_analysis.csv # 提取 DNS 查询的域名、类型、响应码 tshark -r capture.pcapng \ -Y "dns && dns.flags.response == 0" \ -T fields \ -e dns.qry.name \ -e dns.qry.type \ -e frame.time_relative \ -E header=y \ -E separator=, \ > dns_query.csvtshark输出的 CSV 可直接粘贴至 Excel，用数据透视表统计：
- 每个域名的平均 DNS 解析耗时（
frame.time_relative最大值减最小值）； arp.opcode == 1与== 2的数量比（理想应为 1:1，若请求远多于响应，说明存在 ARP 请求超时）；- HTTP 响应中
http.response.code == 200与== 502的占比（502 Bad Gateway通常意味着上游服务（如反向代理）无法连接到真实后端）。
5. 针对 DNS 和 HTTP 的进阶排错：从resolv.conf修改失效到502 Bad Gateway根因定位
5.1 Linux 修改/etc/resolv.conf后未生效？三步定位真实 DNS 解析器
/etc/resolv.conf是用户可见的 DNS 配置入口，但现代 Linux 发行版（Ubuntu 18.04+, CentOS 8+）普遍由systemd-resolved或NetworkManager动态管理，直接编辑会被覆盖。验证真实生效的 DNS 服务器：
- 查
systemd-resolved状态：systemctl is-active systemd-resolved # 应为 active resolvectl status | grep "DNS Servers" # 显示当前使用的 DNS - 查
NetworkManager配置：nmcli dev show | grep DNS # 若显示 `DNS configuration: none`，说明未通过 NM 配置 - 绕过本地 resolver，直连上游 DNS 测试：
若直连成功，但dig @114.114.114.114 www.qq.com +short # 强制使用 114.114.114.114 dig @8.8.8.8 www.qq.com +short # 强制使用 8.8.8.8dig www.qq.com失败，则问题在本地 resolver（systemd-resolved或dnsmasq）；若直连也失败，则是网络层问题（防火墙拦截 UDP 53 端口、上游 DNS 服务器宕机）。
提示：
systemd-resolved的日志在journalctl -u systemd-resolved -f中实时查看，搜索query关键词可看到每次解析请求及响应。
5.2502 Bad Gateway错误的四层归因与 Wireshark 验证路径
502 Bad Gateway是 HTTP 状态码，表示网关（如 Nginx、HAProxy）作为代理，无法从上游服务器（upstream）获得有效响应。根因必在 TCP 层或应用层，Wireshark 可精准定位：
| 可能原因 | Wireshark 中的证据 | 验证命令 |
|---|---|---|
| 上游服务未监听 | 网关向 upstream IP:Port 发送 SYN，无 SYN-ACK 返回 | telnet upstream_ip 8080或nc -zv upstream_ip 8080 |
| 上游服务拒绝连接 | 网关发送 SYN，收到 RST（Reset） | 在 Wireshark 中过滤tcp.flags.reset == 1 and ip.addr == upstream_ip |
| 上游服务响应超时 | 网关发送 HTTP 请求后，长时间（如 60s）无 HTTP 响应，最终发送HTTP/1.1 502给客户端 | 过滤http.host contains "your-domain" and http.response.code == 502，查看其前一个 TCP 流的持续时间 |
| 上游服务返回非 HTTP 响应 | 网关收到上游 TCP 数据，但内容不符合 HTTP 协议（如返回纯文本、二进制乱码） | tshark -r capture.pcapng -Y "ip.addr == upstream_ip && tcp.len > 0" -T fields -e data.text |
实际案例：某服务部署后出现502 Bad Gateway: unknown error, url: http://127.0.0.1:1572。用tshark抓取 Nginx 与127.0.0.1:1572的通信，发现 Nginx 发送GET /health HTTP/1.0后，收到的响应是HTTP/1.1 200 OK，但响应体为空（Content-Length: 0），且 TCP 连接立即关闭。进一步检查上游服务日志，确认其健康检查接口未正确实现，导致 Nginx 认为服务异常而返回 502。
5.3 HTTP 连接复用失效的两个隐蔽信号与修复方法
HTTP/1.1 Keep-Alive 失效会导致连接频繁重建，增加延迟。Wireshark 中的两个关键信号：
- 信号 1：连续 HTTP 请求间 TCP 握手重复出现
过滤tcp.flags.syn == 1 and tcp.flags.ack == 1，若在同一个客户端-服务端 IP 对之间，多次出现 SYN-ACK-SYN-ACK（即三次握手重复），说明连接未复用。 - 信号 2：HTTP 响应头缺失
Connection: keep-alive且Keep-Alive字段
正常复用响应应含Connection: keep-alive和Keep-Alive: timeout=5, max=100。若缺失，服务端可能配置了keepalive_timeout 0;（Nginx）或MaxKeepAliveRequests 1（Apache）。
修复方法：
- Nginx 配置中确保
keepalive_timeout 65;（单位秒）且keepalive_requests 100;； - 应用代码中（如 Python Flask）避免在响应头中手动设置
Connection: close； - 客户端（如 curl）显式启用：
curl --http1.1 --header "Connection: keep-alive" http://example.com。
本文还有配套的精品资源，点击获取
