PacketTRacer 抓包实验：从协议字段到 TCP 三次握手的闭环验证

简介：这份PDF面向计算机网络初学者与实验课学生，围绕PacketTracer模拟环境下的基础组网实验提供系统指导，帮助读者在动手操作中理解网络原理与设备配置方法。资源共1个PDF文件，压缩包约1.51MB，内容以图文步骤和实验说明为主，便于按章节查阅与课堂对照练习。目前已有1347人学习下载，适合作为课程配套资料或自学参考。内容从基本技能实验切入，涵盖网线制作中的直连线与交叉线区别、EIA/TIA 568A与568B线序标准、双机互联的IP地址与子网掩码设置、交换机星型局域网构建，以及Windows Server 2003操作系统安装等模块，并配有实验拓扑与操作截图。读者可据此掌握实验设备清单、操作流程与测试验证思路，逐步建立从物理层布线到网络层配置的完整认知，为后续更复杂的网络实验打下基础。

1. PacketTRacer 实验指导：从抓包到协议栈验证的最小闭环

很多人做计算机网络实验时，抓包工具打开、过滤器一填、点开始，看到满屏滚动就以为完事了。真正翻车的地方在后面：老师问「这个 TCP 三次握手为什么第二段 ACK 的 seq 是 1 而不是 0」，或者「你抓的这帧以太网类型字段 0x0800 对应哪一层」，答不上来。PacketTRacer 这类实验指导的核心价值，不是教你点按钮，而是把「抓到的字节」和「协议规范里的字段」对上号，形成一条可验证的闭环。它适合正在上计算机网络实验课的学生、需要给团队做协议培训的 DevOps 工程师，以及准备 408 或期末复习想动手验证理论的人。下面按「先立住原理、再动手复现、最后避坑」的顺序拆开讲。

2. 抓包环境搭建与过滤器配置：别让第一帧就抓错

2.1 为什么选 PacketTRacer 而不是直接上通用抓包工具

PacketTRacer 的定位是教学向的协议分析器，和通用抓包工具最大的区别在于它把「协议分层」做成了显式视图。通用工具给你的是原始字节流加一层解析树，你得自己知道 Ethernet II 帧头 14 字节、IP 头 20 字节起步、TCP 头 20 字节起步。PacketTRacer 通常会把每一层的字段名和值并排显示，并且内置了常见协议的校验逻辑，比如 IP 头校验和、TCP 伪首部校验。这意味着你在做「以太网帧格式」这类实验时，不用先花两小时配 Wireshark 的列显示。

但教学工具的通病是抽象过头，容易让人忽略真实链路上的噪声。我一般会建议：先用 PacketTRacer 把单个协议的字段结构吃透，再切到通用工具看真实流量。两者不是替代关系，是「先看图纸再上工地」的关系。

选型上还有一点：PacketTRacer 这类工具通常对回环接口和虚拟网卡的支持不如通用工具完善。如果你要做本机进程间通信的抓包，比如验证 TCP 连接建立，得确认它能不能绑定到 loopback。不能绑的话，就老老实实用两台虚拟机或者一台物理机加一台虚拟机，走真实网卡。

2.2 最小可复现的抓包环境搭建步骤

下面以 Linux 环境为例，给出一套能跑通的最小步骤。Windows 下把命令换成对应的 ipconfig 和 netsh 即可，逻辑一样。

# 1. 确认网卡名称，记下你要抓的那块，比如 eth0 或 ens33 ip link show # 2. 确认 PacketTRacer 可执行文件位置，假设在 /opt/packettracer/bin 下 ls /opt/packettracer/bin # 3. 以 root 权限启动，因为抓包需要 CAP_NET_RAW 能力 sudo /opt/packettracer/bin/packettracer --interface eth0 --filter "tcp port 80" # 4. 另开一个终端，产生一条 HTTP 流量用于验证 curl -s http://example.com > /dev/null # 5. 回到 PacketTRacer 界面，确认抓到了至少 3 个包：SYN、SYN-ACK、ACK

