实验三十三：熟悉文件传送协议FTP

一、实验目的

了解文件传送协议FTP的使用。

掌握FTP服务器的配置方法。

掌握FTP客户端常用命令的使用方法

观察FTP的基本工作过程。

二、实验步骤

2.1 构建网络拓扑与设备选型

在 Cisco Packet Tracer 模拟器中，我们需要构建一个最精简的点对点网络，以排除其他网络设备对数据包的干扰。拖入一台计算机（PC-PT），命名为 PC0 ，作为本次实验的 FTP 客户端 。拖入一台服务器（Server-PT），命名为 服务器0 ，作为本次实验的 FTP 服务器端。使用合适的线缆（通常为交叉线）将两台设备的以太网接口直接相连。

2.2 规划并标注 IP 编址方案

为了让两台设备处于同一个广播域内能够直接通信，我们需要为它们规划同一网段的 IP 地址。编址方案如下表所示：

设备名称	角色	IP 地址	子网掩码
PC0	FTP 客户端	192.168.0.1	255.255.255.0
服务器0	FTP 服务器	192.168.0.2	255.255.255.0

2.3 配置设备的 IP 地址与子网掩码

根据上述规划表，分别进入两台设备的桌面系统进行网络配置：

点击 PC0 ，进入"桌面 (Desktop)"选项卡，选择"IP 配置 (IP Configuration)"，将 IPv4 地址设为 192.168.0.1，子网掩码设为 255.255.255.0。同理，点击 服务器0 ，将其 IPv4 地址设为 192.168.0.2，子网掩码设为 255.255.255.0。

2.4 核心步骤：网络连通性测试 (Ping)

配置完成后，绝对不能直接跳到 FTP 环节。我们必须在 PC0 上进行一次 Ping 测试。

操作步骤： 点击 PC0，进入"桌面"选项卡下的"命令提示符 (Command Prompt)"。输入以下指令并回车： ping 192.168.0.2

预期现象： 系统应当收到 4 次来自 192.168.0.2 的 Reply 回复，丢包率（Lost）为 0%。

深度原理解析：为什么这一步不可省略？

1. 基础排错前置： 测试网络拓扑是否物理连通，以及双方的 IP 配置是否准确。如果此时 Ping 失败，请立刻检查线缆和 IP 拼写，避免将简单的网络层错误带入复杂的应用层排错中。

2. 排除 ARP 干扰（极其关键）： 在纯净的网络环境中，两台设备首次通信时，PC0 只知道服务器的 IP，不知道其 MAC 地址。底层会自动触发 ARP（地址解析协议）广播来寻址。如果我们直接开始抓包做 FTP 实验，抓包列表中会首先跳出 ARP 的交互过程，这会极大地干扰我们对 TCP 三次握手和 FTP 纯净数据流的观察。

3. 缓存 MAC 地址： 通过提前 Ping 一次，PC0 和 服务器0 都会将彼此的 MAC 地址记录在本地的 ARP 缓存表中。这样在后续真正的抓包环节，双方就可以直接封装并发送 TCP 数据包，为你呈现最干净的实验现象。

如果测试失败，请检查网络拓扑、计算机PC0和服务器Server0各自的lP地址和子网掩码配置是否正确。

三、 FTP 服务器与客户端环境准备

在底层网络物理连通后，我们需要在应用层分别配置 FTP 的服务端与客户端，并进行基础的命令交互演练。

3.1 服务端（Server0）FTP 服务配置规范

FTP（文件传送协议）是一个典型的 C/S（客户端/服务器）架构协议。我们首先要让 Server0 扮演好服务器的角色，为客户端提供身份验证和文件读写权限。

按以下步骤进行

（1）在 Server0 的图形用户界面顶部，选择"服务"选项卡。

（2）在服务选项卡左侧的"SERVICES"列表中，单击选择"FTP"服务。

（3）在右侧的"用户设置"配置框中新增一个用户，在"用户名"文本框内输入 beginner。

（4）为新增用户 beginner 设置密码，在"密码"文本框内输入 123456。

（5）勾选所有的文件操作权限：写入 、读取 、删除 、重命名 、列表。

• 读取 (R)： 允许客户端使用 get 命令下载文件。

• 写入 (W)： 允许客户端使用 put 命令上传文件。

• 删除 (D)： 允许客户端使用 delete 命令删除文件。

• 重命名 (N)： 允许客户端使用 rename 命令重命名文件。

• 列表 (L)： 允许客户端使用 dir 命令查看目录。

（6）单击右侧的"添加"按钮，将新增用户加入到下方的 FTP 用户列表中。

（7）此时在 FTP 用户列表中会显示出新增用户的记录，包含具体的用户名（beginner）、密码（123456）以及文件操作权限（显示为 RWDNL）。

（8）在界面下方的"文件"列表中，会显示出当前 FTP 服务器上默认包含的可用文件。

（9）在界面顶部的"服务"状态栏，勾选"开启"选项以正式启动 FTP 服务。

3.2 客户端（PC0）登录与基础命令交互演练

服务器配置就绪后，我们切换到客户端 PC0，通过操作系统的命令行体验完整的文件上传与下载流程。

（1）登录 FTP 服务器

打开 PC0 的"命令提示符 (Command Prompt)"。

• 输入登录命令：ftp 192.168.0.2 并回车。

• 此时系统提示 Trying to connect... 并成功连接，随后打印出服务器的欢迎语 220- Welcome to PT Ftp server，并提示输入用户名 (Username:)。

• 输入我们刚才创建的账号：beginner。

• 系统返回状态码 331- Username ok, need password，提示输入密码 (Password:)。

• 安全机制注意： 输入密码 123456 并回车。请注意，出于安全防偷窥机制，命令行屏幕上不会显示你输入的任何密码字符（连星号都不会有），但这并不代表键盘失灵，盲打完毕直接回车即可。

• 登录成功后，系统返回 230- Logged in，并且左侧的命令提示符由 C:\> 变成了 ftp>，这意味着你现在敲击的所有命令，都将由 FTP 客户端软件接管并发送给服务器，而不是在本地计算机执行。

（2） 探索可用命令与目录列表

获取帮助： 在 ftp> 提示符下输入 help（或 ?），系统会列出当前 FTP 客户端支持的所有操作指令（如 cd, delete, dir, get, put, quit 等）。

查看服务器目录： 输入 dir 命令。系统会拉取并打印出 FTP 服务器当前的目录和文件列表。你可以在列表中找到我们之前在服务器 GUI 界面看到的那些文件。

（3） 测试文件下载 (get 命令)

我们假设需要下载列表中的第一个文件 asa842-k8.bin。

在 ftp> 提示符下输入：get asa842-k8.bin，观察控制台输出：系统会提示正在传输（File transfer in progress...），传输完成后会打印出该文件的总字节数（约 5571584 bytes），以及本次传输的耗时和平均速率。

（4） 退出会话与本地文件验证（核心易错点）

断开连接： 输入 quit 命令结束与服务器的会话（注：如果你像截图中那样不小心打成了 guit，系统会提示无效命令，重新输入 quit 即可 ）。系统会返回 221- Service closing control connection.，并且提示符重新变回了 C:\>，代表控制权交还给了 PC0 的本地操作系统。

本地环境验证： 在 C:\> 提示符下，再次输入 dir 命令。

💡 深度解析：两个 dir 的本质区别

• 刚才在 ftp> 状态下敲的 dir，是向服务器索要文件列表。

• 现在在 C:\> 状态下敲的 dir，是查看 PC0 自己的本地硬盘。

执行后你会发现，PC0 的 C 盘里不仅多出了刚刚下载的 asa842-k8.bin，还静静地躺着一个长度仅为 26 字节的小文件：sampleFile.txt。我们将拿它来测试上传功能。

（5） 测试文件上传 (put 命令) 与最终结案

重新登录： 在 C:\> 下再次输入 ftp 192.168.0.2，重复输入用户名 beginner 和密码 123456 登录服务器。

执行上传： 在 ftp> 提示符下输入：put sampleFile.txt。系统瞬间完成传输，提示 26 bytes copied。

结果验证： 再次输入 dir 拉取服务器目录。拖动滚动条到最底部，你会赫然发现 sampleFile.txt 已经成功出现在了服务器的文件列表中。

完美谢幕： 再次输入 quit 退出系统，完成所有应用层面的功能测试。

四、 观察FTP的基本工作过程

在进入 Packet Tracer 的模拟模式（Simulation Mode）后，我们将监视列表过滤为仅显示 FTP 和 TCP 协议。

FTP基本原理分为主动模式和被动模式两种，主动模式：客户端通过控制连接将自己的临时数据端口号告知服务器，由服务器主动发起与该端口的 TCP 连接，以建立数据通道。被动模式：客户端通过控制连接请求服务器开启一个临时数据端口，然后客户端主动向该端口发起 TCP 连接，以建立数据通道。

在本实验中我们观察FTP被动模式的基本工作过程，模拟模式下进行单步模拟，分为以下四个基本过程，首先是FTP客户端登录FTP服务器端，成功登录后，FTP客户端从FTP服务器下载文件，FTP客户端也可以向FTP服务器端上传文件，最后，FTP客户端可以结束与FTP服务器端的会话并退出。

（1）FTP客户端通过三报文握手，与FTP服务器建立TCP控制连接的过程

第一次握手：客户端发送 SYN（请求建立连接）

在计算机 PC0 的命令行界面中，输入命令 ftp 192.168.0.2 并回车。在 Packet Tracer 的模拟模式下，PC0 节点生成了第一个待发送的 TCP 数据包。点击该数据包，分别查看其"OSI模型"选项卡的"出站 PDU 详细信息"以及"出站 PDU 详细信息"选项卡下的"PDU格式"。

【核心数据解剖】

通过对抓取到的第一个出站报文进行分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
源 IP / 目的 IP	192.168.0.1 / 192.168.0.2	见 PDU 格式图中的 IP 报头 (SRC IP / DST IP)	明确了本次连接请求的发起方为 PC0，接收方为 FTP 服务器 Server0。
源端口 (Source Port)	1026	见 PDU 格式图中的 TCP 报头 (SOURCE PORT)	这是 PC0 操作系统为其分配的一个临时动态端口（大于 1024）。PC0 开启此端口专用于本次 FTP 控制会话。
目的端口 (Dest Port)	21	见 PDU 格式图中的 TCP 报头 (DESTINATION PORT)	这是 FTP 控制连接的标准"众所周知端口"。明确告知服务器，本次请求是针对其运行的 FTP 服务。
标志位 (TCP Flags)	0b00000010	见 PDU 格式图中的 TCP 报头 (FLAGS)	核心实证： 该二进制数据的倒数第二位为 1，完美对应 TCP 首部中的 SYN (同步) 位。这证实了客户端正在向服务器发送标准的"请求建立连接"同步报文。
初始序列号 (Seq Num)	0 (相对值)	见 PDU 格式图中的 TCP 报头 (SEQUENCE NUMBER)	客户端告知服务器，己方后续发送的数据将从编号 0 开始排队，以保证传输的有序性。
确认号 (Ack Num)	0	见 PDU 格式图中的 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	由于目前处于单向发起阶段，尚未收到服务器的任何数据，因此确认号为 0。
状态变更	SYN_SENT	见 OSI 模型图下方的设备处理记录 (第 2 条)	报文生成后，PC0 的 TCP 状态机随之变更为"同步已发送"状态，开始等待服务器的回应。

【阶段分析结论】

在第一次握手中，FTP 客户端（PC0）向服务器（Server0）发送了一个纯控制报文。该报文通过将 FLAGS 字段设置为 0b00000010，明确传达了建立连接的意愿，并完成了初始网络参数（如端口号 1026->21）的分配，正式开启了控制通道的建立过程。

第二次握手：服务器发送 SYN + ACK（确认请求，并反向发起请求）

在模拟模式下，点击"捕获/前进"按钮，让第一个包传输至 FTP 服务器（Server0）。此时 Server0 接收报文并生成了准备发回给客户端的回信。点击 Server0 上的数据包，查看其"OSI模型"选项卡以及"出站PDU详细信息"下的 PDU 格式。

【核心数据解剖】

