简介计算机网络实验报告聚焦使用Wireshark/Ethereal捕捉与分析协议数据包。实验覆盖以太网帧、IP数据报、TCP段格式验证以及ARP、ICMPping/tracert、TCP三次握手、FTP工作过程、WWW应用报文等典型协议交互适合高校计算机网络课程实验参考也适合初学者通过抓包理解协议字段与流程。资源包内含1个docx文档大小约7.17MB完整呈现实验目的、环境、过程记录及思考题问答包含关键报文截图与参数解释如IPv4首部长度、ARP封装位置、ICMP序列号含义、三次握手seq/ACK变化等。已有352人学习可用于课程报告撰写或期末复习。文档还针对常见WWW问题给出了基于HTTP/1.0和HTTP/1.1的TCP连接次数差异分析可直接校正思路。1. 用协议分析器把网络课本“跑”一遍从 ARP 到 HTTP 的抓包实操刚开始学计算机网络最容易陷入“背了 TCP 三次握手、画了 OSI 七层模型但 wireshark 里看到真实流量一脸懵”的状态。这份实验报告的思路恰好相反——在 macOS ARM 环境里安装 Wireshark用浏览器、curl、ping、tracert 制造真实流量再把数据帧、IP 数据报、TCP 数据段从头到尾拆开看。它解决的核心问题不是“协议长什么样”而是“协议在真实链路上怎么被封装、怎么协作”。适合正在做计算机网络课程设计的学生也适合想补抓包分析基本功的运维和开发。真实抓包数据比任何教科书都诚实看完你就知道HTTP 下面垫了多少层东西。2. 抓包工具选型与实验环境的流量预配置实验原文写的软件是 Ethereal但 2024 年还在用 Ethereal 的机器几乎绝迹——Wireshark 是它的继任者抓包引擎和显示过滤器一脉相承。这里我一般直接装 Wireshark版本选 LTS 或者当前稳定版即可协议解析能力对教学实验完全够用。在 MacARM 架构上安装 Wireshark 有两种常见做法官方安装包.dmg或 Homebrew。既然实验环境是 Apple Silicon我更推荐用 Homebrew 装因为安装包会自动带上 ChmodBPF 来配置抓包权限省去手动授权这一道工序brew install --cask wireshark装完后启动 Wireshark抓包列表里选en0Wi-Fi或eth0有线。如果你用的是带图形界面的 Linux 或 Windows选接口的逻辑同理——选“有流量”的那个物理网卡别选lo0回环接口除非你刻意要抓本机进程间的通信。实验环境里还涉及一个关键操作清空 ARP 缓存。macOS 下命令与 Windows 略有差异但实验报告里用的是 Windows 命令提示符的写法arp -d -a在 Windows 上arp -d删除指定条目-a表意是显示缓存组合起来的实际效果是清空全部 ARP 表项。macOS 下这条命令会被提示权限不足需要换成sudo arp -d -a或者用sudo ifconfig en0 -arp临时关闭接口的 ARP 协议用完要再开回来。这个步骤的意义在于下一次访问局域网内任意 IP 时网卡必须重新发起 ARP 请求你才有机会抓到“首次解析”的完整交互过程。环境准备好后先别着急点“开始抓包”。我一般会先验证一下 Wireshark 是否真的能捕获流量而不只是显示乱码数据。测试方法很简单开抓包后随便 ping 一下网关 IP然后看捕获列表里有没有出现 ICMP 报文。出现即正常。如果抓包列表里全是TCP Previous segment lost之类的异常提示十有八九是你在 Wi-Fi 接口上抓包且 AP 开了 802.11 帧聚合导致 Wireshark 看到的是重组后的帧。实验场景下不用纠结教学验证不依赖这些细节。对于协议分析器的使用套路实验报告后面所有的操作都可以汇总成三个固定动作先制造流量、再停止抓包、最后用显示过滤器定位目标协议。过滤语法是整个实验最核心的操作技能我把实验里会用到的几条常用过滤器开头列出来后面每一章都会用到它们。3. ARP 与 ICMP 报文分析与参数逐条解读3.1 ARP 请求/应答的链路层封装细节做完第 2 章的清缓存操作后抓包窗口切到en0然后浏览器访问任意内网或外网地址Wireshark 里就能看到成对的 ARP 请求与应答。用显示过滤器过滤arp这样就能把混杂的 HTTP、DNS 流量全部滤掉只保留 ARP 报文。实验中抓到的 ARP 报文是从本机发给网关的找到后展开报文结构核心字段对比如下。报文字段请求报文中的值应答报文中的值说明硬件类型0x00010x00011 表示以太网协议类型0x08000x08000x0800 表示 IPv4硬件地址长度66MAC 地址长度协议地址长度44IPv4 地址长度操作码0x00010x00021 为请求2 为应答发送方 MAC本机 MAC网关 MAC应答时发送方是网关发送方 IP本机 IP网关 IP应答时发送方是网关目标 MAC全 0本机 MAC请求时目标 MAC 未知故置空实验报告里特别提到“ARP 报文被封装在以太网帧的头部中传输”这句话值得展开一下。ARP 报文不是走 IP 协议栈的——它在数据链路层直接被填充进以太网帧的载荷部分以太网帧头部的类型字段值为0x0806用来告诉接收方“这个帧里面装的是 ARP 报文不是 IP 包”。这也是为什么你再怎么清缓存、再怎么抓包ARP 报文里都看不到 IP 头和 TCP/UDP 头的根本原因ARP 压根不经过网络层。参数细节上硬件类型和协议类型是 Wireshark 识别的依据硬件地址长度和协议地址长度则定义了 ARP 报文变长部分的大小在以太网 IPv4 的组合中恒为 6 和 4但换成 IPv6 或 802.11 帧时这两个字段会变。测试中如果看到应答报文的“目标 MAC”字段不是本机地址而是全 0说明该报文不是发给你而是广播应答这时应该检查过滤器里有没有绑定点到点的条件。关于这个实验的排错最常见的坑是清了 ARP 缓存之后还没开抓包就去访问网页了结果 ARP 解析早就完成等切到 Wireshark 界面时只看到后续的 TCP 流量。我一般会先在过滤器栏输好arp再点开始确保不错过前几个报文。3.2 ping 命令的 ICMP Echo 报文格式拆解实验中的第二步操作用 ping 制造 ICMP 流量。ping 一个远端地址ping -c 4 www.gzhu.edu.cn-c 4表示只发 4 个 ICMP Echo 请求和实验报告里“每个报文发三次”的记录略有差异——那是 Windows 下 ping 的默认行为macOS 和 Linux 中 ping 默认是无限次发送需要用-c限流。经过该参数限制后的抓包窗口里过滤器直接输入icmp显示出来的报文成对出现Echo (ping) request和Echo (ping) reply。展开每个报文重点看三个参数。首先是Sequence number序列号它标记每个 Echo 请求的序号。如果发现请求的序号不连续中间隔了数字说明有发出的包没有收到应答即丢包如果收到重复请求说明网络中存在环路或重放。其次是Checksum校验和它由 ICMP 报文的内容计算得出。Wireshark 在报文详情里如果显示[correct]说明校验和验证通过如果显示[invalid]则说明传输过程中报文内容被改变可能是链路故障、硬件故障或者存在中间设备恶意改动。第三个是Response time表示从发出请求到收到应答的往返耗时。这个值是计算 RTT 的原始依据也是判断链路质量的直接指标。实验报告里这个值没有贴出来但实际操作里如果看到连续几个包的 Response time 都超过 100ms且目标地址是本省教育网节点那十有八九是跨网访问了交换路由绕了远路。实验里有个细节值得注意ping 的载荷长度。默认ping发 64 字节其中 ICMP 头部占 8 字节数据部分 32 字节。如果实验中用ping -l 1400 baidu.com这类大小来测 MTU你会看到 ICMP 报文被分片成两个 IP 数据报链路层的封装随之出现偏移——这个现象在实验报告里没提但对理解帧的封装序列很有帮助。3.3 tracert 探测路径的 ICMP 超时报告机制tracert 的实验逻辑和 ping 完全不同ping 是“目的主机回应你”tracert 是“沿途每一台路由器都回应你”。实验报告里说“每经过一个路由器便会在该数据报的选项字段中增加该路由器的地址信息”——严格来说这个描述不太准确tracert 的常见实现是发送 TTL 递增的探测包每一跳的路由器把 TTL 减到 0 后回送一个 ICMP Time Exceeded 报文源主机借此得知该跳路由器的 IP。用 Wireshark 抓的时候过滤器写成icmp.type 11 || icmp.type 8 || icmp.type 0其中type 11是 Time Exceededtype 8是 Echo Requesttype 0是 Echo Reply。这样能把整条路径上的三类 ICMP 报文全部拉出来。实验报告里有一个结论跟踪到的路由器“接口为 137”。这里需要解释一下tracert 显示的是路径上路由器的入口接口 IP即靠近源主机的那一侧不是出口。原因是 ICMP Time Exceeded 报文由路由器收到探测包后立即生成源地址取自收到探测包的接口——也就是“数据进到这个路由器时用的那个 IP”。如果哪天做网络排障时发现 tracert 第一跳不是网关而是内网另一台设备不用慌那多半是网关做了 NAT/策略路由把入口 IP 包装掉了。4. TCP 三次握手与 FTP 工作流程的报文级验证4.1 用 curl 构造流量并过滤握手序列实验报告里用 curl 获取 www.baidu.com 的源码来制造 HTTP 流量这个操作对应的命令是curl -v http://www.baidu.com -o /dev/null-v参数让 curl 输出详细连接信息-o /dev/null丢弃响应内容避免终端刷屏。在 Wireshark 里理论上应该能看到本机向百度 IP 发起 TCP 连接。但这里有个坑curl 解析域名走 DNS拿到 IP 后直接连接的是百度某个 CDN 节点的 IP你不会在抓包里看到“baidu.com”字样看到的只是TCP报文里的目标 IP这一点报告里也印证了目标地址是203.107.62.254。过滤器用tcp.flags.syn 1这条命令的含义是只看 SYN 标志位为 1 的 TCP 报文。三次握手的三个报文依次为客户端发SYNseq0服务端回SYNACKseq0, ack1客户端再发ACKseq1, ack1。在 Wireshark 里展开每个报文对照下面三张表就能验证握手的正确性。第一次握手报文的关键字段如下表。字段值说明Source Port随机高位端口客户端临时端口Destination Port80目标服务端口Sequence Number0 (相对值)客户端初始序列号SYN Flag1同步标志ACK Flag0确认标志未启用第二次握手SYNACK的关键字段如下表。字段值说明Source Port80服务端端口Destination Port客户端临时端口回应客户端Sequence Number0 (相对值)服务端初始序列号Acknowledgment Number1等于客户端 seq 1SYN Flag1同步标志ACK Flag1确认标志第三次握手ACK的关键字段如下表。字段值说明Source Port客户端临时端口同第一次Destination Port80同第一次Sequence Number1 (相对值)等于服务端 seq 1Acknowledgment Number1等于服务端 seq 1ACK Flag1确认标志Win10 以上系统的抓包里你还会额外看到 TCP 选项里的Timestamps字段——这是 RFC 7323 的扩展不是标准三次握手必需内容但报告里没提这层细节所以这里只是补充说明不影响验证逻辑。curl -v的输出里* Connected to www.baidu.com (xxx.xxx.xxx.xxx) port 80这行字就是你抓包里三次握手完成的那一刻。如果 curl 卡在Trying xxx.xxx.xxx.xxx很久说明 TCP 的 SYN 发出后没有收到应答——这时候去 Wireshark 里看有没有对应 IP 的 SYN 重传比抓瞎调试有效得多。4.2 FTP 控制连接与数据连接的状态对照实验第 7 步要求“捕捉整个 FTP 工作工程”报告原文写了个“略”字但摘要里明确要求补全。FTP 抓包的难点在于它有两条连接控制连接TCP 21和数据连接TCP 20 或随机高位端口。FTP 主动模式PORT由服务端主动连回客户端被动模式PASV由客户端连服务端的随机端口。如果抓包时用的是被动模式数据连接的端口不是 20就不能用tcp.port 20过滤。FTP 全流程的六个阶段可以按下表对照验证。阶段动作典型报文方向ARP 解析解析服务器 MACARP 请求/应答广播 单播控制连接建立客户端连服务器 21 端口TCP 三次握手客户端 → 服务器身份验证USER PASSFTP 响应码230客户端 → 服务器数据连接建立PASV 或 PORTFTP 的 227/200 响应客户端 ↔ 服务器数据传输LIST/RETR/STORTCP 数据报文取决于方向连接释放QUIT 双向 FINTCP 四次挥手双向实际抓包时过滤器ftp || ftp-data可以把控制连接ftp和数据连接ftp-data同时选出来。其中控制连接走明文USER 和 PASS 命令直接可见——这正是 FTP 不安全的原因之一只推荐在实验环境用。数据连接里如果是 LIST 命令你会看到若干TCP Previous segment lost的提示不一定是真的丢包更可能是 PASV 模式下数据连接端口变了Wireshark 按前一端口跟踪 TCP 流时衔接不上导致的误报。FTP 四次挥手的过滤器可以用tcp.flags.fin 1用与三次握手同样的方式验证客户端发 FIN服务端 ACK服务端发 FIN客户端 ACK。注意控制连接关闭后数据连接通常也已经关闭。如果只看到控制连接关闭、数据连接还挂着多半是传输过程中存在未完成的被动数据连接这时可以继续等或者干脆关闭 FTP 客户端强制清理。5. HTTP/1.0 与 1.1 的 TCP 连接数和 RTT 计算边界实验最后的思考题涉及 HTTP 连接复用这块实际是网络课里最容易出错的点。题目原意是当点击一个包含一个本地 gif 和两个远地 gif 的文档时需要建立几次 TCP 连接。答案取决于 HTTP 版本HTTP/1.0 非持久连接每个对象HTML 文档 3 个 gif都单独建立一次连接总共 4 次 TCPHTTP/1.1 默认持久连接这 4 个对象可以在同一条连接上排队传输因此只需 1 次 TCP 连接。整个过程中没有任何 UDP 过程所以 UDP 连接数为 0。这个计算有两个边界值得补充。一是持久连接的上限HTTP/1.1 的持久连接可以串行传输多个对象但如果页面对象数量非常多比如几十张图片所有对象都堆在一条连接上就会变成队头阻塞因此部分浏览器实现会针对同一域名打开 6 条并行持久连接来加速。另一个是 TCP Fast OpenTFO等机制在握手阶段就携带了 HTTP 请求数据这种场景下 TCP 连接数和 HTTP 请求数并不是一一对应的。实验原文里“RTT0.14ms”这个值需要检查抓包里的时间字段才能验证。RTT 指的是数据包从源主机发出到收到确认的往返时间。实验中用 curl 获取 www.baidu.com 时从发起请求到收到完整页面总耗时约等于DNS 查询 RTT TCP 连接建立 1.5 RTT三次握手需 1 个完整 RTT 加 SYN 到达的半个 RTT HTTP 请求/响应 1 个 RTT。如果页面包含多个对象在 HTTP/1.0 非持久连接下每个对象都要重复“建立连接 请求响应”的 2 个 RTT页面越多耗时越长。Wireshark 自带的Statistics → Flow Graph功能选择 TCP 流可以把每个请求对应的建立连接时间、响应耗时全部可视化比手动数报文时间更直观。另外一个比较隐蔽的问题实验里按http://www.gzhu.edu.cn/index.jsp和http://www.gzhu.edu.cn/cn/research/index.jsp问“能否在同一个持久连接上发送”。答案是能但前提是这两次请求发生在同一条 TCP 连接的生命周期内并且在 HTTP/1.1 下默认的 Keep-Alive 超时时间内没有断开。验证方法是看 Wireshark 里这两个请求的 TCP 流编号是否为同一个看Stream index字段。如果是同一个说明浏览器复用连接成功如果流编号不同说明 Keep-Alive 超时或服务器主动关了连接浏览器只能重建 TCP 连接。最后留一个可操作的验证建议打开浏览器的开发者工具按 F12切到 Network 面板勾选“Disable cache”重新加载一个包含多个资源的页面观察浏览器实际发起的 TCP 连接次数和理论值对比。你会发现现代浏览器对同一域名的连接数管理远比课本模型复杂多域名拆分、HTTP/2 多路复用都会让“连接数”变成一个动态值。实验报告里基于 HTTP/1.0 和 1.1 的对比结论仍然成立但真实浏览器环境下的连接数变量更多值得在报告中注明以免形成机械化记忆。本文还有配套的精品资源点击获取