这段命令的逻辑说明：第一步是确认抓包对象，抓错网卡是最常见的「抓不到包」原因。第二步确认工具存在，避免路径问题。第三步的--filter参数用的是 BPF 语法，tcp port 80表示只抓 TCP 且端口为 80 的包。第四步用 curl 产生流量，注意用-s静默模式避免多余输出干扰。第五步是验证点，如果只看到 SYN 没有 SYN-ACK，说明流量没出去或者被防火墙拦了。

参数说明：--interface后面跟网卡名，不能写any除非工具明确支持；--filter的引号不能省，否则 shell 会把空格拆成多个参数。如果你要抓 UDP 的 DNS 查询，把过滤器换成udp port 53。要抓 ICMP 就用icmp。这些过滤器写法在 PacketTRacer 和通用工具之间是通用的，因为底层都是 libpcap。

提示：抓包前先确认网卡处于 UP 状态，用ip link show eth0看 state 是不是 UP。如果是 DOWN，先sudo ip link set eth0 up。

2.3 过滤器写错会导致什么：三个真实翻车场景

第一个场景：写了tcp port 80但目标是 HTTPS 的 443 端口，结果一个包都抓不到，还以为工具坏了。原因是过滤器是精确匹配，80 和 443 是两个端口。解决方法是写tcp port 80 or tcp port 443，或者干脆先不写过滤器抓全量再分析。

第二个场景：写了host 192.168.1.100但本机 IP 是 192.168.1.101，抓到的全是广播包。原因是 host 过滤器只匹配源或目的地址等于该 IP 的包。解决方法是先ip addr show确认本机 IP，或者用net 192.168.1.0/24抓整个网段。

第三个场景：过滤器里写了port 80但没写协议，结果 TCP 和 UDP 的 80 端口都抓了。虽然 80 端口通常只有 TCP，但严格来说这是不精确的。解决方法是明确写tcp port 80。

这三个场景的共同点是：过滤器语法没错，但语义和你的预期不匹配。抓包工具不会报错，它只是忠实地执行你给的规则。所以每次抓不到包，先检查过滤器，再检查网卡，最后检查流量是否真的产生了。

3. 以太网帧与 ARP 解析：从字节偏移看协议分层

3.1 以太网 II 帧头的 14 个字节到底怎么数

以太网 II 帧头固定 14 字节，结构是：目的 MAC 6 字节、源 MAC 6 字节、类型 2 字节。类型字段 0x0800 表示上层是 IPv4，0x0806 表示 ARP，0x86DD 表示 IPv6。这个「类型字段」就是协议分层的粘合剂，它告诉接收方把后面的数据交给哪个协议处理。

在 PacketTRacer 里选中一个帧，通常会看到类似这样的字段展开：

这张表里前三个字段是以太网帧头，后面的是 ARP 报文的内容。注意 ARP 报文是直接封装在以太网帧里的，没有 IP 头。这就是为什么 ARP 被称为「三层半」协议——它工作在二层和三层之间。

数字节的时候有个血泪经验：PacketTRacer 的十六进制视图里，每两个字符是一个字节。目的 MAC 占前 12 个字符，源 MAC 占接下来 12 个，类型占最后 4 个。如果你数出来对不上，大概率是把偏移量算错了。建议用工具的「高亮字段」功能，点哪个字段就高亮哪段字节，比手数靠谱。

3.2 用 ARP 请求和应答验证 MAC 与 IP 的映射

ARP 的实验目标很明确：验证「同一网段内，IP 地址如何解析成 MAC 地址」。操作步骤如下。

# 1. 清空本机 ARP 缓存，确保能抓到完整的请求应答过程 sudo ip neigh flush all # 2. 确认缓存已空 ip neigh show # 3. 在 PacketTRacer 里设置过滤器，只抓 ARP # 过滤器写：arp # 4. 另开终端 ping 同一网段的另一台主机，比如 192.168.1.20 ping -c 1 192.168.1.20 # 5. 回到 PacketTRacer，应该看到两个包： # 第一个是 ARP 请求，目的 MAC 是 ff:ff:ff:ff:ff:ff，Opcode 是 1 # 第二个是 ARP 应答，目的 MAC 是请求方的 MAC，Opcode 是 2