通过对 Server0 准备发出的出站报文进行分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
源 IP / 目的 IP	192.168.0.2 / 192.168.0.1	见 出站 PDU 格式图中的 IP 报头 (SRC IP / DST IP)	地址反转： 明确此时报文是由服务器 Server0 发往客户端 PC0。
源端口 / 目的端口	21 / 1026	见 出站 PDU 格式图中的 TCP 报头 (SOURCE PORT / DESTINATION PORT)	端口反转： 服务器使用自己的 21 端口，向 PC0 之前开启的 1026 临时端口进行精准回信。
标志位 (TCP Flags)	0b00010010	见 出站 PDU 格式图中的 TCP 报头 (FLAGS)	核心实证： 该二进制数据的倒数第 2 位（SYN）和倒数第 5 位（ACK）均为 1。这证明服务器在"确认(ACK)"收到请求的同时，也向客户端发起了"同步(SYN)"请求。
序列号 (Seq Num)	0 (相对值)	见 出站 PDU 格式图中的 TCP 报头 (SEQUENCE NUMBER)	服务器端也生成了自己的初始序列号 (ISN)，告诉客户端："我发给你的数据，从编号 0 开始"。
确认号 (Ack Num)	1	见 出站 PDU 格式图中的 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	关键确认： 确认为 1，意味着服务器向 PC0 宣告："你序列号为 0 的包我收到了，我正在期待你发送序列号为 1 的包"。
状态变更	SYN_RECEIVED	见 OSI 模型图下方的设备处理记录 (第 5 条)	服务器接受了连接请求，其 TCP 状态机变更为"同步已接收"，等待客户端的最后一次确认。

【阶段分析结论】

在第二次握手中，FTP 服务器扮演了"承上启下"的角色。通过发送 SYN + ACK 报文，服务器不仅用 ACK=1 确认了客户端的连通性，同时用 SYN=1 发起了反向的连通性测试。此时，服务器已分配好连接资源，处于半连接状态（SYN_RECEIVED）。

第三次握手：客户端发送纯 ACK（最终确认）

在模拟模式下，再次点击"捕获/前进"按钮，将服务器发出的 SYN+ACK 报文传回客户端（PC0）。PC0 接收该报文后，内部进行处理并生成了本次握手的最后一个回信数据包。点击 PC0 节点上新生成的这个出站数据包，查看其"OSI模型"选项卡以及"出站PDU详细信息"下的 PDU 格式。

【核心数据解剖】

通过对客户端（PC0）发出的最后这个出站确认报文进行分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
源 IP / 目的 IP	192.168.0.1 / 192.168.0.2	见 出站 PDU 格式图中的 IP 报头 (SRC IP / DST IP)	明确了这最后一封确认信是由客户端 PC0 发往服务器 Server0。
源端口 / 目的端口	1026 / 21	见 出站 PDU 格式图中的 TCP 报头 (SOURCE PORT / DESTINATION PORT)	PC0 继续使用其 1026 临时端口，向服务器的 21 端口发送确认。
标志位 (TCP Flags)	0b00010000	见 出站 PDU 格式图中的 TCP 报头 (FLAGS)	核心实证： 二进制数据的倒数第 5 位为 1（即 ACK 位 ），而倒数第 2 位（SYN 位）已恢复为 0。这证实了客户端在此步仅发送纯粹的确认（ACK），不再发起同步请求。
序列号 (Seq Num)	1	见 出站 PDU 格式图中的 TCP 报头 (SEQUENCE NUMBER)	客户端的序列号由初始的 0 迈进了 1，表示它之前序列号为 0 的 SYN 握手包已完成使命，这是它发送的"第二个"TCP逻辑分段。
确认号 (Ack Num)	1	见 出站 PDU 格式图中的 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	关键确认： 客户端向服务器宣告："你序列号为 0 的 SYN+ACK 包我已经收到了，通道没问题"。
状态变更	ESTABLISHED	见 OSI 模型图（入站处理说明）第 6 条	高光时刻： PC0 确认了双方收发能力均正常，将 TCP 连接状态正式设置为"已建立"（ESTABLISHED）。

【阶段分析结论】

在第三次握手中，客户端（PC0）向服务器发送了纯 ACK 报文。随着这个报文的生成与发送，客户端单方面进入了 ESTABLISHED 状态；当该报文顺利抵达服务器后，服务器也将进入 ESTABLISHED 状态。至此，一条可靠的、全双工的 TCP 控制连接（192.168.0.1:1026 ⟷ 192.168.0.2:21）正式建立完毕，为后续 FTP 应用层明文传输用户名和密码铺平了道路。

第四步（阶段过渡）：服务器确认连接确立并下发欢迎消息

在第三次握手（纯 ACK 报文）抵达 FTP 服务器（Server0）后，点击 Server0 节点上新生成的事件。此时可以观察到服务器连续进行了两次核心处理：首先在 TCP 层确认连接建立，随后立即在 FTP 应用层生成了欢迎消息（Welcome Message）并准备下发给客户端。

【核心数据解剖】

通过对 Server0 生成的这个出站 FTP 数据包（即将发往 PC0 的欢迎消息）进行抓包分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
应用层协议	FTP	见 OSI 模型图（出站详细信息）第 7 层	实验的里程碑： 这是本次实验中首次出现应用层数据封装。证明底层的 TCP"修路"工作已彻底完成，开始正式传输真实的 FTP 业务数据。
源 IP / 目的 IP	192.168.0.2 / 192.168.0.1	见 PDU 格式图中的 IP 报头 (SRC IP / DST IP)	明确这是由 FTP 服务器向客户端下发的问候数据。
源端口 / 目的端口	21 / 1026	见 PDU 格式图中的 TCP 报头 (SOURCE PORT / DEST_PORT)	关键属性： 服务器通过其 FTP 控制端口（21） 发出此报文。证实了 21 端口是负责传输控制文本（如欢迎词、命令）的，而非文件数据通道。
标志位 (TCP Flags)	0b00011000	见 PDU 格式图中的 TCP 报头 (FLAGS)	全新特征： 倒数第 4 位（PSH 强制推送位 ）和倒数第 5 位（ACK 确认位 ）同时置 1。PSH=1 表示该报文携带了需要立即处理的文本，要求 PC0 网卡收到后立刻向上层（控制台）推送显示。
序列号 (Seq Num)	1	见 PDU 格式图中的 TCP 报头 (SEQUENCE NUMBER)	服务器开始发送它在这个连接中的第一个有效数据段。
确认号 (Ack Num)	1	见 PDU 格式图中的 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	继续保持为 1，维持双向同步确认机制。
有效载荷长度	52 字节	见 OSI 模型出站详细信息底部的描述文本 (第 1 条)	相比于此前长度为 0 或 24 的纯控制报文，这额外的 52 个字节正是打包在内的 FTP 欢迎英文字符串。
应用层行为	发送欢迎消息	见 OSI 模型入站详细信息底部的描述文本 (第 1 条)	明确指出"FTP 服务器向 FTP 客户端发送欢迎消息"。

【阶段分析结论】

当 TCP 三次握手成功，服务器状态机进入 ESTABLISHED 后，FTP 控制连接正式就绪。FTP 服务端程序立刻响应，通过 21 端口下发了长度为 52 字节、带有 PSH（推送）标志位的应用层欢迎报文。当该报文顺利送达客户端后，PC0 的屏幕上将回显 220- Welcome to PT Ftp server 并在下一行打印 Username:，从而正式引导用户进入账号密码登录环节。

（2）FTP客户端基于TCP控制连接，使用用户名和密码登录FTP服务器的过程

第五步：客户端接收欢迎语并封装用户名报文（PC0 视角）

【实验操作与现象】

当 FTP 服务器发来的欢迎报文抵达客户端（PC0）后，控制台显示 Username:。用户在提示符后输入用户名 beginner 并敲击回车。此时让实验停留在这一瞬间：前一个服务器的包刚收完，PC0 本地新生成的包还在排队，尚未发送给服务器0。点击 PC0 此时的事件，查看其"OSI模型"以及"出站PDU详细信息"中的"PDU格式"。

【核心数据解剖】

通过对 PC0 本地当前经历的这两个报文事件（收到的欢迎包与刚生成的用户名包）进行深度解剖，核心字段数据如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
应用层当前动作	1. FTP client sends username to FTP server.	见 OSI 模型图最下方说明 (第 1 条)	状态实证： 证实输入 beginner 回车后，PC0 的 FTP 应用层立即被激活，开启了"发送用户名"的动作。
源端口 / 目的端口	1026 / 21	见 出站 PDU 详细信息 TCP 报头	临时会话窗口依然是 1026，目标依然是服务器的 21 号控制端口。
标志位 (TCP Flags)	0b00011000	见 PDU 格式图 TCP 报头 (FLAGS)	传输特征： ACK（确认位）与 PSH（推送位）同时置 1。代表这个新包既要对上一个收到的包做确认，又要强制把刚写好的用户名推向网络。
序列号 (Seq Num)	1	见 PDU 格式图 TCP 报头 (SEQUENCE NUMBER)	客户端的本地序列号维持在 1，意味着这是连接建立后，客户端准备发送的第一段有效业务载荷。
确认号 (Ack Num)	53	见 PDU 格式图 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	确认号从握手时的 1 突变成 53。证明 PC0 确实刚刚完整接收了服务器发来的 52 字节欢迎词（1 + 52 = 53），并在本地新包的头部盖上了"52字节已收到，下次请从53发"的确认戳。
应用层命令 (Command)	USER	见 PDU 格式图最底部 FTP Layer	FTP 协议的标准登录指令，表明该报文承载的是账号身份。
应用层参数 (Argument)	beginner	见 PDU 格式图最底部 FTP Layer	明文传输铁证： 此时包虽然还在 PC0 内部，但应用层已经把输入的 beginner 毫无加密地暴露在 PDU 中。有力证明了传统 FTP 协议在控制连接中的不安全性。

【阶段分析结论】

在第五步的特定瞬间，通信过程在 PC0 本地形成了完美的闭环：客户端刚刚完整接收了服务器 21 号端口发来的 52 字节欢迎消息，使得本地 TCP 状态机的确认号（Ack Num）演进为 53；而在用户键入 beginner 并回车后，应用层立刻在本地打包出明文的 USER beginner 指令，并附加 PSH 推送标志。该报文在 PC0 的网络栈中封装完毕，驻留在网卡缓冲区，处于"蓄势待发"的状态。

第六步：服务器处理用户名并要求输入密码（Server0 视角）

在模拟模式下，随着 PC0 发出的用户名数据包抵达 FTP 服务器（Server0），Server0 节点上触发了数据处理事件。点击 Server0 上的事件包，分别查看其"入站 PDU 详细信息"（服务器收到了什么）以及"出站 PDU 详细信息"（服务器回复了什么）。

【核心数据解剖】

通过对 Server0 的入站（Inbound）和出站（Outbound）报文进行双向分析，核心字段数据及其底层含义如下表所示：

数据处理阶段	数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
入站 (接收请求)	应用层提取	FTP Command: USER FTP Argument: beginner	见 入站 PDU 格式图最底部	接收证实： 服务器成功从网络底层剥离出纯文本，读取到了客户端明文提交的登录账号 beginner。
入站 (接收请求)	入站序列号与确认号	Seq: 1 Ack: 53	见 入站 PDU 格式图 TCP 报头	确认这是客户端在建立连接后发来的第一批业务数据（Seq=1），且客户端已确认收到前序 52 字节的欢迎语（Ack=53）。
入站 (接收请求)	接收数据长度	36 字节	见 入站 OSI 模型图第 2 条说明	证实本次接收到的 TCP 有效载荷数据长度为 36 字节。
---	---	---	---	---
出站 (生成响应)	出站序列号 (Seq Num)	53	见 出站 PDU 格式图 TCP 报头	服务器的序列号变为 53，完美承接了客户端发来的 Ack=53，确保数据流的连续性。
出站 (生成响应)	出站确认号 (Ack Num)	37	见 出站 PDU 格式图 TCP 报头	硬核数学实证： 确认号变成 37。因为服务器收到了客户端 Seq=1 且长度为 36 字节的数据（1 + 36 = 37），借此告诉客户端："你的用户名包我完整收到了"。
出站 (生成响应)	标志位 (TCP Flags)	0b00011000	见 出站 PDU 格式图 TCP 报头	ACK与PSH同时置1。服务器既在确认收到用户名，又在强制推送下一步的反馈指令。
出站 (生成响应)	应用层响应代码	Code: 331	见 出站 PDU 格式图最底部 FTP Response	FTP 协议的标准状态码 331，表示"用户名正确（或已受理），需要密码"。
出站 (生成响应)	应用层响应文本	Message: Username ok, need password	见 出站 PDU 格式图最底部 FTP Response	服务器通过 21 号控制端口下发的明文提示语，准备回显到客户端的屏幕上以引导用户输入密码。

【阶段分析结论】

在此步骤中，FTP 服务器成功接收并解析了客户端发来的明文用户名报文。TCP 协议的序列号与确认号机制在此处展现了极其严密的逻辑闭环（客户端的 Seq=1 加上长度 36，精确推导出了服务器回包的 Ack=37）。随后，服务器 FTP 应用程序生成了状态码为 331 的响应报文，提示需要密码，并将其封装入带有 PSH 标志位的 TCP 数据段中，准备发回客户端。

第七步：客户端接收提示并提交明文密码（PC0 视角）

当服务器发出的响应报文送达 PC0 时，命令行界面出现 Password: 提示符。在控制台中输入密码 123456（输入时屏幕无显示）并敲击回车。此时实验暂停在这一瞬间：PC0 刚处理完入站的服务器提示包，并在本地生成了出站的密码包。分别点击事件列表中的对应事件，查看其"入站 PDU 详细信息"与"出站 PDU 详细信息"。

