简介本资源是一份面向计算机网络专业本科生及初学者的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查到缓存条目却无法对应到抓包窗口里某次广播的源 MACDNS 查询在命令行能解析成功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必须精确到协议字段而非简单关键词协议推荐过滤表达式关键说明ARParp.opcode 1 or arp.opcode 2opcode 1是请求who-has 2是响应is-at避免用arp它会匹配所有含 ARP 字段的帧包括 gratuitous ARPICMPicmp.type 8 or icmp.type 0type 8是 Echo Request 0是 Echo Reply注意icmp.code在 type3Destination Unreachable时才有意义DNSdns udp.port 53必须限定udp.port 53否则会混入 DNS-over-HTTPS (DoH) 的 TLS 流量TCP DNS 需改为tcp.port 53HTTPhttp.request.method GET2.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 包如 TTL1 时路由器返回的 ICMP Time ExceededWireshark 会标红并注明Bad checksum这是判断路径中设备行为的关键线索。View → Time Display Format → Seconds Since Beginning of Capture切换为相对时间。ARP 请求与响应之间通常间隔 1msHTTP 建连与首字节延迟常在 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以太网若为6IEEE 802则说明抓包点位于特殊网络设备如某些虚拟交换机。Protocol type: 必须为0x0800IPv4若为0x86ddIPv6则属于 NDP 协议不应归入 ARP 分析。Sender MAC addressarp.src.hw_mac发出 ARP 请求的设备 MAC。若此值为全00:00:00:00:00:00说明是gratuitous ARP免费 ARP常用于 IP 冲突检测或高可用 VIP 切换。Sender IP addressarp.src.proto_ipv4请求方声称的 IP。若该 IP 与本机 IP 不同且Target IP addressarp.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 3Destination Unreachable时code值决定原因code 0Network Unreachable路由表无匹配项code 1Host Unreachable路由可达但目标主机无响应如关机code 3Port UnreachableUDP 目标端口无进程监听常用于nmap -sU扫描type 11Time Exceeded时code 0表示 TTL0code 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.comdns.qry.type为1A 记录或28AAAA。dns.flags.response 1响应报文Response此时dns.flags.rcode决定结果rcode 0NoError正常响应rcode 3NXDomain域名不存在rcode 2ServerFailure权威服务器内部错误关键技巧在 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 的网关必须指向直连路由器的接口 IPPC1 的网关 R1 的f0/0IP如192.168.10.1PC2 的网关 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.210.0.0.2是 R2 互联接口 IPR2 上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.1R1 的 f0/0 IP目标 MACff:ff:ff:ff:ff:ff。R1 发送 ARP 响应is-at 00:00:00:00:00:01R1 的 f0/0 MAC。PC1 发送 ICMP Echo Request源 IP192.168.10.10目的 IP192.168.20.10源 MACPC1_MAC目的 MACR1_f0/0_MAC。R1 转发 ICMPR1 查路由表决定下一跳为10.0.0.2R2于是修改 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 headery \ -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 headery \ -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.8若直连成功但dig www.qq.com失败则问题在本地 resolversystemd-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收到 RSTReset在 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即三次握手重复说明连接未复用。信号 2HTTP 响应头缺失Connection: keep-alive且Keep-Alive字段正常复用响应应含Connection: keep-alive和Keep-Alive: timeout5, max100。若缺失服务端可能配置了keepalive_timeout 0;Nginx或MaxKeepAliveRequests 1Apache。修复方法Nginx 配置中确保keepalive_timeout 65;单位秒且keepalive_requests 100;应用代码中如 Python Flask避免在响应头中手动设置Connection: close客户端如 curl显式启用curl --http1.1 --header Connection: keep-alive http://example.com。本文还有配套的精品资源点击获取