逻辑说明：第一步清空缓存是关键，否则本机可能直接用缓存里的 MAC 发数据，你就抓不到 ARP 请求了。第二步确认清空成功。第三步设置过滤器减少干扰。第四步产生 ARP 流量。第五步验证。

参数说明：ip neigh flush all在部分发行版上需要 root 权限。如果提示命令不存在，用sudo arp -d或者sudo ip -s neigh flush all。ping 的-c 1表示只发一个包，避免持续输出。

在 PacketTRacer 里看 ARP 应答包时，重点看两个字段：Sender MAC 和 Sender IP。Sender MAC 就是被 ping 那台主机的 MAC，Sender IP 是它的 IP。这两个值的组合就是 ARP 缓存里要存的内容。你可以回到终端用ip neigh show确认缓存里确实多了这一条。

注意：如果 ping 的是不同网段的主机，ARP 请求的目标 IP 会是网关地址，而不是最终目的 IP。这是很多人做实验时困惑的点——「我 ping 的是 8.8.8.8，为什么 ARP 请求里问的是 192.168.1.1」。原因是跨网段通信时，主机只需要知道网关的 MAC，剩下的路由由网关负责。

3.3 帧长度与填充字段：为什么最小帧是 64 字节

以太网规定最小帧长 64 字节，这个 64 字节是从目的 MAC 开始算到帧校验序列（FCS）结束。如果上层数据太短，比如 ARP 请求只有 28 字节，加上帧头 14 字节才 42 字节，不够 64，就需要填充字段补到 46 字节的数据部分。

在 PacketTRacer 里抓一个 ARP 包，看它的总长度。如果显示 60 字节（不含 FCS）或 64 字节（含 FCS），说明有填充。填充字段的内容通常是全零，但规范不要求具体值，只要求长度够。

这个知识点在考试里经常考：为什么最小帧是 64 字节？答案是碰撞检测。以太网用 CSMA/CD，发送方要在发送过程中检测碰撞。如果帧太短，发送方可能在检测到碰撞之前就已经发完了，导致无法重传。64 字节对应的是 10Mbps 以太网下 512 比特的传输时间，也就是往返传播延迟的两倍。这个数值在千兆以太网里通过载波扩展机制做了调整，但最小帧长仍然是 64 字节。

实验里验证这一点的方法：抓一个 ARP 请求，看它的长度字段。如果 PacketTRacer 显示的长度是 42 字节，说明它没算填充；如果显示 60 或 64，说明算了。不同工具的显示口径不一样，看的时候注意区分。

4. IP 与 ICMP 联动分析：ping 命令背后的完整链路

4.1 IP 头 20 字节里哪几个字段必须盯死

IP 头固定部分 20 字节，字段不少，但实验里必须盯死的是这几个：版本（4 位）、首部长度（4 位）、总长度（16 位）、标识（16 位）、标志（3 位）、片偏移（13 位）、生存时间 TTL（8 位）、协议（8 位）、首部校验和（16 位）、源 IP（32 位）、目的 IP（32 位）。

其中最容易翻车的是「首部长度」和「总长度」的区别。首部长度的单位是 4 字节，所以值通常是 5（表示 20 字节）。总长度的单位是 1 字节，表示整个 IP 数据报的长度，包括首部和数据。如果你看到首部长度是 5、总长度是 60，那数据部分就是 40 字节。

TTL 是另一个关键字段。每经过一个路由器，TTL 减 1，减到 0 就丢弃并发 ICMP 超时报文。traceroute 就是利用这个机制工作的。实验里可以用 ping 的-t参数（Windows）或-T参数（Linux）指定 TTL，观察不同 TTL 下的响应。

协议字段告诉接收方上层是什么：1 是 ICMP，6 是 TCP，17 是 UDP。这个字段和以太网帧的类型字段作用类似，但层次不同。以太网类型字段区分的是 IP 和 ARP，IP 协议字段区分的是 TCP、UDP、ICMP。

4.2 抓一次 ping 的完整流程：从 ICMP 请求到应答

下面用一套可复现的步骤，把 ping 的完整链路抓下来并逐层验证。