【核心数据解剖】

通过对 PC0 此时经历的"一收一发"两个报文进行深度对比分析，核心字段数据如下表所示：

数据处理阶段	数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
入站 (接收提示)	应用层提取	Code: 331 Message: Username ok...	见 入站 PDU 格式图最底部	提示解析： PC0 成功读取了服务器的 331 状态码和提示文本，得知用户名有效，随后才在屏幕上弹出密码输入框。
入站 (接收提示)	入站序列号与确认号	Seq: 53 Ack: 37	见 入站 PDU 格式图 TCP 报头	确认这是服务器发来的第 53 字节的数据段，并且服务器已经确认了 PC0 上一步发送的数据（Ack=37）。
入站 (接收提示)	接收数据长度	54 字节	见 入站 OSI 模型图第 2 条说明	证实服务器发来的这句英文提示加上状态码，总共占据了 54 个字节的长度。
---	---	---	---	---
出站 (生成密码包)	应用层动作	FTP客户端将密码发送给FTP服务器	见 出站 OSI 模型图第 1 条说明	状态实证： 证实回车键按下后，FTP 应用层开始执行发送密码的动作。
出站 (生成密码包)	出站序列号 (Seq Num)	37	见 出站 PDU 格式图 TCP 报头	PC0 的序列号顺利迈入 37，完美承接了服务器刚才发来的 Ack=37。
出站 (生成密码包)	出站确认号 (Ack Num)	107	见 出站 PDU 格式图 TCP 报头	极其严密的数学闭环： 确认号从上一次的 53 变成了 107！这是因为 PC0 刚刚收到了服务器 Seq=53 且长度为 54 字节的包（53 + 54 = 107）。客户端以此数字向服务器宣告："你的 54 字节提示我已经一字不落地收到了"。
出站 (生成密码包)	FTP 层命令 (Command)	PASS	见 出站 PDU 格式图最底部	协议标准指令，表明该报文承载的是密码（Password）。
出站 (生成密码包)	FTP 层参数 (Argument)	123456	见 出站 PDU 格式图最底部	全场最佳铁证！ 尽管输入密码时屏幕不显示，但在网络底层的 PDU 封装中，密码 123456 依然以纯明文形式赤裸裸地展现。这直接证明了 FTP 协议存在极其重大的安全隐患。

【阶段分析结论】

在这一阶段，网络通信的可靠性与 FTP 协议的脆弱性形成了鲜明对比。一方面，TCP 传输层极其严密地履行了职责，PC0 通过将出站确认号精确更新为 107，完美确认了对入站 54 字节数据的接收；另一方面，FTP 应用层却将极其敏感的密码（123456）以未经任何加密的明文形式打包进 TCP 载荷中。该带有 PSH 标志的出站报文现已封装完毕，即将发往服务器进行最终的身份核验。

第八步：服务器验证密码并返回登录成功提示（Server0 视角）

在模拟模式下，随着 PC0 发出的密码数据包跨越网络抵达 FTP 服务器（Server0），Server0 节点上触发了本次登录验证的事件。此时实验暂停：服务器刚刚处理完收到的明文密码，并在本地打包生成了准备发回给 PC0 的宣判结果，但该数据包尚未发出。点击 Server0 上的事件包，分别查看其"入站 PDU 详细信息"与"出站 PDU 详细信息"。

【核心数据解剖】

通过对 Server0 在这一瞬间的入站（Inbound）和出站（Outbound）报文进行双向比对分析，核心字段数据及其底层含义如下表所示：

数据处理阶段	数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
入站 (接收密码)	应用层提取	FTP Command: PASS FTP Argument: 123456	见 入站 PDU 格式图最底部	验证触发： 服务器成功从网络底层剥离出纯文本，读取到了客户端提交的明文密码 123456，交由后台验证。
入站 (接收密码)	入站序列号与确认号	Seq: 37 Ack: 107	见 入站 PDU 格式图 TCP 报头	确认这是客户端发来的第 37 字节的数据段，并且客户端已经确认收到了服务器之前的 107 字节数据。
入站 (接收密码)	接收数据长度	34 字节	见 入站 OSI 模型图第 2 条说明	证实本次接收到的包含密码的 TCP 有效载荷长度为 34 字节。
---	---	---	---	---
出站 (宣告成功)	应用层响应代码	Code: 230	见 出站 PDU 格式图最底部 FTP Response	成功标志： FTP 协议的标准状态码 230，正式宣告"用户已登入，可以继续"。
出站 (宣告成功)	应用层响应文本	Message: Logged in	见 出站 PDU 格式图最底部 FTP Response	服务器下发的最终成功提示语，将回显到客户端的屏幕上。
出站 (宣告成功)	出站序列号 (Seq Num)	107	见 出站 PDU 格式图 TCP 报头	服务器的序列号变为 107，完美承接了入站包的 Ack=107。
出站 (宣告成功)	出站确认号 (Ack Num)	71	见 出站 PDU 格式图 TCP 报头	确认号突变成 71！这是因为服务器收到了客户端 Seq=37 且长度为 34 字节的密码包（37 + 34 = 71）。服务器以此宣告："你的密码我一字不落全收到了"。
出站 (宣告成功)	标志位 (TCP Flags)	0b00011000	见 出站 PDU 格式图 TCP 报头	ACK与PSH同时置1。确认密码收妥，并强制推送"登录成功"的喜讯给客户端。

【阶段分析结论】

在这一步骤中，FTP 服务器成功接收了客户端的明文密码并完成了后台身份验证。底层 TCP 传输层继续维持着极其严密的数学逻辑（入站的 Seq 37 加上长度 34，精准推导出了出站包的 Ack 71）。随后，服务器应用层封装了带有 230 Logged in 的成功状态报文。此时，这个承载着"通关文牒"的数据包正静静躺在服务器的网卡缓冲区中，完成了最后的组装，准备进入物理网络发往 PC0。

第九步：客户端接收登录成功报文（PC0 入站视角）

服务器0 发出的响应数据包跨越网络抵达客户端（PC0）。点击 PC0 此时接收到的入站事件包，查看其"入站 PDU 详细信息"，确认客户端最终从网络层、传输层到应用层解析出的具体数据。

【核心数据解剖】

通过对 PC0 此时接收到的这个入站报文进行深度解剖，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
应用层解析状态	Code: 230 Message: Logged in	见 入站 PDU 格式图最底部 FTP Layer	登录成功回显： PC0 的 FTP 软件正式读到了 230 成功代码，随后控制台界面会闪出 230 Logged in，正式将权限移交给用户（显示 ftp> 提示符）。
入站序列号 (Seq Num)	107	见 入站 PDU 格式图 TCP 报头 (SEQUENCE NUMBER)	承接上一步，服务器从第 107 字节开始把"成功喜讯"的数据发了过来。
入站确认号 (Ack Num)	71	见 入站 PDU 格式图 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	服务器发包的同时，再次向 PC0 确认："你之前的密码包（Seq=37，长度34）我确实收全了，目前安全水位在第 71 字节"。
标志位 (TCP Flags)	0b00011000	见 入站 PDU 格式图 TCP 报头 (FLAGS)	倒数第 4 位（PSH）和倒数第 5 位（ACK）依然置 1，确保客户端系统收到后马上把这个成功消息推给控制台回显。
源 IP / 目的 IP	192.168.0.2 / 192.168.0.1	见 入站 PDU 格式图 IP 报头	明确报文由服务器发回，在网络层精准投递给客户端。
源端口 / 目的端口	21 / 1026	见 入站 PDU 格式图 TCP 报头	服务器从 21 端口射出的数据，精准回流到 PC0 的 1026 专属控制窗口中。

【阶段分析结论】

在此步骤中，PC0 成功接收并处理了来自服务器 21 号端口的入站 TCP 报文。随着应用层成功剥离并读取出 Code: 230（Logged in）状态码，FTP 客户端在本地正式确立了"已登录"状态。至此，基于 TCP 21 号端口的 **FTP 控制连接（Control Connection）**身份验证流程在应用层交互上顺利完成，开始进入传输层的最终签收收尾阶段。

第十步：客户端发送纯 ACK 报文确认接收成功消息（PC0 出站视角）

在客户端（PC0）成功解析出 230 Logged in 并在屏幕打印后，观察 Packet Tracer 的事件列表，PC0 节点紧接着自动生成了一个绿色的 TCP 数据包。点击该包查看其"OSI模型"选项卡及"出站PDU详细信息"。可以发现，该报文的封装最高只到第 4 层（传输层），没有应用层数据。

【核心数据解剖】

通过对 PC0 发出的这个收尾出站报文进行分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
报文类型	纯 TCP 确认包	见 OSI 模型图外层封装，止步于第 4 层	通信礼仪： 操作系统底层自动回复的"收据"，不携带任何 FTP 业务数据，仅用于 TCP 连接的可靠性维护。
源端口 / 目的端口	1026 / 21	见 出站 PDU 格式图 TCP 报头	确认信息依然顺着 1026 → 21 的控制通道原路返回。
标志位 (TCP Flags)	0b00010000	见 出站 PDU 格式图 TCP 报头 (FLAGS)	纯确认特征： 只有倒数第 5 位（ACK 确认位）被置为 1。证实这是一个不带推送（无 PSH）、不带同步（无 SYN）的纯粹的确认报文。
出站序列号 (Seq Num)	71	见 出站 PDU 格式图 TCP 报头 (SEQUENCE NUMBER)	PC0 没有新的应用层数据要发送，因此序列号维持在 71（与上次发送完密码后的水位一致）。
出站确认号 (Ack Num)	144	见 出站 PDU 格式图 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	完美闭环的收据： 确认号从上一次的 71 跃升至 144！因为上一步服务器发来的 230 Logged in 报文，其 Seq=107 且载荷长度为 37 字节（107 + 37 = 144）。PC0 用这个 144 向服务器宣告："登录成功的 37 个字节，我已悉数收到，账目结清"。

【阶段分析结论】

在此步骤中，虽然应用层的登录交互已经结束，但传输层（TCP）仍在忠实履行其可靠传输机制。PC0 自动生成了一个纯 ACK 报文，通过精确计算确认号（Ack=144），向服务器反馈了对前序 37 字节控制文本的完整接收。当这个绿色的 TCP 包飞回服务器后，本次"登录认证"阶段的所有数据往来才在底层实现了真正的、彻底的双向闭环结案。

第十一步：服务器接收纯 ACK 报文完成登录闭环（Server0 入站视角）

PC0 发出的纯 TCP 确认包抵达 FTP 服务器（Server0）。点击 Server0 上的该入站事件包，查看其"入站 PDU 详细信息"。此时可以观察到，该报文在服务器端同样止步于第 4 层（传输层），代表服务器成功收到了客户端针对登录成功消息的底层签收回执。

【核心数据解剖】

通过对 Server0 接收到的这个入站纯 ACK 报文进行分析，核心字段数据及其底层含义如下表所示：

数据字段 (Field)	当前抓包真实数据	截图中的位置证据	数据背后的深刻含义
报文层级	纯 TCP 确认包	见 入站 OSI 模型图（最高只到 Layer 4）	收尾签收： 服务器只收到了传输层首部，没有应用层载荷，确认此包为客户端系统自动回传的"收据"。
源 IP / 目的 IP	192.168.0.1 / 192.168.0.2	见 入站 PDU 格式图 IP 报头	源 IP 为客户端 192.168.0.1，目的 IP 为服务器 192.168.0.2。证实该收据由客户端发出，顺利送达服务器。
源端口 / 目的端口	1026 / 21	见 入站 PDU 格式图 TCP 报头	数据精准回流到服务器正在监听的 21 号控制端口。
标志位 (TCP Flags)	0b00010000	见 入站 PDU 格式图 TCP 报头 (FLAGS)	纯确认特征： 只有 ACK 确认位被置为 1。证实服务器收到的确实是一个纯粹的、不带任何业务数据的确认标志。
入站序列号 (Seq Num)	71	见 入站 PDU 格式图 TCP 报头 (SEQUENCE NUMBER)	该数值完美承接了第七步客户端发送密码包后的水位（密码包 Seq=37 + 长度34 = 71）。因为此后客户端没有发送任何新的应用层业务数据，故序列号冻结在 71。
入站确认号 (Ack Num)	144	见 入站 PDU 格式图 TCP 报头 (ACKNOWLEDGEMENT NUMBER)	确认号为 144。服务器核对自身之前的发送记录（Seq=107，包含 230 Logged in 提示信息的载荷长度为 37 字节），107 + 37 = 144，数据完全对齐。说明客户端已经 100% 完好接收了登录成功的宣判。

【阶段分析结论】

