简介这是一份计算机网络抓包实验报告面向计算机专业学生、网络初学者以及正在准备实验课程的学习者用于通过Wireshark等工具掌握常见网络协议的运行机制。资源共包含1个doc文档压缩包大小2.36MB内容完整既有实验目的与要求也有步骤和结果分析。实验内容覆盖数据链路层、网络层、传输层和应用层从以太网帧的源/目的MAC地址、IP报文的地址与协议类型到TCP/UDP端口、序列号和标志字段均有解析同时针对HTTP、FTP、DNS、SMTP、POP3等典型应用层协议展示了抓包结果和关键字段含义并对TCP三次握手与四次挥手、ARP与ICMP报文结构进行了细致分析还涉及ipconfig、ping、tracert等常用网络命令的使用。报告配有抓包截图和包结构图方便读者对照理解可以直接用于实验报告参考、期末复习或自学网络协议分析。目前已有208人学习内容翔实适合需要快速上手的初学者及希望强化协议理解的学习者。1. 从抓包实验反推协议栈为什么计算机网络课一定要动手截几个包单纯看谢希仁或自顶向下教材TCP 三次握手的 SYN、ACK 标志位永远是纸面上的方块图只有当你在 Wireshark 里亲眼看到第 1 帧 SYN 序号为 0、第 2 帧 SYNACK 确认号为 1、第 3 帧 ACK 再确认时才会真正理解“序号 确认号”这对机制是干什么用的。这份抓包实验的核心价值就是把教材里分层的抽象概念映射到真实报文上帧头里的 MAC 地址、IP 头里的协议号、TCP 头里的端口号与标志位每一层都有明确的字节归属而 Wireshark 的解码窗口恰好能把它们逐层拆开。适合正在上计算机网络课、准备期末复习或考研的学生也适合需要快速回顾协议字段的工程师——抓包是验证“我以为我懂了”的最快方式。2. 捕获过滤器与显示过滤器的区别先想清楚要抓什么再点开始2.1 两种过滤器的本质差异Wireshark 里最容易混淆的就是 Capture Filter 和 Display Filter。实验步骤里那句“在 Capture filter 中输入 tcp单击 start”用的是捕获过滤器——它在数据包进入 Wireshark 内存之前就做丢弃语法是 libpcap 格式不支持字段名比如tcp port 80而不是tcp.port 80。而显示过滤器作用于已经捕获的报文集合语法基于协议字段交互式输入时有自动补全比如http、tcp.flags.syn 1、ip.addr 192.168.1.1。这两个东西不能混用。捕获过滤器写ip.addr 192.168.1.1会直接报错因为 libpcap 不认识这种带点号的字段反过来显示过滤器写成tcp port 80也不会生效。实际做实验时我一般把捕获过滤器设为“尽量宽”比如只抓tcp或udp保留完整流量然后用显示过滤器缩小范围。原因是捕获过滤器的丢弃是不可逆的如果一开始就把范围收窄后面想分析三次握手或重传可能就没有数据了。2.2 本实验最常用的显示过滤器做这份实验报告时以下过滤器基本够用。每一条都对应实验要求里的一个具体场景。实验需求显示过滤器说明分析 TCP 三次握手tcp.flags.syn 1或组合tcp.flags.syn 1 tcp.flags.ack 0只看纯 SYN 报文定位握手第一帧分析 HTTP 请求与响应http或 http.request抓取 SMTP 交互smtp过滤 25 端口上的 SMTP 会话抓取 POP3 邮箱登录pop注意协议名是 pop不是 pop3抓取 DNS 查询响应dns或udp.port 53观察 DNS 请求与应答的对应关系定位 FTP 控制连接ftp或ftp.request.commandFTP 控制连接走 21 端口数据连接走 20/动态端口只看某个主机的流量ip.addr 10.11.9.238不区分源/目的适合过滤实验机与服务器的通信注意ip.addr是“或”语义ip.addr 10.11.9.238等价于源地址或目的地址匹配即可。如果你想精确区分方向应该写ip.src 10.11.9.238或ip.dst 10.11.9.238。这是很多人在写过滤器时的常见误区结果把本不该出现的包也过滤进来了。2.3 实战先抓全量再逐步缩小推荐的操作流程是这样的。第一步选择要监听的网卡——如果机器上有虚拟网卡、蓝牙网卡等先在 Wireshark 主界面的网卡列表里确认哪个是实际联网的接口一般看“正在发送/接收的数据包”那列的跳动情况即可判断。第二步双击网卡开始捕获不做任何过滤。第三步在浏览器里访问一个 HTTP 页面或者执行ping、nslookup等命令产生目标流量。第四步停止捕获再在显示过滤器里输入http或tcp.port 80等条件。第五步右键某条报文选择 Follow - TCP Stream可以查看完整的会话内容。# 命令行抓包也遵循同样的思路先宽后窄 # 抓 eth0 上 80 端口的流量保存到文件 tcpdump -i eth0 -w http.pcap tcp port 80 # 事后用 tcpdump 读取文件并过滤查看 tcpdump -r http.pcap -n tcp.flags.syn 1上面第一条命令是捕获阶段-w http.pcap把原始报文写入文件第二条是分析阶段-r读取文件后再用 BPF 语法过滤。用命令行抓包时同样建议先宽后窄因为-w落盘的文件可以反复分析但被过滤掉的包就永远找不回来了。Wireshark 的捕获过滤器本质上也是把这种 BPF 语法翻译成底层可执行规则理解了这层关系就不会再把两种过滤器搞混。3. 逐层拆解一个 TCP 报文从帧头到 TCP 头的完整字段解读3.1 以太网帧分层思想的物理起点实验要求“任意捕获一个数据包分析其数据链路层格式”。Wireshark 解码窗口的最上层是 Frame 信息它对应物理层和链路层的接收信息包括帧号、帧长、到达时间、帧内封装的协议类型等。以原文里的第 346 号帧为例帧长为 54 字节捕获长度为 54 字节说明没有截断源 MAC 是e0:94:67:1b:c1:1a厂商前缀e0:94:67属于 Intel目的 MAC 是00:23:89:3b:24:72厂商前缀00:23:89属于 Hangzhou 某设备这个地址通常就是网关或路由器的 MAC。这里的 EtherType 是0x86dd代表上层封装的是 IPv6如果是 IPv4则 EtherType 为0x0800。以太网帧格式以第 346 号帧为例 目的 MAC 00:23:89:3b:24:72 6 字节 源 MAC e0:94:67:1b:c1:1a 6 字节 协议类型 0x86dd 2 字节IPv6 数据 IP 报文 46-1500 字节链路层的关键认知是以太网帧本身不关心 IP 地址它只负责在同一个广播域内传输靠 MAC 地址寻址。帧里的类型字段决定了上层是谁——0x0800是 IPv4、0x86dd是 IPv6、0x0806是 ARP。ipconfig /all里看到的“物理地址”就是这个 MAC 地址。3.2 IP 层寻址与分片网络层关注的是 IP 报头。IPv4 头最常用的是版本号、服务类型、总长度、标识符、TTL、协议号、源 IP、目的 IP 这几个字段。TTL 每经过一个路由器减 1减到 0 会被丢弃并回送 ICMP 超时报文这就是tracert命令的原理——通过发送 TTL 为 1、2、3 的探测包逐一拿到沿途路由器的地址。协议号字段决定上层是 TCP 还是 UDPTCP 是 6UDP 是 17ICMP 是 1。在 Wireshark 里看到 IP 头的 Protocol 列写着 6就说明后面跟着的是 TCP 报文。# Windows 下用 tracert 观察 TTL 逐跳递减 tracert -d www.sina.com.cn # -d 表示不解析主机名输出速度更快-d参数避免了对每个路由节点做反向 DNS 解析实验中能明显减少等待时间。如果跟踪到中途出现* * *可能是路由器不响应 ICMP 超时报文也可能是网络丢包这时候可以加-w 500把每跳的超时等待时间从默认的 1 秒缩短到 500 毫秒来加速探测。3.3 TCP 头端口、序号、标志位TCP 头是这份实验的核心关注点。比如一个访问www.sina.com.cn的请求包源端口是61146目的端口是80序号为 1确认序号为 1头部长度 20 字节标志字段为0x11。这里的0x11是十六进制表示二进制是00010001对应 FIN 和 ACK 两个标志位置 1说明这是一个带 FIN 的确认报文——也就是说应用层数据发送完毕后发送方在主动关闭连接。TCP 头的关键字段按顺序是源端口16 位、目的端口16 位、序号32 位、确认号32 位、数据偏移4 位以 4 字节为单位、保留6 位、标志位6 位URG/ACK/PSH/RST/SYN/FIN、窗口大小16 位、校验和16 位、紧急指针16 位、选项可变长。TCP 头部结构IPv4无选项时 20 字节 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | 源端口 | 目的端口 | -------------------------------- | 序号Sequence Number | -------------------------------- | 确认号Acknowledgment Number | -------------------------------- | 数据偏移 | 保留 |N|C|E|U|A|P|R|S|F| 窗口大小 | -------------------------------- | 校验和 | 紧急指针 | --------------------------------标志位里最常分析的是 ACK、SYN、FIN。SYN 表示“请求建立连接”FIN 表示“我要关闭连接”ACK 表示“我确认收到了你发的数据”。它们的组合能直接说明一次连接的状态SYN 单独出现是握手的第一个报文SYNACK 是第二个ACK 单独出现是第三个连接关闭时FINACK 和 ACK 的组合则能明确区分是谁主动发起的关闭。3.4 用 Wireshark 的专家信息辅助判断Wireshark 左下角的 Expert Information 可以按严重程度列出所有异常事件比如 TCP Retransmission重传、Duplicate ACK重复确认、Out-of-Order乱序等。实验报告里分析完正常报文之后顺手看一下这段会话里有没有重传或乱序是一种很有信息量的扩展分析。重传说明网络有拥塞或丢包乱序说明路径上有负载均衡或多路径转发。把这些现象和 TCP 的可靠性机制联系起来比单独截图一个正常报文更能体现对协议的理解程度。4. 三次握手与四次挥手从标志位和序号变化看懂连接生命周期4.1 握手的三个报文一个都不能少实验要求抓取 TCP 三次握手和四次挥手的包分析序列号和标志字段的变化规律。在 Wireshark 里可以通过右键 HTTP 报文选择 Follow TCP Stream把所有属于同一 TCP 连接的报文单独呈现这样就能直接看到连接建立和关闭的完整序列。以原文的抓包为例客户端源端口是 49961服务器目的端口是 80。第一次握手客户端发出 SYN 报文SYN 标志位置 1序号为 0。这个 0 是相对序号实际在 TCP 头里是一个随机初始化的 32 位数由于 Wireshark 启用了序列号相对化显示所以显示为 0。第二次握手服务器返回 SYNACK 报文SYN 和 ACK 都置 1服务器的初始序号也是 0确认号为 1——这个 1 就是“客户的序号 0 加 1”。第三次握手客户端发送 ACK 报文确认号为 1也就是服务器的初始序号加 1ACK 标志位置 1。至此连接建立成功。三次握手标志位和序号变化 方向 标志位 序号 确认号 C - S SYN 0 0 S - C SYN ACK 0 1 C - S ACK 1 1注意第三次握手的 ACK 报文可以携带数据HTTP 请求往往就跟着第三个握手报文一起发出这就是常见的“加速打开”现象——TCP 协议允许在 ACK 里捎带应用层数据不需要等第四个独立报文。4.2 挥手时 FIN 和 ACK 的交叉变化四次挥手对应的序列是客户端先发 FINACK服务器回 ACK服务器再发 FINACK客户端最后回 ACK。原文实验里提到的“前三个帧是三次握手后四个帧是四次挥手”这正是 Follow TCP Stream 视图下最典型的展示效果。第一次挥手时 FIN 标志置 1表示客户端不再发送数据第二次挥手是服务器对 FIN 的确认ACK 置 1第三次挥手是服务器主动发 FIN表示服务器也没有数据要发了第四次挥手是客户端对服务器 FIN 的确认。挥完手之后连接进入 TIME_WAIT 状态默认等待 2 个最大报文段生存时间MSL后才彻底关闭。# Windows 下查看 TCP 连接状态 netstat -ano | findstr :80 # 输出中可以看到 ESTABLISHED、TIME_WAIT、FIN_WAIT_2 等状态netstat -ano的-a显示所有连接和监听端口-n用数字形式显示地址和端口-o显示进程 PID。findstr :80是 Windows 下的文本过滤。对理解挥手过程很有帮助的是观察 TIME_WAIT 状态的数量级如果大量出现 TIME_WAIT说明服务器主动频繁关闭了连接如果是客户端频繁访问短连接服务TIME_WAIT 通常出现在客户端一侧而非服务器侧。4.3 用显示过滤器直接筛选握手报文如果不通过 Follow TCP Stream也可以直接用显示过滤器单独提取握手报文# 提取所有纯 SYN 报文排除 SYNACK tcp.flags.syn 1 tcp.flags.ack 0 # 提取所有 FIN 报文 tcp.flags.fin 1 # 提取同时带 SYN 和 ACK 的响应包 tcp.flags.syn 1 tcp.flags.ack 1注意一个容易误用的细节tcp.flags.syn 1并不会排除 SYNACK 报文因为 SYNACK 报文的 SYN 标志位也是 1。所以在筛选“第一次握手”时必须额外加上tcp.flags.ack 0。同理筛选 FIN 时也应明确是否为纯 FIN 或 FINACK。这也是很多实验报告里截图画了 SYN 包但没说明为什么这个包的 ACK 位也是 1 的原因——不是混淆而是没有意识到这类组合标志位本身就是常见的。另外Wireshark 的着色规则默认用浅绿色标记 SYN、用红色标记 RST、用深绿色标记 FIN 报文颜色可以帮助快速定位异常。如果看到一大片红色 RST 报文说明连接被强制重置了——常见原因包括端口未监听、防火墙拒绝、应用层协议错误。5. 从 HTTP、SMTP、FTP 到 DNS应用层协议的分析与验证技巧5.1 HTTP 的典型请求-响应形态HTTP 分析的关键在于找到请求包和响应包的对应关系。Wireshark 会在请求包的解码信息里显示[Response in frame: 723]在响应包里显示[Request in frame: 701]这种链接信息直接标注了同一事务的请求和响应分别在哪一帧。分析时值得关注的是请求行方法、URI、版本、请求头Host、User-Agent、Accept 等以及状态行HTTP 版本、状态码、状态描述再结合 TCP 层的序列号变化就能还原出一个 HTTP 请求从发出到收到响应所经历的数据传输过程。一个典型的 HTTP 请求包关键字段 GET / HTTP/1.1 Host: www.sina.com.cn User-Agent: Mozilla/5.0 Accept: text/html,application/xhtmlxml Connection: keep-alive响应包则看状态码200 表示成功302 表示重定向304 表示缓存未修改404 表示资源不存在500 表示服务器内部错误。实验里如果访问的页面比较复杂一次 HTTP 事务可能涉及多个请求和响应注意区分主文档请求和子资源请求。5.2 SMTP 与 POP3文本协议最直观SMTP 和 POP3 都是文本协议直接用 Wireshark 的 Follow TCP Stream 就能看到完整的会话过程容易理解。SMTP 中客户端发送EHLO、MAIL FROM、RCPT TO、DATA等命令服务器以 250 开头的状态码回应DATA之后的邮件正文以单独一行的.结束。POP3 中客户端发送USER、PASS、STAT、LIST、RETR等命令服务器返回以OK或-ERR开头的响应。捕获过滤器里输入smtp或pop时要注意SMTP 协议实际只监听 25 端口而提交邮件用的 SMTP 服务有时走 465 或 587 端口这会影响捕获结果。SMTP 会话典型报文 C: EHLO pc.example.com S: 250-smtp.example.com C: MAIL FROM:testexample.com S: 250 OK C: RCPT TO:receiverexample.com S: 250 OK C: DATA S: 354 End data with CRLF.CRLF C: Subject: test C: C: hello. C: . S: 250 OK这段报文中C:开头的是客户端发出的命令S:开头的是服务器响应。状态码的含义可以归纳为220表示服务就绪250表示请求命令完成354表示开始输入邮件内容221表示会话结束。5.3 FTP 的双连接模型与抓包时的常见陷阱FTP 的分析核心在于它有两个连接控制连接走 21 端口数据连接走 20 端口或动态端口。控制连接上传输的是USER、PASS、LIST、RETR、STOR等命令和对应的响应码数据连接则承载实际的文件内容。抓包时最常见的坑是只过滤ftp协议结果看不到文件传输内容这不是没抓到而是数据连接走的不是 21 端口。展览在显示过滤器里输入tcp.port 20 || tcp.port 1024就能覆盖数据连接。不过需要注意FTP 的数据连接端口是根据 PASV 或 PORT 模式动态协商的如果担心遗漏直接用ftp过滤器分析控制命令再配合查看数据连接的 TCP 传输情况。FTP 控制连接典型交互 C: USER anonymous S: 331 Password required C: PASS anonymousexample.com S: 230 Logged in C: LIST S: 150 Here comes the directory listing S: 226 Directory send OK响应状态码的首位数字有固定含义1xx表示成功但需要继续2xx表示命令成功3xx表示需要进一步提供信息4xx表示暂时性失败5xx表示永久性失败。5.4 DNS 的 UDP 报文分析与排错验证DNS 查询一般使用 UDP 的 53 端口报文字段包括事务 ID、标志位、问题数、回答数、授权记录数、附加记录数、查询名和查询类型。Wireshark 里过滤dns后可以看到每个 DNS 请求后面紧跟着一个 DNS 响应两者通过事务 ID 对应。# 用 nslookup 验证 DNS 解析是否正常 nslookup -typeA www.sina.com.cn 8.8.8.8 # -typeA 表示查询 A 记录8.8.8.8 是外部 DNS 服务器如果实验中发现 DNS 响应包的 Flags 字段里出现0x8183低八位的第三位是 1表示服务器返回了“名字不存在”的错误。通过对比 Wireshark 里捕获的 UDP 报文和nslookup的输出结构可以看到查询名、类型、类别这些字段在两种表示下的对应关系这也是验证协议解析是否正确的一种方式。最后一个验证技巧把 Wireshark 里捕获的 DNS 报文和ping执行时出现的 IP 地址做一次对照。先nslookup得到域名对应的 IP再ping该 IP观察 ICMP 报文中的请求和应答字段是否与原文实验中的包结构一致——这样整个实验的链路层、网络层、传输层到应用层就形成了一个可验证的闭环。本文还有配套的精品资源点击获取