# 1. 设置 PacketTRacer 过滤器，同时抓 ICMP 和 ARP # 过滤器写：icmp or arp # 2. 清空 ARP 缓存，确保能看到 ARP 请求 sudo ip neigh flush all # 3. ping 同一网段的主机，只发两个包 ping -c 2 192.168.1.20 # 4. 在 PacketTRacer 里按时间顺序看包： # 包1：ARP 请求（广播） # 包2：ARP 应答（单播） # 包3：ICMP Echo Request（类型 8，代码 0） # 包4：ICMP Echo Reply（类型 0，代码 0） # 包5：第二个 ICMP Echo Request # 包6：第二个 ICMP Echo Reply # 5. 选中包3，展开 IP 头，确认： # - 协议字段 = 1（ICMP） # - 源 IP = 本机 IP # - 目的 IP = 192.168.1.20 # - TTL = 64（Linux 默认）或 128（Windows 默认） # 6. 展开 ICMP 头，确认： # - 类型 = 8（请求） # - 代码 = 0 # - 标识符和序列号用于匹配请求和应答

逻辑说明：第一步的过滤器同时抓 ICMP 和 ARP，因为第一次 ping 会先触发 ARP。第二步清缓存确保 ARP 一定出现。第三步发两个包是为了看序列号的变化。第四步按顺序看包，理解「先 ARP 后 ICMP」的顺序。第五步和第六步是逐字段验证。

参数说明：ping 的-c 2表示发两个包。Linux 下默认 TTL 是 64，Windows 下是 128，这个差异可以用来判断目标主机的操作系统。ICMP 的标识符字段在 Linux 下通常是进程 ID，序列号从 1 开始递增。

在 PacketTRacer 里对比请求和应答包时，重点看两个字段的变化：类型从 8 变成 0，源 IP 和目的 IP 互换。标识符和序列号保持不变，这样发送方才能把应答和请求匹配上。如果标识符对不上，说明抓到了其他进程的 ping。

提示：如果 ping 不通但 ARP 能通，问题通常出在 ICMP 被防火墙拦了。Linux 下检查sudo iptables -L -n看有没有 DROP ICMP 的规则。Windows 下检查防火墙的入站规则。

4.3 TTL 递减与 traceroute 的联动验证

traceroute 的原理是发送一系列 TTL 递增的包，第一个包 TTL=1，到达第一个路由器后 TTL 减为 0，路由器丢弃并返回 ICMP 超时报文（类型 11，代码 0）。第二个包 TTL=2，到达第二个路由器才超时。以此类推，直到到达目的主机。

实验里可以这样验证：

# 1. PacketTRacer 过滤器写：icmp # 2. 执行 traceroute，限制最大跳数为 3，避免抓太多包 traceroute -m 3 8.8.8.8 # 3. 在 PacketTRacer 里观察： # - 第一组包：TTL=1 的 UDP 包（Linux 默认用 UDP）和返回的 ICMP 超时报文 # - 第二组包：TTL=2 的 UDP 包和返回的 ICMP 超时报文 # - 第三组包：TTL=3 的 UDP 包和返回的 ICMP 超时报文 # 4. 选中 ICMP 超时报文，展开 IP 头，确认： # - 源 IP 是中间路由器的地址 # - 协议字段 = 1（ICMP） # - 展开 ICMP 头，类型 = 11，代码 = 0 # 5. 选中 ICMP 报文的数据部分，里面包含了原始 UDP 包的 IP 头和前 8 字节数据 # 这是 ICMP 差错报文的规定：必须包含原始数据报的 IP 头和至少 8 字节数据

逻辑说明：第一步限制过滤器。第二步用-m 3限制跳数，避免抓包过多。第三步观察 TTL 递增和 ICMP 超时的对应关系。第四步验证 ICMP 超时报文的字段。第五步验证 ICMP 差错报文携带原始数据的规定。

参数说明：Linux 下 traceroute 默认用 UDP 高端口，Windows 下 tracert 默认用 ICMP。如果要强制用 ICMP，Linux 下加-I参数。-m 3表示最大 3 跳。

这个实验的价值在于把「TTL 是什么」从概念变成可观察的现象。你看到 TTL=1 的包出去，回来的 ICMP 超时报文里源 IP 是第一个路由器，就理解了 TTL 的作用。这比背「TTL 是生存时间，每经过一个路由器减一」要深刻得多。