在整个登录验证流程的最后一步，FTP 服务器成功接收并解析了来自客户端的纯 TCP ACK 报文。入站确认号（Ack Num）稳定在 144，标志着服务器先前发送的 230 Logged in 业务载荷已获得客户端传输层的显式确认；同时，入站序列号稳定在 71，与服务器自身的期望水位完全一致。至此，FTP 客户端与服务器之间基于 TCP 21 号端口的控制连接登录认证阶段在底层完成了最完美的双向数据闭环。

（3）FTP客户端使用FTP命令dir列出文件的过程

⚠️ 注意： 本节中的 dir 命令抓包源自一次独立的、重新建立的 FTP 会话。因此，读者会注意到控制连接的客户端源端口由上一节的 1026 变为了 1025。在实际连续的同一次 FTP 会话中，该端口在整个生命周期内是保持不变的。

阶段一：控制通道的命令预处理（时间戳 0.000 秒）

【现象描述】 在时间戳 0.000 秒，当用户在 FTP 客户端（PC0）触发 dir 目录查询操作时，客户端系统并没有立刻向服务器索要目录数据，而是首先触发了一个预处理动作。PC0 通过已建立的控制通道，向服务器发送了一条环境配置指令，为接下来的数据交互做准备。

【PDU 数据抓取与原理解析】 通过查看客户端（PC0）出站 PDU 详细信息，我们可以从各个 OSI 协议层提取出以下核心证据并进行原理解析：

• 1. 传输通道分析（OSI 第 4 层 - TCP）

  • 提取数据： TCP 源端口为 1025，目的端口为 21。

  • 原理解释： 目的端口为 21 是非常关键的铁证，说明当前报文是在 FTP 默认的控制连接 上进行传输的。这印证了 dir 命令的初始下发阶段完全依赖于这条"指挥通道"，并没有产生新的连接。

  • 提取数据： TCP 标志位（Flags）为 0b00011000（即同时开启了 PSH 和 ACK 标志），序列号 Seq 为 269，确认号 Ack 为 460。

  • 原理解释： 这里的 ACK 标志和非零的 Seq/Ack 值证明了这绝不是 一个建立连接的握手包，客户端和服务器在之前的登录阶段早就完成了三次握手，连接处于 ESTABLISHED 状态。而 PSH（Push）标志的出现，说明这个报文携带了真实的应用层指令，催促服务器立刻接收并处理。

• 2. 核心指令意图（OSI 第 7 层 - Application）

  • 提取数据： 报文的应用层解析出 FTP Command 为 TYPE，FTP Argument 为 BINARY。

  • 原理解释： 这揭示了该数据包的真实使命。说明客户端在正式请求目录列表（通常是 LIST 命令）之前，必须先规范双方的传输标准。客户端通过发送 TYPE I 命令，要求将后续的网络传输模式设定为二进制（Binary）模式，以确保接下来在数据通道中传输的目录信息不会出现格式解析错误。

• 3. 节点寻址（OSI 第 3 层 - Network）

  • 提取数据： 源 IP 192.168.0.1，目的 IP 192.168.0.2。

  • 原理解释： 明确了本次报文的交互双方，指令正由客户端准确地发往 FTP 服务器。

【本阶段小结】 综上所述，在输入 dir 命令的瞬间（0.000秒），整个过程完全是在复用原有的 21 端口控制连接 。此时并未发生任何新的 TCP 三次握手，一切动作都属于数据传输前的"协商与配置"阶段。

阶段一：控制通道的命令预处理 ------ 服务器响应（时间戳 0.001 秒）

【现象描述】 在时间戳 0.001 秒，FTP 服务器（服务器0）接收到了客户端发来的环境配置请求。服务器的底层 TCP 协议栈对接收到的数据进行了重组和确认，并将其提交给上层的 FTP 应用服务。FTP 服务成功处理该请求后，立刻在服务器内部生成了一个响应报文，准备原路返回给客户端。此时在服务器上可以同时观察到"入站（接收）"和"出站（发送）"两个处理动作。

【PDU 数据抓取与原理解析】

为了清晰说明服务器的处理逻辑，我们将数据分为入站和出站两部分进行剖析：

• 1. 入站方向：接收客户端指令 (Inbound PDU)

  • 提取数据： 目的端口为 21，应用层解析出包含 TYPE BINARY 命令。TCP 报文长度（Data Length）为 34 字节，序列号 Seq 为 269。

  • 原理解释： 这正是客户端在 0.000 秒发出的那个预处理指令包。服务器的 21 端口成功捕获了它，系统提示"FTP服务器接收来自FTP客户端的类型命令"，表明数据已成功送达应用层。

• 2. 出站方向：生成并返回响应 (Outbound PDU)

  • 核心动作提取（OSI 第 7 层 - Application）： 观察出站 PDU 的应用层（FTP Response），可以看到服务器生成了状态码 Code: 200，提示信息为 Message: Command okay.

  • 原理解释： 在 FTP 协议栈中，状态码 200 代表"命令执行成功"。这说明服务器已同意了客户端的请求，正式将接下来的数据传输模式默认设为二进制（Binary）模式。

  • 通道验证提取（OSI 第 4 层 - TCP）： 源端口为 21，目的端口为 1025。

  • 原理解释： 报文从服务器的 21 端口发回客户端的 1025 端口，证明服务端的响应依然在最初建立的控制连接通道中进行。

  • 可靠性机制验证（TCP 序列号与确认号）： 观察出站报文的确认号 Ack 变为了 303。

  • 原理解释： 这是一个非常经典的 TCP 可靠传输证明。服务器收到的入站报文 Seq 是 269，携带了 34 字节的数据载荷（Payload）。根据 TCP 机制，服务器回复的确认号必须是 269 + 34 = 303。这就告诉客户端："你发来的前 303 个字节我都收妥了"。

【本阶段小结】 在 0.001 秒，服务器完成了对客户端 TYPE 命令的确认并返回了 200 成功状态码。截至目前，所有的交互都严格限制在 21 端口的控制通道内，仅用于协商传输参数，真正的目录数据尚未开始请求，数据通道也并未建立。

阶段一：控制通道的命令交互 ------ 协商数据端口（时间戳 0.002 秒）

【现象描述】 在时间戳 0.002 秒，客户端（PC0）首先接收到了服务器上一秒发来的 200 Command okay 响应，确认了二进制传输模式已就绪。紧接着，因为客户端知道即将在 dir 命令中接收大量的目录文本数据，它必须"未雨绸缪"，开始为数据通道的建立做准备。于是，PC0 立即生成了一个全新的报文，向服务器发送 PASV（被动模式）指令，请求服务器开放一个数据端口。

【PDU 数据抓取与原理解析】

同样，我们将此时 PC0 上的动作分为入站和出站两部分剖析：

• 1. 入站方向：接收并确认服务器响应 (Inbound PDU)

  • 提取数据： 报文从服务器的 21 端口发往 PC0 的 1025 端口。应用层携带 Code: 200，Message: Command okay.

  • 原理解释： 这证实了 PC0 成功收到了服务器对 TYPE 命令的许可。PC0 的系统提示"TYPE is supported"，说明底层配置已完成。

  • 可靠性机制验证（加分项）： 此时入站报文的 Seq 为 460，数据长度 Length 为 41 字节。根据 TCP 机制，PC0 接下来回复的确认号（Ack）必须是 460 + 41 = 501。我们将在出站报文中验证这一点。

• 2. 出站方向：发送 PASV 被动模式请求 (Outbound PDU)

  • 核心动作提取（OSI 第 7 层 - Application）： 观察出站 PDU 详情，应用层的 FTP Command 变为了 PASV（无参数）。

  • 原理解释： 这是一个极其关键的 FTP 指令！PASV 全称是 Passive Mode（被动模式）。PC0 通过这个指令告诉服务器："我要看目录了，请你在你那边随机开一个高位端口，然后把端口号告诉我，我主动去连你。" 这标志着 FTP 准备从控制通道向数据通道过渡。

  • 通道验证提取（OSI 第 4 层 - TCP）： 源端口依然是 1025，目的端口依然是 21。

  • 原理解释： 目的端口依然为 21，这证明即使是"协商新端口"的命令，也必须在旧的"控制连接"中进行传达。控制通道的作用就是"指挥部"。

  • TCP 序列号验证： 观察出站报文的 Ack 变为了 501。

  • 原理解释： 这完美印证了前面入站报文的推算（460 + 41 = 501）。TCP 协议精确无误地确认了上一条信息的接收，确保了命令交互的绝对可靠。

【本阶段小结】

在 0.002 秒，客户端正式发出了建立数据通道的请求（PASV）。此时，控制通道（21端口）的任务即将告一段落。

阶段一：控制通道的命令交互 ------ 确认临时数据端口（时间戳 0.003 秒）

【现象描述】 在时间戳 0.003 秒，FTP 服务器接收到了客户端（PC0）发来的 PASV 被动模式请求。服务器同意了该请求，立刻在本地随机监听了一个高位端口（用于后续的数据传输），并生成了一个包含 227 Entering Passive Mode 状态码的响应报文。在这个响应中，服务器将自己刚刚开放的临时端口号通过一种特殊的格式"计算"后，通过控制通道发回给了客户端。

【PDU 数据抓取与原理解析】

按照惯例，我们从入站（接收请求）和出站（发送新端口）两个视角进行剖析：

• 1. 入站方向：接收 PASV 请求 (Inbound PDU)

  • 提取数据： 报文到达服务器的 21 端口，应用层解析出 FTP Command: PASV。

  • 原理解释： 服务器成功捕获了客户端的指令，系统提示"FTP服务器接收来自FTP客户端的被动命令"。这触发了服务器底层开放新端口的动作。

  • 可靠性验证： 入站报文的 Seq 为 303，携带了 28 字节的载荷（Length: 28）。那么出站报文的确认号（Ack）应当是 303 + 28 = 331。

• 2. 出站方向：返回 227 状态码及端口参数 (Outbound PDU) 【核心】

  • TCP 序列号验证（OSI 第 4 层）： 出站报文的 Seq 为 501，Ack 为 331。

  • 原理解释： Ack=331 完美契合了前面的推算，证明底层 TCP 传输可靠无误。

  • 核心动作提取（OSI 第 7 层 - Application）： 观察出站 PDU，应用层的 FTP Response 为 Code: 227 ，Message 为 192,168,0,2,4,8。

  • 原理解释： 这是 FTP 协议设计的经典机制。状态码 227 Entering Passive Mode 意味着服务器已进入被动模式并开放了端口。而后面的 192,168,0,2,4,8 是最为关键的参数：

    • 前四位 192,168,0,2 代表服务器的 IP 地址。

    • 后两位 4 和 8 是端口号的计算因子。

    • 端口计算公式： 临时端口号 = (第5个数字 * 256) + 第6个数字。

    • 代入计算： 本次服务器开放的数据端口为 (4 * 256) + 8 = 1024 + 8 = 1032。

  • 通道验证： 这个至关重要的"端口协商"信息，依然是从服务器的 21 端口发往客户端的 1025 端口，证明控制通道的任务圆满完成。

【本阶段小结】

在 0.003 秒，服务器成功分配了临时数据端口（1032），并通过控制连接将这个新端口号告知了客户端。至此，"盖指挥部"和"规划运输路线"的工作全部结束。

阶段一：控制通道的命令交互 ------ 客户端下达目录请求指令（时间戳 0.004 秒）

【现象描述】 在时间戳 0.004 秒，客户端（PC0）成功接收到了服务器发来的 227 Entering Passive Mode 报文，从中解析出了即将用于数据传输的新端口号。完成了"新端口协商"后，客户端认为前置准备工作全部就绪，于是立即在现有的控制通道中，向服务器正式发送了请求获取目录列表的 LIST 命令。这是 dir 操作的核心指令。

【PDU 数据抓取与原理解析】

我们依然从入站和出站两个视角，深入解析客户端的协议栈动作：

• 1. 入站方向：接收 227 状态码与端口参数 (Inbound PDU)

  • 提取数据： 报文从服务器的 21 端口到达 PC0 的 1025 端口，应用层解析出 Code: 227，Message: 192,168,0,2,4,8。

  • 原理解释： 这证实客户端已准确接收到服务器开放的临时端口信息（计算后为 1032 端口）。PC0 的系统提示"FTP客户端从FTP服务器接收到被动命令的响应。服务器侦听被动端口，等待客户端的连接"，这表明客户端的底层逻辑已经准备好触发下一次的 TCP 连接了。

  • 可靠性验证： 入站报文（上一秒服务器发出的）Seq 为 501，携带了 42 字节的数据载荷。因此，客户端下一步回复的确认号（Ack）应当是 501 + 42 = 543。

• 2. 出站方向：正式发送 LIST 命令 (Outbound PDU)

  • 核心动作提取（OSI 第 7 层 - Application）： 观察出站 PDU，应用层的 FTP Command 变为 LIST ，参数为 /ftp。

  • 原理解释： 这里的 LIST 才是用户在命令行输入 dir 时，底层真正发送的 FTP 指令！它告诉服务器："请把 /ftp 目录下的文件列表发给我。" 注意，这个命令仅仅是"下达需求"，目录的数据并不是在这个包里传回来的。

  • 通道验证提取（OSI 第 4 层 - TCP）： 源端口依然是 1025，目的端口依然是 21。

  • 原理解释： 尽管客户端已经知道了新端口（1032），但 LIST 作为一个"控制指令"，依然必须通过 21 端口的控制通道来发送。这再次印证了控制通道作为"指挥中枢"的地位。

  • TCP 序列号验证： 观察出站报文的 Seq 为 331，Ack 变为了 543。

  • 原理解释： Ack=543 完美契合了前面的推算，说明客户端对服务器刚刚发来的"含新端口号"的报文进行了可靠确认。

【本阶段小结】

在 0.004 秒，客户端完成了最后一步"发号施令"的工作。它通过原有的控制通道（21 端口），正式将"获取目录列表"的 LIST 任务下达给了服务器。

阶段一：控制通道命令交互 ------ 服务器响应目录请求（时间戳 0.005 秒）

【现象描述】 在时间戳 0.005 秒，FTP 服务器（服务器0）成功接收到了客户端发来的 LIST 目录查询指令。服务器的应用服务立刻对其进行解析与响应：首先，底层 TCP 协议栈对该命令的数据进行了确认；随后，FTP 应用层生成了状态码为 125 的响应报文发回客户端。该报文旨在宣告：数据连接已经打开，即将开始传输文件/目录。

【PDU 数据抓取与原理解析】

我们严格依据当前截图的入站与出站 PDU 详情进行深度剖析：

• 1. 入站方向：接收并解析 LIST 指令 (Inbound PDU)

  • 提取数据： 报文到达服务器的 21 端口。TCP 协议栈层明确显示："Received分段信息：序列号（Sequence Number）为 331 ，确认号（Acknowledgment Number）为 543 ，数据长度（Length）为 32 字节"。应用层解析出 FTP Command: LIST。

  • 原理解释： 此时服务器通过 21 端口准确接收到了客户端索要目录的请求（长度为 32 字节）。这触发了服务器开始准备目录数据的内部动作。

  • 可靠性验证： 根据 TCP 确认机制，服务器接下来回复客户端的确认号（Ack）应当为：入站 Seq + Length，即 331 + 32 = 363。我们将立刻在出站报文中验证这一点。

• 2. 出站方向：下发 125 状态码宣告传输开始 (Outbound PDU) 【核心转折点】

  • 核心动作提取（OSI 第 7 层 - Application）： 观察出站 PDU 详情底部的 FTP Response，状态码为 Code: 125 ，提示信息为 Message: Data connection already open; transfer starting.。

  • 原理解释： 状态码 125 是一个关键的转折信号。它告诉客户端："我已经收到你的 LIST 指令了，并且我这边的数据传输环境（即之前协商好的 1032 端口）已经准备就绪，马上就通过该通道把目录发给你。"

  • 通道验证提取（OSI 第 4 层 - TCP）： 源端口为 21，目的端口为 1025。

  • 原理解释： 目的端口是 1025，这证明这条"发令枪"信息仍然是通过原有的控制通道传达的。这也完美符合 FTP 的机制：所有状态通知和命令确认，都必须在控制通道中完成。

  • TCP 确认号验证： 观察出站报文的 TCP 字段，其序列号（Sequence Number）为 543 ，确认号（Acknowledgment Number）赫然显示为 363！

  • 原理解释： 出站 Ack=363 与我们在入站包中的推算（331 + 32 = 363 ）分毫不差，且出站 Seq=543 正好对应了入站的 Ack。这证明服务器完全、可靠地接收到了客户端的 32 字节指令，控制层面的交互在这里实现了完美的闭环。

【本阶段小结】

在 0.005 秒，服务器发出了 125 状态码，这意味着"阶段一：控制通道命令交互"正式安全落幕。至此，所有关于环境配置（TYPE）、端口协商（PASV）和请求下发（LIST）的命令全部复用了最初的连接完成，没有产生任何新的握手。

阶段二：建立数据通道（第二次三次握手） ------ 客户端发起 SYN 请求（时间戳 0.006 秒）

【现象描述】 在时间戳 0.006 秒，客户端（PC0）首先在原有的控制通道上，接收到了服务器上一秒发来的 125 状态码，确认了服务器端的数据端口已经开启并等待连接。没有任何犹豫，PC0 立即在本地动态开辟了一个全新的端口，并向着之前算好的服务器临时端口，发射了第二次 TCP 三次握手的第一发子弹（SYN 报文）。这标志着临时数据通道的正式起建。

【PDU 数据抓取与原理解析】

我们依然从入站和出站两个维度，见证这个激动人心的通道切换过程：

• 1. 入站方向：接收 125 状态宣告 (Inbound PDU - FTP)

  • 提取数据： 报文从服务器的 21 端口到达 PC0 的 1025 端口。TCP 层详情显示：序列号（Seq）为 543 ，确认号（Ack）为 363 ，数据长度为 75 字节。应用层解析出 Code: 125。

  • 原理解释： 客户端成功接收了服务器的"发令枪"。请注意这里的 Seq 和 Ack，它们完美承接了 0.005 秒出站报文的数据。这证明即使到了建立新通道的最后一刻，控制通道依然保持着绝对的可靠与同步。

• 2. 出站方向：发起全新数据通道的三次握手 (Outbound PDU - TCP) 【全场高能】

  • 端口大换血（OSI 第 4 层 - TCP）： 观察出站 PDU，源端口变成了全新的 1028 ，目的端口变成了我们在 0.003 秒推算出来的 1032！

  • 原理解释： 这是 FTP 双通道分离机制的铁证 ！为了不干扰 1025 <-> 21 的控制通道（此时它还在保持连接），PC0 操作系统在本地随机挑选了 1028 这个高位端口，笔直地连向了服务器的 1032 端口。一条名为"数据通道"的专线开始动工。

  • 握手标志位突变（TCP Flags）： PDU 格式图中清晰显示，TCP 标志位（Flags）变为了 0b00000010。

  • 原理解释： 二进制的倒数第二位是 1，代表这是 TCP 的 SYN（同步）标志位 。系统提示设备将连接状态设置为了 SYN_SENT。这证明此时发送的不再是普通的确认包或数据包，而是请求建立全新 TCP 连接的握手包。

  • 序列号清零（Seq & Ack）： 报文的序列号（Sequence Number）为 0 ，确认号（Acknowledgment Number）为 0。

  • 原理解释： 既然是一条由 1028 <-> 1032 构成的新通道，那么双方的数据交互进度自然要"从零开始"。Seq=0 再次印证了这是一次完全独立于控制通道的、全新的 TCP 三次握手起点。

【本阶段小结】 在 0.006 秒，被动模式的理论化为了现实。客户端（1028 端口）正式向服务器（1032 端口）发出了 SYN 握手请求。至此，你的事件列表中出现了第一条属于数据通道的纯 TCP 记录。

阶段二：建立数据通道（第二次三次握手） ------ 服务器返回 SYN+ACK（时间戳 0.007 秒）

【现象描述】 在时间戳 0.007 秒，FTP 服务器（服务器0）刚刚在本地 1032 端口上接收到了来自客户端（PC0，1028 端口）的全新连接请求。服务器同意建立这条专用于传输目录的新通道，于是它将该端口的连接状态更新为 SYN_RECEIVED，并立即生成了一个 SYN+ACK 报文发送回客户端，完成三次握手的第二步。

【PDU 数据抓取与原理解析】

我们依然分为入站（接收客户端的 SYN）和出站（发送服务器的 SYN+ACK）两个视角进行深度剖析：

• 1. 入站方向：接收客户端的建连请求 (Inbound PDU)

  • 端口验证（OSI 第 4 层 - TCP）： 报文从源端口 1028 到达目的端口 1032。

  • 原理解释： 这证实了上一秒（0.006秒）客户端发出的握手包已成功抵达。此时交互完全在临时分配的高位端口间进行，21 端口（控制通道）完全没有参与。

  • 状态与标志位提取： 系统提示提取到序列号（Seq）为 0，确认号（Ack）为 0。底层标志位为 0b00000010（即 SYN 标志位为 1）。

  • 原理解释： 服务器识别出这是一个全新的同步请求。此时服务器的操作系统在底层提取了 MSS（最大分段大小，1460 字节）等参数，并将该 1032 端口的连接状态正式标记为 SYN_RECEIVED（同步收到）。

• 2. 出站方向：服务器回应确认与同步信号 (Outbound PDU)

  • 端口反转（OSI 第 4 层 - TCP）： 源端口变为 1032，目的端口变为 1028。

  • 原理解释： 服务器从自己的临时数据端口发回响应，精准定位客户端开辟的临时端口。

  • 核心标志位突变（TCP Flags）： 观察出站 PDU 格式图，TCP 标志位（Flags）变为了 0b00010010。

  • 原理解释： 二进制的倒数第二位（SYN）和倒数第五位（ACK）同时为 1。这就是大名鼎鼎的 SYN+ACK 报文。它向客户端传达了两层含义：第一，"我同意你的连接请求（SYN）"；第二，"我确认收到了你的信号（ACK）"。

  • 序列号与确认号的推进（Seq & Ack）： 出站报文的序列号（Sequence Number）为 0 ，确认号（Acknowledgment Number）变为了 1。

  • 原理解释：

    • Seq = 0：因为这是服务器在这条新通道上发出的第一个包，所以它自己的起始序列号也是 0。

    • Ack = 1：根据 TCP 机制，确认号是对接收到的有效请求序列号加 1（入站的 SYN 包消耗一个序列号，所以 0 + 1 = 1）。这代表服务器告诉客户端："你的第 0 号请求我收妥了，我期待你接下来发第 1 号数据。"

【本阶段小结】

在 0.007 秒，临时数据通道的"第二次三次握手"已经完成了三分之二。服务器通过 1032 端口成功发出了 SYN+ACK 报文，只等客户端最后回复一个 ACK，这条专门用来运送目录数据的"高速公路"就正式竣工了。

阶段二：建立数据通道（第二次三次握手） ------ 客户端完成最终确认（时间戳 0.008 秒）

【现象描述】 在时间戳 0.008 秒，客户端（PC0）在其临时开辟的 1028 端口上，成功接收到了服务器（1032 端口）发回的握手确认信号。PC0 的操作系统立刻做出响应，将该数据连接的状态正式标记为 ESTABLISHED（已建立），并向服务器发送了最后一次纯粹的确认报文。至此，专用于传输目录列表的临时数据通道彻底打通。

【PDU 数据抓取与原理解析】

我们依然通过入站（接收响应）与出站（发送最终确认）双向视角，来见证这条数据通道竣工的历史性瞬间：

• 1. 入站方向：接收服务器的 SYN+ACK (Inbound PDU)

  • 通道验证（OSI 第 4 层 - TCP）： 报文从服务器的 1032 端口精准送达客户端的 1028 端口。

  • 核心标志位验证： PDU 格式图清晰显示 Flags 为 0b00010010 。这正是包含了 ACK 和 SYN 的双重确认包，完美承接了上一秒（0.007秒）服务器的出站动作。

  • TCP 序列号对齐： 系统提示提取到"Received分段信息：序列号（Seq）为 0 ，确认号（Ack）为 1"。这表明服务器成功确认了客户端的握手请求，并同步了自己的初始序列号。

  • 状态变更（核心动作）： 底层提示文字明确指出："TCP连接成功。设备将连接状态设置为ESTABLISHED。" 这意味着在客户端的视角里，这条高速公路已经正式通车。

• 2. 出站方向：发出三次握手的最后一击 (Outbound PDU)

  • 动作提取： 客户端立刻生成了一个从 1028 端口发往 1032 端口的报文。

  • 核心标志位突变（TCP Flags）： 观察出站 PDU，TCP 标志位变为了 0b00010000。

  • 原理解释： 这里的二进制只有倒数第五位是 1，即这是一个纯 ACK 报文。客户端用它来告诉服务器："好的，你的同意信号我也收到了。"

  • 序列号与确认号的完美闭环（Seq & Ack）： 出站报文的序列号（Sequence Number）变为了 1 ，确认号（Acknowledgment Number）也变为了 1。

  • 原理解释：

    • Seq = 1：因为客户端发出的第一个 SYN 包消耗了序列号 0，所以现在轮到发送第 1 号数据了。

    • Ack = 1：客户端收到了服务器 Seq=0 的 SYN 包（SYN 也会消耗一个序列号），因此回复 0 + 1 = 1，表示"我期待你接下来发第 1 号数据"。

    • 数据完全契合了截图提示："Sent分段信息：序列号 1，确认号 1"。

【本阶段小结与全阶段总结】

在 0.008 秒，伴随着最后一个 ACK 报文的发出，"阶段二：数据通道建立"宣告完美结束。 这条由客户端 1028 端口连向服务器 1032 端口的全新 TCP 连接，经历了 SYN → SYN+ACK → ACK 经典的三个步骤，现在已经处于随时可以全速传输数据的状态。