5. TCP 三次握手抓包验证：序列号与标志位的对应关系

5.1 三次握手的三个包各自长什么样

TCP 三次握手的三个包，在 PacketTRacer 里看 TCP 头的标志位和序列号，规律很清晰。

第一个包（SYN）：标志位 SYN=1，ACK=0，seq=客户端初始序列号（比如 1000），ack=0。这个包的意思是「我想跟你建立连接，我的起始序列号是 1000」。

第二个包（SYN-ACK）：标志位 SYN=1，ACK=1，seq=服务端初始序列号（比如 2000），ack=1001。这个包的意思是「我同意建立连接，我的起始序列号是 2000，我期望你下一个包的序列号是 1001」。

第三个包（ACK）：标志位 SYN=0，ACK=1，seq=1001，ack=2001。这个包的意思是「我确认收到你的 SYN-ACK，我下一个包的序列号是 1001，我期望你下一个包的序列号是 2001」。

关键点：SYN 和 FIN 各消耗一个序列号，所以第二个包的 ack 是 1000+1=1001，第三个包的 ack 是 2000+1=2001。数据字节不消耗额外序列号，只有 SYN、FIN 和实际数据消耗。

在 PacketTRacer 里验证时，选中第一个包，展开 TCP 头，看 Flags 字段。通常显示为SYN或0x02。第二个包显示SYN, ACK或0x12。第三个包显示ACK或0x10。序列号和确认号在 TCP 头的固定位置，偏移量是 4 字节和 8 字节。

5.2 用 curl 触发握手并逐包核对序列号

# 1. PacketTRacer 过滤器写：tcp port 80 and host 目标IP # 假设目标 IP 是 93.184.216.34 # 2. 执行 curl，只发 HEAD 请求，减少后续数据传输的干扰 curl -I http://example.com # 3. 在 PacketTRacer 里找到前三个 TCP 包： # 包1：SYN，seq=0（相对序列号）或某个随机值（绝对序列号） # 包2：SYN-ACK，seq=0，ack=1 # 包3：ACK，seq=1，ack=1 # 4. 如果 PacketTRacer 显示的是相对序列号，验证： # - 包1 seq=0，ack 无 # - 包2 seq=0，ack=1 # - 包3 seq=1，ack=1 # 5. 如果显示的是绝对序列号，验证： # - 包1 seq=X，ack 无 # - 包2 seq=Y，ack=X+1 # - 包3 seq=X+1，ack=Y+1

逻辑说明：第一步设置过滤器，只抓目标 IP 的 80 端口流量。第二步用-I发 HEAD 请求，服务端只返回头部，减少数据包干扰。第三步找到前三个 TCP 包。第四步和第五步分别验证相对序列号和绝对序列号的情况。

参数说明：curl -I等价于--head，只请求头部。PacketTRacer 默认可能显示相对序列号，这样更直观，但绝对序列号能看出初始序列号的随机性。TCP 初始序列号是随机生成的，这是为了防止旧连接的延迟包干扰新连接。

注意：如果抓到的第一个包不是 SYN，而是 ACK 或其他，说明连接已经建立了，或者你抓的是其他连接的包。解决方法是先关闭所有到目标 IP 的连接，或者换一个目标 IP。

5.3 四次挥手为什么比三次握手多一次

四次挥手的过程：主动关闭方发 FIN，被动关闭方回 ACK，被动关闭方发 FIN，主动关闭方回 ACK。比三次握手多一次的原因是 TCP 是全双工的，每个方向需要单独关闭。

在 PacketTRacer 里抓四次挥手，过滤器和抓握手一样，只是触发方式换成关闭连接。curl 执行完会自动关闭连接，所以抓完握手继续看后面的包就能看到挥手。

关键字段：FIN 包消耗一个序列号，和 SYN 一样。所以第一个 FIN 的 seq 是当前序列号，第二个 FIN 的 ack 是第一个 FIN 的 seq+1。ACK 包不消耗序列号，所以中间的 ACK 的 seq 和 ack 不变。