阶段三：目录数据传输 ------ 服务器正式发送目录列表（时间戳 0.009 秒）

【现象描述】 在时间戳 0.009 秒，FTP 服务器（服务器0）在其数据端口（1032）上接收到了客户端发来的最后一次握手确认包（ACK），服务器立刻将该连接的状态标记为 ESTABLISHED（已建立），宣告数据通道彻底竣工。毫无延迟地，服务器立刻将早已准备好的 /ftp 目录内容打包，沿着这条刚刚建好的专线，向客户端发送了真实的目录数据载荷。

【PDU 数据抓取与原理解析】

我们依然通过入站（确认建连）与出站（发送数据）的双向视角，见证这历史性的一刻：

• 1. 入站方向：接收最终确认，通道竣工 (Inbound PDU)

  • 通道与状态验证： 报文从客户端的 1028 端口到达服务器的 1032 端口。底层事件明确提示："TCP连接成功。设备将连接状态设置为ESTABLISHED。"

  • 原理解释： 这意味着服务器端的三次握手流程正式闭环，双方可以开始安全地传输数据了。

  • TCP 参数核对： 抓包显示标志位 Flags 为 0b00010000 （纯 ACK 报文），序列号（Seq）为 1 ，确认号（Ack）为 1。

  • 原理解释： 这完美对应了我们在 0.008 秒推演的客户端出站数据。服务器收妥了这个确认包，握手阶段的序列号消耗到此为止。

• 2. 出站方向：倾泻真实的目录数据 (Outbound PDU) 【全场最高潮】

  • 通道锁定（OSI 第 4 层 - TCP）： 报文从服务器的 1032 端口发往客户端的 1028 端口。请注意，这里完全没有 21 端口的影子，数据传输被完美隔离在临时通道中。

  • 核心数据载荷提取： 观察出站 PDU 的 OSI 模型详情，赫然写着："Sent分段信息：序列号 1，确认号 1，以及数据长度 556 。" 并且在 PDU 格式图的最下方，出现了一个 Variable Size PDU（可变大小协议数据单元） ，里面装满了 DATA。

  • 原理解释： 这 556 字节的数据，正是你在客户端敲下 dir 命令后，真正想要获取的目录列表文本信息 ！由于通道刚刚建立，服务器的发送序列号依然是 1，它迫不及待地将这 556 字节的"真金白银"推向了客户端。

  • 标志位验证： 此时的 Flags 依然是 0b00010000 （ACK）。因为数据通道中除了建立和断开连接时需要特殊的 SYN 和 FIN 标志外，正常传输数据时，每一发数据包都会默认带上 ACK 以维持连接的可靠性。

【本阶段小结】 在 0.009 秒，纸上谈兵的协议协商终于转化为了实质性的数据流动。服务器通过专用的 1032 -> 1028 数据通道，将 556 字节的目录信息发送给了客户端。

阶段三：目录数据传输 ------ 客户端接收目录载荷（时间戳 0.010 秒）

【现象描述】 在时间戳 0.010 秒，客户端（PC0）在其专用的临时数据端口（1028）上，成功接收到了来自服务器（1032 端口）的数据报文。这份报文正是用户敲下 dir 命令后所期盼的最终结果------目录列表的文本信息。PC0 的底层 TCP 协议栈接收到这批数据后，开始将其存入缓冲区，准备重组后提交给上层的 FTP 客户端软件进行界面显示。

【PDU 数据抓取与原理解析】

由于这是一个单纯的接收动作，我们重点剖析其入站（Inbound PDU）的详细参数：

• 1. 通道验证（OSI 第 4 层 - TCP）

  • 提取数据： 源端口为 1032（服务器），目的端口为 1028（客户端）。

  • 原理解释： 再次确认这批数据是严格走在刚刚建好的临时"数据通道"上的，与 21 端口的控制通道互不干扰。

• 2. 核心载荷与序列号验证（关键核对）

  • 提取数据： PDU 详情清晰显示："Received分段信息：序列号（Seq）为 1 ，确认号（Ack）为 1 ，以及数据长度 556 "。在 PDU 格式图底部，也显示了包含数据的 Variable Size PDU。

  • 原理解释： 这里的参数与 0.009 秒服务器的出站参数完全一致 ！这证明那 556 字节的目录数据在传输过程中没有任何丢失或篡改，被 PC0 照单全收。

• 3. 标志位与底层处理动作

  • 提取数据： TCP 标志位（Flags）为 0b00010000 （即 ACK 标志）。系统提示动作："TCP存储有效载荷数据，用于进一步重组来自传入分段的数据。"

  • 原理解释： 在网络传输中，应用层的数据（如这 556 字节的文本）是被包裹在 TCP 数据段里的。PC0 的操作系统收到后，需要把外层的 TCP 包装拆掉，把里面的纯数据存进内存缓冲区（重组），然后"端"给正在等待的 FTP 软件，最终以黑底白字的形式打印在你的命令行窗口上。

【本阶段小结】 在 0.010 秒，真正有价值的"货物"（556字节的目录数据）已经安全运达目的地并入库。dir 命令的核心诉求至此已经实现。

阶段三：目录数据传输 ------ 服务器连续发送数据分段（时间戳 0.012 秒）

【现象描述】 在时间戳 0.012 秒，FTP 服务器（服务器0）在没有收到客户端对上一批数据确认的情况下，主动且连续地向客户端再次发送了第二批目录数据。这是因为总的目录文本较大（超过了单个包的承载或系统设定的分段大小），而服务器判断客户端的"接收窗口"依然充裕，因此利用 TCP 滑动窗口机制，实现了数据的连续高速发送，无需死板地等待"发一个、等一个确认"。

【PDU 数据抓取与原理解析】

这是一个纯粹的出站动作（服务器主动发送），我们紧盯它的出站（Outbound PDU）参数：

• 1. 通道验证（OSI 第 4 层 - TCP）

  • 提取数据： 源端口依然是 1032，目的端口依然是 1028。

  • 原理解释： 证明数据仍在我们的专属数据通道中传输。

• 2. 序列号的完美衔接（高能核对）

  • 提取数据： 观察出站 PDU 详情，明确显示："Sent分段信息：序列号（Seq）为 557 ，确认号（Ack）为 1，以及数据长度 556"。

  • 原理解释： 这个 Seq=557 简直是完美的教科书级数据！我们在 0.009 秒看到，服务器发的第一个数据包起始序列号是 1，长度是 556。那么这第一块数据占据了通道中的 1 到 556 号位置。紧接着发送的第二块数据，理所当然必须从第 557 号字节开始！ （即 1 + 556 = 557）。数据在这里实现了严丝合缝的拼接。

• 3. 确认号与滑动窗口机制揭秘

  • 提取数据： 确认号（Ack）依然为 1。底层状态提示："总的未确认数据仍然小于可用窗口大小(15272 字节)。TCP将继续发送另一个分段。"

  • 原理解释： 为什么 Ack 还是 1？因为此时时间间隔太短（才过去 2 毫秒），服务器还没有收到 PC0 发来的关于第一块数据的 ACK 确认包。

  • TCP 的聪明之处： 如果按死板的逻辑，服务器应该停下来死等确认。但是 TCP 协议栈发现，客户端的"可用窗口"（还能接收的数据量）高达 15272 字节，完全吃得下更多数据。所以服务器不等了，直接把下个 556 字节的"货"也发了出去。这就是极大地提升了网络传输速率的滑动窗口机制。

• 4. 标志位验证

  • 提取数据： TCP 标志位（Flags）依然为 0b00010000 （纯 ACK）。

  • 原理解释： 正常的数据传输包，默认携带 ACK 标志位，属于标准动作。

【本阶段小结】

在 0.012 秒，服务器运用 TCP 滑动窗口机制，在数据通道（1032 -> 1028）中连续发出了第二批 556 字节的目录数据。整个过程不仅序列号衔接完美无瑕，更展现了底层协议追求高效传输的真实逻辑。

阶段三：目录数据传输 ------ 客户端接收第二批数据分段（时间戳 0.013 秒）

【现象描述】 在时间戳 0.013 秒，客户端（PC0）的数据接收端口（1028）成功捕获了服务器发来的第二块目录数据载荷。PC0 的底层 TCP 协议栈对接收到的序列号进行了严格校验，确认这正是它所期待的下一批数据。随后，系统将这 556 字节的内容存入内部缓冲区，准备与之前收到的第一批数据进行拼接重组。

【PDU 数据抓取与原理解析】

由于这是一个纯接收动作，我们重点剖析其 入站（Inbound PDU） 的详细参数，来见证数据的完美对接：

• 1. 通道验证（OSI 第 4 层 - TCP）

  • 提取数据： 源端口为 1032，目的端口为 1028。

  • 原理解释： 毫无疑问，数据依然平稳地跑在我们专属的临时数据通道上。

• 2. 序列号校验与数据重组（核心核对）

  • 提取数据： PDU 详情清晰显示："Received分段信息：序列号 557 ，确认号 1，以及数据长度 556"。

  • 原理解释： 这里的 Seq=557 和 Length=556 与上一秒服务器的出站数据完全一致！底层事件提示"该TCP分段具有预期的对端序列号"，这句话含金量极高。因为 PC0 在 0.010 秒接收了第 1 到 556 号字节，所以它的 TCP 协议栈"期待"收到的下一个字节刚好就是第 557 号。数据在这里实现了完美的无缝衔接。

  • 动作提取： "TCP存储有效载荷数据，用于进一步重组来自传入分段的数据。"

  • 原理解释： TCP 是一个面向字节流的协议。对于上层的 FTP 软件来说，它不需要知道数据被切成了几个 556 字节的块。底层的 PC0 操作系统会默默地把这些块按序列号（1, 557...）在内存里重新拼好（重组），最后一次性交给应用层。

• 3. 标志位验证

  • 提取数据： 观察 PDU 格式图，TCP 标志位（Flags）依然为 0b00010000 （纯 ACK 标志）。

  • 原理解释： 这证实了这是一个纯粹的数据传输包，连接状态依然稳定。

【本阶段小结】 在 0.013 秒，客户端成功接收并校验了第二批 556 字节的目录数据。得益于 TCP 严格的序列号机制，这批数据被精准地存入缓冲区，等待拼接。

阶段三：目录数据传输 ------ 服务器连续发送第三批数据分段（时间戳 0.017 秒）

【现象描述】 在时间戳 0.017 秒，FTP 服务器（服务器0）依然处于 ESTABLISHED（已建立）状态。由于 /ftp 目录的文本内容较大，前面发出的两批数据（共 1112 字节）未能传完整个列表。此时，服务器继续利用 TCP 的滑动窗口机制，在尚未收到客户端任何数据确认包的情况下，马不停蹄地向客户端发送了第三批目录数据。

【PDU 数据抓取与原理解析】

这是一个纯粹的服务器出站动作（连续发送），我们紧盯它的 出站（Outbound PDU） 真实参数：

• 1. 核心标志位纠错（TCP Flags）

  • 提取数据： 观察 PDU 格式图，TCP 标志位（Flags）确凿无疑是 0b00010000。

  • 原理解释： 这是一个纯 ACK 报文，绝对没有任何 FIN（断开连接）的意思。数据通道依然保持全速畅通，服务器还在埋头干活。

• 2. 序列号的严密推进（高能核对）

  • 提取数据： PDU 详情显示："Sent分段信息：序列号（Seq）为 1113 ，确认号（Ack）为 1，以及数据长度 556"。

  • 原理解释： 这个 Seq=1113 的出现，完美证明了数据的连续性。

    • 第一块数据：Seq=1，Length=556 （占据 1~556 字节）

    • 第二块数据（0.012秒）：Seq=557，Length=556 （占据 557~1112 字节）

    • 第三块数据（0.017秒当前）： 起始序列号必然是 1112 + 1 = 1113！服务器再次装载了 556 字节的数据发了出去。

• 3. 确认号与滑动窗口的持续运作

  • 提取数据： 确认号（Ack）依然为 1 。底层提示明确指出："总的未确认数据仍然小于可用窗口大小(14716 字节)。TCP将继续发送另一个分段。"

  • 原理解释： 服务器目前已经连续发出去了三块数据（共 1668 字节），但依然没有收到 PC0 的确认收条（所以 Ack 还是 1，表示没收到客户端的新动静）。由于客户端报出的接收窗口（Window Size）还有 14716 字节的巨大余量，服务器的 TCP 判定"继续发没问题，对方吃得消"，于是毫不犹豫地把第三块数据也推向了网络。

【本阶段小结】

在 0.017 秒，根本没有发生任何断开连接的动作。相反，服务器在 1032 -> 1028 的数据通道上，高效地推送了第三批 556 字节的目录数据。整个通信过程正处于高吞吐量的数据连续传输高潮期。

阶段三：目录数据传输 ------ 客户端接收第三批数据并进行累积确认（时间戳 0.018 秒）

【现象描述】 在时间戳 0.018 秒，客户端（PC0）的数据端口（1028）成功接收到了服务器发来的第三批目录数据。PC0 的 TCP 协议栈在接收并存储了这 556 字节的数据后，立刻生成了一个确认包（ACK）发回服务器。这个确认包是对之前所有未确认数据（前三批，共计 1668 字节）的一次性总清算。

【PDU 数据抓取与原理解析】 我们依然分为入站（接收数据）和出站（发送ACK）两个动作进行深度剖析：

• 1. 入站方向：接收第三批数据 (Inbound PDU)

  • 核心标志位与载荷验证： 观察入站 PDU，TCP 标志位（Flags）为 0b00010000（纯 ACK，没有任何 FIN 标志）。同时，详情提示："Received分段信息：序列号 1113，确认号 1，以及数据长度 556"。

  • 原理解释： 这完美对应了 0.017 秒服务器发出的那一批数据，数据流稳定传输。

• 2. 出站方向：客户端的"累积确认"神操作 (Outbound PDU)

  • 动作提取： PC0 收到包后，立刻向服务器的 1032 端口发送了一个标志位为 0b00010000 的纯 ACK 报文。

  • 序列号与极其关键的确认号（Ack）： 出站详情显示："Sent分段信息：序列号 1，确认号 1669"。

  • 原理解释： 为什么确认号突然变成了 1669？这正是 TCP 的累积确认机制！服务器连续发了三批数据（556 + 556 + 556 = 1668）。PC0 之前一直没吭声，现在它直接回复 Ack=1669，这一句话就相当于告诉服务器："你刚才连续发给我的那三批共 1668 字节的数据，我一滴不漏地全收到了！"

【本阶段小结】 在 0.018 秒，客户端成功接收了第三块目录拼图，并通过一个极其高效的 Ack=1669 报文，一次性清算了前期的所有接收账单，促使服务器清理底层缓存以继续发送后续数据。

阶段三：目录数据传输 ------ 服务器清理缓冲区并发送第四批数据（时间戳 0.019 秒）

【现象描述】 在时间戳 0.019 秒，FTP 服务器（服务器0）在其数据端口（1032）上，成功接收到了客户端（PC0）发来的累积确认包。服务器确认客户端已经安全收到了前三批数据后，立刻在底层执行了一个极其关键的动作：清空已确认数据的内存缓冲区 。紧接着，因为目录还没传完，服务器马不停蹄地组装了第四批目录数据，继续沿着数据通道发送给客户端。

【PDU 数据抓取与原理解析】

我们将分别从入站（接收确认与清理内存）和出站（发送第四批数据）两个视角，见证 TCP 协议的严谨运作：

• 1. 入站方向：接收累积确认，释放内存 (Inbound PDU)

  • 通道与标志位验证： 报文从客户端的 1028 端口到达服务器的 1032 端口。PDU 格式图清晰显示，TCP 标志位（Flags）为 0b00010000 ，这是一个纯 ACK 确认报文。

  • 核心序列号提取： 详情明确指出："Received分段信息：序列号 1，确认号 1669"。

  • 原理解释（高光时刻）： 这里的 Ack=1669 准确无误地传达了客户端的进度（前 1668 字节已全部收妥）。系统底层随之触发了一条极具技术含量的动作："该TCP分段具有期望的确认号。该设备从缓冲区中弹出最后一个发送的分段。"

  • 深度剖析： TCP 是保证可靠传输的。服务器在发送数据后，并不会立刻删除这些数据，而是将它们保存在"发送缓冲区"里，以防网络丢包需要重传。直到此刻，服务器收到了 Ack=1669 的"收条"，它才真正放心，将这 1668 字节的数据从宝贵的内存中"弹出"（清理掉）。这展示了 TCP 完美的内存调度机制。

• 2. 出站方向：无缝衔接，第四次发车 (Outbound PDU)

  • 核心载荷与序列号提取： 观察出站 PDU 详情，赫然写着："Sent分段信息：序列号（Seq）为 1669 ，确认号（Ack）为 1，以及数据长度 556"。

  • 原理解释： 既然客户端要求从 1669 号字节开始发，服务器就精准地从 Seq=1669 开始，再次打包了 556 字节的数据推送出去。数据的拼接在这里严丝合缝（第 1669 到 2224 字节）。

  • 标志位验证： 观察 PDU 格式图，TCP 标志位依然是 0b00010000 （纯 ACK 标志），没有任何断开连接的迹象。同时，底部的 Variable Size PDU 证明这 556 字节是实打实的真实目录载荷。

  • 窗口机制继续运作： 提示文字显示："总的未确认数据仍然小于可用窗口大小(14160 字节)。TCP将继续发送另一个分段。"说明通道极其通畅，甚至后续可能还有第五批、第六批数据。

【本阶段小结】 在 0.019 秒，服务器的 TCP 协议栈展现了教科书级别的操作：它通过处理 Ack=1669 的确认包，安全释放了前期的内存缓存；同时毫不减速地发出了带有 556 字节载荷的第四批目录数据。

阶段三：目录数据传输 ------ 客户端接收第四批数据分段（时间戳 0.020 秒）

【现象描述】 在时间戳 0.020 秒，客户端（PC0）在临时数据端口（1028）上，成功捕获了服务器发来的第四批目录数据。PC0 的底层 TCP 协议栈对报文进行了严格的拆包与序列号校验，确认无误后，将这新到达的 556 字节有效载荷（Payload）存入内存缓冲区，准备与之前已经收妥的 1668 字节数据进行最终的拼接重组。

【PDU 数据抓取与原理解析】

这是一个纯接收动作，我们聚焦于客户端的 入站（Inbound PDU） 详情进行深度剖析：

• 1. 通道验证（OSI 第 4 层 - TCP）

  • 提取数据： 源端口为 1032（服务器），目的端口为 1028（客户端）。

  • 原理解释： 数据依然在临时"高速公路"上稳定狂奔。

• 2. 序列号的精准咬合（高能核对）

  • 提取数据： PDU 详情清晰显示："Received分段信息：序列号（Seq）为 1669 ，确认号（Ack）为 1，以及数据长度 556"。

  • 原理解释： 这里的参数与 0.019 秒服务器的出站参数分毫不差 ！更关键的是系统给出的第 3 条提示："该TCP分段具有预期的对端序列号。"

  • 深度剖析： 在 0.018 秒，PC0 发送了 Ack=1669 的确认包，意思就是"我期待你发第 1669 号字节给我"。现在，带有 Seq=1669 的数据包真的如约而至。这证明了即使面对大体积的目录文本，TCP 协议依然能保证数据字节流的绝对有序，绝不乱序。

• 3. 数据重组动作提取

  • 提取数据： "TCP存储有效载荷数据，用于进一步重组来自传入分段的数据。"

  • 原理解释： 此时 PC0 的内存缓冲区里，已经按顺序摆放好了四块数据：

    • 第 1 块：1 ~ 556

    • 第 2 块：557 ~ 1112

    • 第 3 块：1113 ~ 1668

    • 第 4 块（刚刚存入）：1669 ~ 2224 底层的操作系统正在像拼图一样，把这些数据拼成一个完整的 /ftp 目录列表字符串。

• 4. 标志位验证

  • 提取数据： 观察 PDU 格式图，TCP 标志位（Flags）依然为 0b00010000 （纯 ACK 标志）。

  • 原理解释： 报文中依然没有出现 FIN 标志，说明传输状态依然是普通的进行时。

【本阶段小结】 在 0.020 秒，客户端成功接收了第四批 556 字节的数据。截至目前，客户端已经累计安全接收了 2224 字节 的目录文本内容。

插曲：控制通道的后台同步 ------ 客户端确认 125 状态码（时间戳 0.021 秒）

【现象描述】 在时间戳 0.021 秒，正当临时数据通道（1028 <-> 1032）打得火热、连续传输大体积目录内容时，客户端（PC0）操作系统的网络底层并没有忘记它在控制通道 上还有一笔"旧账"没清。于是，PC0 在其最初建立的 1025 端口上，悄悄向服务器的 21 端口发送了一个纯 TCP 确认包（ACK）。这个包并非用于目录数据的确认，而是为了确认它在十多毫秒前收到的那个宣告数据连接开启的 125 FTP 状态码。

【PDU 数据抓取与原理解析】

这是一个纯出站的确认动作（Outbound PDU），我们重点剖析它如何与十几毫秒前的数据产生完美闭环：

• 1. 视角切换 ------ 端口大转移（核心验证）

  • 提取数据： 观察出站 PDU 详情，源端口变成了 1025 ，目的端口变成了 21。

  • 原理解释： 这是一个极其关键的信号！它证明当前动作已经跳出了临时数据通道 ，回到了我们"阶段一"使用的指挥部------控制通道。这生动地展示了 FTP 双端口机制的独立性：两条通道各自维护自己的连接状态，互不干扰。

• 2. 跨越时空的序列号闭环（高能核算）

  • 提取数据： PDU 详情显示："Sent分段信息：序列号（Seq）为 363 ，确认号（Ack）为 618"。

  • 原理解释（解密 618 的来源）：

    • 我们把时间拨回 0.005 和 0.006 秒，当时服务器在控制通道上发出了 Code: 125（提示数据连接已打开）。

    • 我们复查那时的抓包记录（你可以翻看当时的截图），服务器那个 125 报文的 Seq 是 543，数据长度（Length）是 75 字节。

    • 按照 TCP 确认规则，客户端对那个包的确认号应该是：543 + 75 = 618！

    • 没错！PC0 此时发出的 Ack=618，正是在告诉服务器："你刚才那个长达 75 字节的 125 状态通报，我已经妥善处理完了！"

    • 而 Seq=363 也是完全继承了控制通道挂起前 PC0 的最后一个序列号。

• 3. 标志位验证

  • 提取数据： TCP 标志位（Flags）为 0b00010000 （纯 ACK）。

  • 原理解释： 这仅仅是一个系统底层的接收确认包，应用层没有任何新的指令下发。

【本阶段小结】

在 0.021 秒，我们观察到了网络通信中真实的"并发处理"现象。PC0 趁着处理数据通道（1028端口）接收缓冲区的间隙，在控制通道（1025端口）上把之前积压的 125 状态确认包发送给了服务器，完成了控制层面的后台同步。

插曲终章：控制通道的后台同步 ------ 服务器接收确认并释放内存（时间戳 0.022 秒）

【现象描述】 在时间戳 0.022 秒，FTP 服务器（服务器0）的控制通道（21 端口）成功接收到了客户端发来的状态确认包。服务器底层的 TCP 协议栈在核对了确认号之后，确认客户端已经安全收到了关于"数据连接已打开（Code: 125）"的通知。于是，服务器在控制通道上也执行了"内存清理"动作，将这段旧的状态信息从发送缓冲区中彻底抹除。

【PDU 数据抓取与原理解析】

这是一个纯粹的入站接收动作（Inbound PDU），我们紧盯服务器端的底层处理逻辑，验证数据的完美对接：

• 1. 通道与端口的精准对接（OSI 第 4 层 - TCP）

  • 提取数据： 报文从源端口 1025（客户端）精准送达目的端口 21（服务器）。

  • 原理解释： 再次印证这是属于控制通道的通信流，与正在海量传文件的数据通道（1032 端口）完全平行、互不干扰。

• 2. 序列号的跨时空吻合（高能核对）

  • 提取数据： PDU 详情显示："Received分段信息：序列号（Seq）为 363 ，确认号（Ack）为 618"。

  • 原理解释： 这里的参数与 0.021 秒 PC0 的出站数据分毫不差！这证明确认报文在传输过程中安然无恙。

• 3. 服务器底层的"拔刀收鞘"动作（核心机制）

  • 提取数据： 系统提示文字第 3 和第 4 条写道："该TCP分段具有预期的对端序列号。该TCP分段具有期望的确认号。该设备从缓冲区中弹出最后一个发送的分段。"

  • 原理解释： 这句话含金量极高！服务器一直在等客户端确认那个长达 75 字节的 125 状态码。现在 Ack=618 终于到了，TCP 协议栈的可靠性机制达成闭环，服务器非常果断地将这 75 字节从控制通道的内存缓存中"弹出"（清理销毁），释放了系统资源。

  • 细节辟谣： 注意看提示文字里写着"数据长度 20"，但这其实是思科模拟器文字描述的一个常见 Bug（它把 20 字节的 TCP 报头长度当成了数据长度）。我们点开第三张图（PDU格式图）看真相：IP 报头的 TL（总长度）是 40。减去 IP 报头 20 字节和 TCP 报头 20 字节，真正的数据载荷（Payload）是 0 。这确确实实就是一个没有携带任何应用层指令的纯 ACK 包。

【本阶段小结】 在 0.022 秒，关于 125 状态码的最后一点尾巴终于被清理干净了。控制通道（21 端口）的任务彻底交代完毕，再次进入安静的休眠挂起状态。