实验里容易困惑的点：为什么第二个 FIN 和第一个 FIN 之间可能隔了很久？因为被动关闭方可能还有数据要发，发完才发 FIN。这个间隔在抓包时表现为时间戳的差异。PacketTRacer 通常会显示每个包的时间戳，可以看这个间隔。

6. 实验避坑与排查：抓不到、对不上、看不懂怎么办

6.1 抓不到包：从网卡到过滤器的排查顺序

现象：PacketTRacer 显示正在抓包，但一个包都没有。

原因一：网卡选错了。本机有多块网卡时，默认可能选了虚拟网卡或未连接的网卡。解决方法是ip link show确认哪块网卡有流量，重新指定--interface。

原因二：过滤器太严。比如写了tcp port 80 and host 192.168.1.100，但实际流量是到 192.168.1.101 的。解决方法是先去掉过滤器抓全量，确认有流量后再逐步加过滤条件。

原因三：权限不够。普通用户没有 CAP_NET_RAW 能力，抓不到包但工具不报错。解决方法是sudo启动，或者setcap cap_net_raw+eip给可执行文件授权。

原因四：流量走了回环接口。本机进程间通信不走物理网卡，走 lo 接口。解决方法是抓lo接口，或者用两台机器。

6.2 字段对不上：相对序列号与绝对序列号的混淆

现象：抓到的 TCP 包 seq 和 ack 都是小数字，比如 0、1、2，但理论上初始序列号应该是随机大数。

原因：PacketTRacer 默认显示相对序列号，把第一个包的序列号当作 0，后续包相对于它计算。这是为了教学方便，但和真实协议行为不符。解决方法是找工具的设置项，切换成绝对序列号显示。如果找不到，就接受相对序列号，但要知道真实值是随机的。

另一个容易混淆的点：IP 头的「首部长度」字段单位是 4 字节，值是 5 表示 20 字节。但「总长度」字段单位是 1 字节，值是 60 表示 60 字节。这两个字段的单位不同，看的时候要区分。

6.3 看不懂 ICMP 差错报文里的嵌套结构

现象：抓到一个 ICMP 超时报文，展开后发现里面还有一层 IP 头和 TCP/UDP 头，不知道是什么。

原因：ICMP 差错报文规定必须包含原始数据报的 IP 头和至少前 8 字节数据。这是为了让发送方知道是哪个数据报出错了。嵌套的那层 IP 头就是原始数据报的。

解决方法：在 PacketTRacer 里展开 ICMP 报文的数据部分，找到嵌套的 IP 头，看它的源 IP 和目的 IP。这两个地址和 ICMP 报文本身的源目的地址是反过来的——ICMP 报文的源是路由器，目的是原始发送方；嵌套 IP 头的源是原始发送方，目的是最终目标。

6.4 时间戳看不懂：相对时间和绝对时间的区别

现象：PacketTRacer 显示的时间戳是 0.000、0.001、0.002 这样的小数，不知道对应真实世界的什么时间。

原因：抓包工具默认显示相对时间，以第一个包为 0 点。这样看包之间的间隔很方便，但不知道绝对时间。解决方法是找设置项切换成绝对时间，或者自己加一个基准时间。

相对时间在分析协议交互时更有用。比如看三次握手的间隔，0.000 到 0.001 是 1 毫秒，说明网络延迟很低。如果间隔是 0.5 秒，说明有延迟。绝对时间在排查「什么时候发生的」这类问题时有用。

6.5 校验和显示错误：是工具算错了还是包真的坏了

现象：PacketTRacer 显示 IP 头校验和或 TCP 校验和错误，但网络通信正常。

原因一：网卡硬件卸载。很多网卡支持校验和卸载，发送时由网卡计算校验和，抓包工具在网卡驱动之前抓到包，看到的是未计算的校验和。解决方法是关闭网卡的校验和卸载功能，sudo ethtool -K eth0 tx off rx off。

原因二：抓包位置不对。在发送端抓包看到的是未计算校验和的包，在接收端抓包看到的是已经验证过的包。解决方法是换到接收端抓，或者接受这个显示错误。

原因三：包真的坏了。如果接收端也显示校验和错误，且通信异常，说明链路有问题。解决方法是检查网线、网卡、交换机端口。

7. 用 PacketTRacer 做协议栈验证的进阶技巧