阶段三：目录数据传输 ------ 服务器发送第五批（带有 PSH 标志）数据（时间戳 0.024 秒）

【现象描述】 在时间戳 0.024 秒，数据通道的传输根本没有结束！ 服务器0（1032 端口）继续向客户端（1028 端口）发送了第五批 目录数据。由于这是整个 /ftp 目录列表的最后一块数据碎片，服务器在底层的 TCP 报文中打上了 PSH（推）标志位，催促客户端收到后立刻将拼接好的完整目录提交给 FTP 软件显示。

【PDU 数据抓取与原理解析】

这是一个纯粹的数据通道出站动作（Outbound PDU），我们来看它极其硬核的参数细节：

• 1. 通道验证（打脸我刚才错误的铁证）

  • 提取数据： 观察第二张图的 OSI 模型第 4 层，源端口依然是 1032 ，目的端口依然是 1028！

  • 原理解释： 这铁证如山地表明，我们根本没有回到控制通道，依然在临时"数据高速公路"上狂奔。目录数据还在传！

• 2. 序列号的终极咬合（高能核对）

  • 提取数据： 详情提示显示："Sent分段信息：序列号（Seq）为 2225 ，确认号（Ack）为 1，以及数据长度 257"。

  • 原理解释： 这个 Seq=2225 简直太美妙了！

    • 我们回顾一下：第 4 批数据是 Seq=1669，长度 556。那么它占据的字节编号就是 1669 到 2224。

    • 紧接着的这第 5 批数据，毫无悬念地从 2225 号字节开始！数据流的拼接没有哪怕一个字节的差错。

    • 这一次的长度变成了 257 字节，说明剩下的目录文本只有这么多了（没有达到 556 的满载额度）。

• 3. 核心标志位突变 ------ PSH 登场（关键预告）

  • 提取数据： 观察 PDU 格式图，TCP 标志位（Flags）变为了 0b00011000 （即 PSH+ACK）。

  • 原理解释： 倒数第四位的 PSH（Push / 推送） 标志位被置为了 1。在 TCP 传输大文件时，前面的数据块通常只有 ACK，让接收方先存在内存里；当发送方发出最后一块数据时，通常会加上 PSH 标志。意思是："这是最后一点货了，别在缓冲区里攒着了，赶紧把前面收到的 2224 字节和这 257 字节拼起来，推给上面的 FTP 软件吧！"

【本阶段小结】

在 0.024 秒，服务器在数据通道上发出了第五批（257 字节）数据，并且通过 PSH 标志位暗示这可能是最后一批有效载荷了。截至目前，这个庞大的 /ftp 目录总共传输了 2224 + 257 = 2481 字节的数据！

阶段三终章：目录数据传输 ------ 客户端接收完结并重组（时间戳 0.025 秒 / 入站）

【现象描述】 在时间戳 0.025 秒的第一个动作中，客户端（PC0）的 1028 端口收到了服务器发来的第五批、也是最后一批数据。PC0 的 TCP 协议栈识别出了 PSH（推送）标志，立刻将内存缓冲区里的所有 5 批数据拼接到一起，还原成完整的目录文本，并将其向上层（FTP 应用客户端）提交。

【入站 PDU 数据核对】

• 1. 序列号的最后对齐：

  • 提取数据： "Received分段信息：序列号（Seq）为 2225 ，确认号（Ack）为 1，以及数据长度 257"。

  • 原理解释： 这与上一秒服务器的出站数据完全一致。最后 257 个字节平安送达。

• 2. PSH 标志与重组机制（全场最高光）：

  • 提取数据： "该设备在连接到...接收到一个TCP PUSH+ACK 分段。" 最关键的是第 6 条提示："TCP重新组合所有数据段并将其传递给上层。"

  • 原理解释： 这是一个极其完美的底层运作展示。TCP 把之前收到的 (1~556)、(557~1112)、(1113~1668)、(1669~2224) 以及刚刚收到的 (2225~2481) 像串珍珠一样完整地串在了一起。这 2481 字节 就是你在命令行敲下 dir 后屏幕上打印出的所有字符！

阶段四：数据通道拆除（四次挥手第 1 步） ------ 客户端主动发送 FIN 请求（时间戳 0.025 秒 / 出站）

【现象描述】

数据既然已经完整地交给了上层应用，这条临时建立的 1028 <-> 1032 数据通道就彻底失去了利用价值。PC0 的操作系统毫不拖泥带水，立刻决定销毁通道。它主动将连接状态变更为 FIN_WAIT_1，并向服务器发射了带有 FIN 标志的挥手报文。

【出站 PDU 数据核对】

• 1. 核心标志位突变 ------ FIN 信号登场：

  • 提取数据： 观察出站 PDU 格式图，TCP 标志位（Flags）变为了 0b00010001 （即 FIN+ACK ）。同时底层提示："设备关闭在端口1032上到192.168.0.2的TCP连接。"并且"设备将连接状态设置为 FIN_WAIT_1"。

  • 原理解释： PC0 正式发起了 TCP 四次挥手的第一步，告诉服务器："我的货收完了，我要关门了。"

• 2. 终极累积确认号（极其硬核的核对）：

  • 提取数据： 出站详情显示："Sent分段信息：序列号 1，确认号 2482"。

  • 原理解释： 为什么 Ack 是 2482？这简直是强迫症的福音！

    • 刚刚收到的最后一块数据起始 Seq 是 2225，长度是 257。

    • 那么 PC0 期待的下一个字节编号就是 2225 + 257 = 2482

    • 通过这一个数字 Ack=2482，PC0 向服务器做出了最终宣告："你发出的整整 2481 字节的目录数据，我一个字节都没漏，全收到了！"

【本阶段小结】

在 0.025 秒，PC0 完美谢幕了接收任务，并以一个清算总账的 Ack=2482 配合 FIN 标志，正式按下了数据通道自毁的按钮。

阶段四：数据通道拆除（四次挥手第 2、3 步合并） ------ 服务器发送 FIN+ACK（时间戳 0.026 秒）

【现象描述】 在时间戳 0.026 秒，服务器0 的 1032 端口接收到了客户端发来的断开连接请求（FIN）。服务器不仅立刻确认了该请求，并且由于自身也没有目录数据需要发送了，它高效地将"确认断开（ACK）"与 "主动断开（FIN）"合并为一个报文。 注：在模拟器的事件列表中，此时会出现两个连续的事件。第一个事件包含了底层的接收与生成响应的完整 PDU 逻辑；第二个事件为数据包进入物理链路的传输动画（此时点击会提示"正在传输中，无 PDU 信息"）。

【PDU 数据抓取与原理解析】

我们打开第一个有效事件的 PDU，从入站和出站两个标签页剖析核心数据：

• 1. 入站方向（Inbound PDU）：接收 FIN 请求并清空缓存

  • 提取数据： 报文到达 1032 端口。PDU 详情显示："Received分段信息：序列号（Seq）为 1，确认号（Ack）为 2482。设备接收到一个TCP FIN+ACK分段。"

  • 原理解释： 这里的参数完美承接了上一秒客户端的动作。系统提示"该设备从缓冲区中弹出最后一个发送的分段"，证明服务器看到 Ack=2482 后，确认所有的目录数据已安全送达，彻底清空了底层的发送缓存。

• 2. 出站方向（Outbound PDU）：合并发送挥手信号

  • 提取数据： 切换到出站标签页，源端口为 1032，目的端口为 1028。底层生成了一个全新的报文，其 TCP 标志位同样为 0b00010001（FIN+ACK）。

  • 序列号推演核对： 详情显示："Sent分段信息：序列号（Seq）为 2482，确认号（Ack）为 2"。

    • Seq = 2482： 顺延服务器发送上一批数据的结尾。

    • Ack = 2： 这是最核心的机制！因为刚才入站的 FIN 标志位会消耗一个序列号（入站 Seq=1），根据 TCP 确认规则，服务器必须加 1 进行确认，即 1 + 1 = 2这就解释了为什么出站确认号变成了 2。

  • 状态跃迁： 此时服务器在底层的状态连续发生了变化，先进入 CLOSE_WAIT（等待关闭），随即切入 LAST_ACK（最后确认）状态，静静等待客户端的最后一击。

【本阶段小结】

在 0.026 秒，服务器完成了挥手的第二步和第三步，将 FIN+ACK 发向客户端，并把连接状态置为 LAST_ACK。

阶段四终章：数据通道拆除（四次挥手第 4 步） ------ 客户端发送最终 ACK（时间戳 0.027 秒）

【现象描述】 在时间戳 0.027 秒，客户端（PC0）在 1028 端口迎来了服务器发来的 FIN+ACK 挥手报文。PC0 的底层 TCP 协议栈接收了服务器的断开请求，在模拟器的状态机中将其连接状态变更为 CLOSING（正在关闭）。紧接着，PC0 生成了四次挥手中的最后一步（纯 ACK 报文），将其发射回服务器。至此，PC0 端的拆除工作彻底完成。

【PDU 数据抓取与原理解析】

这是一个标准的接收与最终确认动作，我们严格核对真实的底层参数：

• 1. 入站方向（Inbound PDU）：接收服务器的终极清算

  • 核心标志位： 报文到达 1028 端口。PDU 格式图清晰显示 Flags 为 0b00010001（FIN+ACK）。

  • 序列号严密对应： 详情提示："Received分段信息：序列号（Seq）为 2482，确认号（Ack）为 2 "。这与 0.026 秒服务器的出站参数完全吻合。

  • 底层状态变更： 第 4 条提示明确指出："设备将连接状态设置为 CLOSING。"

• 2. 出站方向（Outbound PDU）：发出四次挥手的最后一击 【全场大结局】

  • 动作提取： PC0 向服务器（1032 端口）发出了一个标志位为 0b00010000（纯 ACK） 的最后确认包。

  • 序列号与确认号的终极定格（极度真实的抓包数据）： 详情显示："Sent分段信息：序列号（Seq）为 2，确认号（Ack）为 2482"。

    • Seq = 2： 因为 PC0 在 0.025 秒发出的自己的那个 FIN 包（Seq=1）消耗了一个序列号，所以现在顺理成章推进到了 2。

    • Ack = 2482（高光发现）： 按照标准 TCP 协议，对服务器 Seq=2482 的 FIN 包进行确认应为 2483。然而，Packet Tracer 模拟器在此处的底层运算并未为 FIN 标志位累加序列号 ，而是直接沿用了服务器传来的序列号 2482 进行确认。这就是网络实验中最真实的"所见即所得"！

【本阶段小结与终局宣告】 在 0.027 秒，PC0 以一个真实的 Seq=2, Ack=2482 报文，射出了 TCP 拆除连接的最后一颗子弹。

阶段四终局：数据通道彻底销毁 ------ 服务器接收最终 ACK 并关闭连接（时间戳 0.028 秒）

【现象描述】 在时间戳 0.028 秒，FTP 服务器（服务器0）的 1032 端口静静地接收到了来自客户端的最后一个报文。服务器底层的 TCP 协议栈对该报文进行了校验，确认这是对自身 FIN 断开请求的最终回复。随着这声代表"确认"的回音落地，服务器毫不留恋地切断了底层的资源占用，将该端口的连接状态正式标记为 CLOSED（已关闭）。临时数据通道彻底从网络世界中被抹除。

【PDU 数据抓取与原理解析】

这是一个纯粹的入站接收与终结动作（只有 Inbound PDU，没有出站响应，因为连接已经不复存在了）：

• 1. 链路的最后确认（OSI 第 4 层 - TCP）

  • 提取数据： 报文从客户端的 1028 端口，最终抵达服务器的 1032 端口。

  • 原理解释： 这是这两个临时端口在本次通信生命周期里的最后一次同框。

• 2. 数据的完美对接（高能核对）

  • 提取数据： PDU 详情清晰显示："Received分段信息：序列号（Seq）为 2，确认号（Ack）为 2482"。第三条提示补充道："该TCP分段具有预期的对端序列号。"

  • 原理解释： 这组数据与上一秒（0.027 秒）客户端发出的出站数据构成了 100% 的完美镜像！跨越了虚拟网络链路，数据依然严丝合缝。

• 3. 标志位与最终审判（状态机落幕）

  • 提取数据： 观察 PDU 格式图，TCP 标志位（Flags）为 0b00010000 （纯 ACK）。

  • 核心宣告： 详情页的最后一行，系统给出了最终的审判结果："设备将连接状态设置为CLOSED。"

  • 深度剖析： 在收到这个包之前，服务器处于 LAST_ACK（等待最后确认）状态。现在 Ack=2482 的确认包到了，四次挥手的最后一步达成闭环。TCP 状态机走到了终点 CLOSED，代表着这个 Socket 连接被操作系统彻底回收。

【大结局总结】 在 0.028 秒，伴随着 CLOSED 状态的亮起，专门用于传输 /ftp 目录列表的 1028 <-> 1032 数据通道光荣退役。