7.1 构造特定流量验证协议字段的边界值

PacketTRacer 配合一些命令行工具，可以构造特定流量来验证协议字段的边界值。比如验证 IP 分片，可以用 ping 发一个超过 MTU 的包。

# 1. PacketTRacer 过滤器写：icmp # 2. 发一个 3000 字节的 ping 包，超过以太网 1500 字节 MTU ping -c 1 -s 3000 192.168.1.20 # 3. 在 PacketTRacer 里观察： # - 第一个包：ICMP Echo Request，总长度 1500，标志 MF=1，片偏移=0 # - 第二个包：ICMP Echo Request，总长度 1500，标志 MF=1，片偏移=1480 # - 第三个包：ICMP Echo Request，总长度 48，标志 MF=0，片偏移=2960 # 4. 验证片偏移的单位是 8 字节： # 第一个包数据部分 1480 字节，片偏移 0 # 第二个包数据部分 1480 字节，片偏移 1480/8=185 # 第三个包数据部分 8 字节，片偏移 (1480+1480)/8=370

逻辑说明：第一步设置过滤器。第二步发大包触发分片。第三步观察分片结果。第四步验证片偏移的计算。

参数说明：-s 3000指定 ICMP 数据部分 3000 字节，加上 ICMP 头 8 字节和 IP 头 20 字节，总长度 3028 字节。MTU 1500 字节，所以需要分成三个包。第一个包数据 1480 字节（1500-20），第二个包数据 1480 字节，第三个包数据 48 字节（3028-20-1480-1480）。

这个实验的价值在于把「IP 分片」从概念变成可观察的现象。你看到 MF 标志和片偏移的变化，就理解了分片和重组的过程。

7.2 用时间线视图分析协议交互的时序关系

PacketTRacer 通常有时间线视图，把包按时间顺序排列，用不同颜色区分协议。这个视图在分析交互时序时很有用。

比如分析 TCP 慢启动，可以抓一次大文件传输，看时间线上包的时间间隔变化。慢启动阶段，拥塞窗口指数增长，包的时间间隔逐渐缩小。进入拥塞避免阶段后，时间间隔趋于稳定。

再比如分析 DNS 查询，可以看 DNS 请求和应答的时间差。如果时间差很大，说明 DNS 服务器响应慢。如果时间差很小但解析失败，说明 DNS 返回了错误码。

时间线视图的另一个用途是发现异常。比如某个包的时间戳突然跳变，说明有延迟。某个协议的包突然消失，说明连接断了。这些异常在列表视图里不容易发现，在时间线视图里一目了然。

7.3 把抓包结果导出做二次分析

PacketTRacer 通常支持导出 pcap 格式，可以用通用工具做二次分析。比如用 tshark 统计协议分布，用 tcpdump 过滤特定流量。

# 1. 在 PacketTRacer 里导出 pcap 文件，假设保存为 capture.pcap # 2. 用 tshark 统计协议分布 tshark -r capture.pcap -q -z io,phs # 3. 用 tshark 提取所有 HTTP 请求的 URL tshark -r capture.pcap -Y "http.request" -T fields -e http.host -e http.request.uri # 4. 用 tcpdump 过滤特定 IP 的流量并保存 tcpdump -r capture.pcap -w filtered.pcap host 192.168.1.20 # 5. 用 capinfos 查看抓包文件的基本信息 capinfos capture.pcap

逻辑说明：第一步导出 pcap。第二步用 tshark 的协议分层统计功能。第三步提取 HTTP 请求的 Host 和 URI。第四步用 tcpdump 过滤。第五步查看文件信息。

参数说明：-q -z io,phs是 tshark 的统计选项，io,phs表示协议分层统计。-Y是显示过滤器，-T fields指定输出字段。-e指定字段名。这些命令在排查网络问题时很常用，配合 PacketTRacer 的教学视图，可以兼顾学习和实战。

我自己的习惯是：先用 PacketTRacer 把协议字段看明白，再把 pcap 导出来用 tshark 做批量分析。教学工具帮你理解单个包，通用工具帮你理解流量模式。两者结合，既不会迷失在字节里，也不会停留在点按钮的层面。希望帮到你。

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