实验二十九：TCP的运输连接管理

一、实验目的

验证TCP通过"三报文握手"建立TCP连接

验证TCP通过"四报文挥手"释放TCP连接

二、实验步骤

2.1 构建网络拓扑与参数配置

在 Cisco Packet Tracer 工作区中构建点对点的网络拓扑，添加一台终端设备作为客户端（PC0）和一台服务器设备（Server0），并使用交叉线将两者的 FastEthernet 端口直接相连。

为便于直观查看，先在拓扑图中使用文本工具为两台设备标注好预期的 IP 地址和子网掩码。

随后，分别进入两台设备的桌面配置界面，将 PC0 的 IP 地址配置为 192.168.0.1，Server0 配置为 192.168.0.2，并将两者的子网掩码均严格设定为 255.255.255.0，确保双方处于同一局域网网段内。

2.2 网络连通性测试与 ARP 预处理

在进入后续的单步抓包前，打开计算机 PC0 的命令行界面（Command Prompt），使用 ping 192.168.0.2 命令测试 PC0 与 Server0 之间的连通性。

执行此步骤具有三大核心目的：第一，测试网络拓扑的物理层和数据链路层是否构建成功；第二，验证 PC0 和 Server0 各自的 IP 地址和子网掩码等网络层参数是否配置正确；第三（极其重要），让 PC0 与 Server0 提前通过地址解析协议（ARP）获取并缓存对方相关接口的 MAC 地址，以免在后续单步调试过程中突然出现 ARP 广播寻址过程，从而干扰对 TCP 核心实验现象的观察。如果连通性测试失败，需立刻返回检查拓扑连线及 IP 配置。

2.3 切换仿真模式与配置协议监视器

网络连通性测试通过后，将软件工作模式切换至仿真模式（Simulation）。为了精准捕捉目标数据并排除其他后台协议包的视觉干扰，在右侧事件列表面板中点击"编辑过滤器（Edit Filters）"，在弹出的面板中取消所有系统默认协议的勾选，仅保留并监视传输控制协议（TCP）和超文本传输协议（HTTP）的相关事件。至此，环境准备完毕，准备进行 TCP 连接管理过程的抓包分析。

三、实验核心步骤：TCP 运输连接管理全过程分析

在完成所有网络层基础配置及连通性测试后，本阶段将通过模拟器深度剖析 TCP 的连接建立、数据交互与连接释放过程。

在 PC0 的桌面打开 Web 浏览器，于地址栏输入 Server0 的 IP 地址 192.168.0.2 并点击"Go"以触发网络请求。此时，底层的 HTTP 客户进程需要先依赖 TCP 建立可靠的运输通道。随后，在仿真面板点击单步播放按钮，观察事件列表并逐个截取报文段（PDU）信息。

3.1 第一阶段：三报文握手（建立连接）

(1) 第一次握手：PC0 发送 TCP 连接请求报文段（SYN）

本次通信由 PC0 的 TCP 客户进程主动发起，目标为 Server0 的 TCP 服务器进程。在发起请求前，PC0 的 TCP 进程处于 CLOSED（关闭） 状态，而 Server0 已在对应的 80 端口（HTTP 服务）开启被动监听，处于 LISTEN（监听） 状态。

当在浏览器触发请求后，PC0 立即生成一个绿色的 TCP 报文段发往 Server0。点击该报文段打开 PDU 详细信息界面，查看出站 PDU 详情（Outbound PDU Details）中的第 4 层（运输层）参数：

首部标志位状态： 在 TCP 报文首部中，同步标志位（SYN）被置为 1 ，表示这是一个请求建立连接的同步报文；此时由于连接尚未建立，无可确认数据，故确认标志位（ACK）被置为 0。
序列号字段（seq）： 报文的序号（Sequence Number）被初始化为 0（注：Cisco Packet Tracer 默认使用从 0 开始的相对序号以便于教学观察）。
确认号字段（ack）： 由于 ACK 标志位为 0，此时确认号字段的值（为 0）无效。
状态机转换： 根据模拟器第 4 层事件描述------"该设备尝试在端口 80 上与 192.168.0.2 建立 TCP 连接。设备将连接状态设置为 SYN_SENT。 "，PC0 成功发出该请求报文后，其状态正式由 CLOSED 转变为 SYN-SENT（同步已发送） 。同时，该报文在第 4 层的核心动作被模拟器准确记录为："设备发送了一个TCP SYN分段。Sent分段信息：序列号 0，确认号 0，以及数据长度 24。"

(2) 第二次握手：Server0 发送连接确认及连接请求报文段（SYN + ACK）

本次通信由处于被动等待状态的 Server0 发往 PC0。当 Server0 接收到 PC0 发送的 TCP 连接请求报文段（SYN）后，其运输层 TCP 服务器进程接受该连接请求，状态随即由 LISTEN（监听） 转换至 SYN-RCVD（同步已接收） 状态。此时，Server0 需要向 PC0 发送确认报文，同时向 PC0 发起反向连接请求，因而本地生成一个包含双重功能的 SYN+ACK 报文段。在仿真模式下单击该报文，通过比对入站（Inbound）至出站（Outbound）的 PDU 详细信息，其运输层核心字段及状态机交互细节如下：

首部标志位状态： 在出站 TCP 首部中，同步标志位（SYN）与确认标志位（ACK）均被置为 1 。其中 ACK = 1 明确表示对 PC0 首次握手报文的有效确认，而 SYN = 1 则表明 Server0 正在向 PC0 发起反向连接请求。
序列号字段（seq）： 报文的序号字段被初始化为 0（使用 Packet Tracer 的相对序号计数机制），代表 Server0 自身数据流的初始发送序号。
确认号字段（ack）： 确认号字段被精确设定为 1 。其核心原理解析为：Server0 接收到的入站 SYN 报文段中 seq = 0，虽然该同步报文段并不携带任何应用层有效载荷，但依据 TCP 协议规范，SYN 标志位必须消耗一个序号。因此，服务器根据公式 ack = 接收到的 seq + 1（即 0 + 1 = 1）计算出确认号，其学术含义为"服务器已正确接收 PC0 的第 0 号同步报文，并期望对端下一次发送序号为 1 的报文段"。
运输层描述印证： 此时 PC0 本地因仍在等待服务器的响应，其连接状态依然维持在 SYN-SENT。而 Server0 端的 Layer 4 描述信息完整印证了这一状态跃迁过程：入站处理明确提示"该设备在服务器端口80上接收到一个TCP SYN分段... 设备将连接状态设置为SYN_RECEIVED "；出站处理则记录了回信动作："设备发送了一个TCP SYN+ACK分段。Sent分段信息：序列号 0，确认号 1，以及数据长度 24。"

(3) 第三次握手：PC0 发送确认报文段（ACK）及 Server0 接收确认

本次通信属于三报文握手的最后收尾阶段，由 PC0 的 TCP 客户进程发往 Server0 的 TCP 服务器进程。当 PC0 接收到 Server0 回送的 SYN+ACK 报文段后，其运输层协议软件会核对预期的对端序列号。验证无误后，PC0 的 TCP 连接状态正式由 SYN-SENT（同步已发送）跃迁至 ESTABLISHED（连接已建立） ，这标志着客户端侧的连接已准备就绪。这一状态转换过程在模拟器的入站（Inbound）处理描述中得到了清晰印证："该TCP分段具有预期的对端序列号... TCP连接成功... 设备将连接状态设置为 ESTABLISHED"。

为完成双向通道的建立，PC0 随即生成并发出本阶段的最后一个 TCP 报文段（纯 ACK 确认包）。通过观察出站 PDU 详细信息（Outbound PDU Details），可发现其首部核心字段发生了关键变化：同步标志位（SYN）已被置为 0 ，因为同步请求阶段已经结束；确认标志位（ACK）保持为 1 ，表明此报文段执行纯粹的确认功能。在序号参数方面，序列号字段（seq）变更为 1 ，其学术依据在于 PC0 发出的首个 SYN 报文虽无有效载荷，但按协议规定须消耗一个序号（即序号 0），故本次发送的序号顺延为 1；确认号字段（ack）被设定为 1 ，表明 PC0 已成功接收 Server0 发送的 seq = 0 的同步报文（同样消耗一个序号），根据公式计算，PC0 期望接收的下一个字节序号为 0 + 1 = 1。出站日志准确记录了该动作："设备发送了一个TCP ACK分段。Sent分段信息：序列号 1，确认号 1，以及数据长度 20"。此处系统日志显示的 20 字节"数据长度"实指 TCP 的首部长度，真正的应用层载荷数据为 0 字节，这完全符合标准 TCP 纯确认报文的特征。

随着单步模拟的推进，该确认报文最终抵达 Server0。Server0 的运输层在端口 80 接收到此 ACK 分段后，校验序列号及确认号匹配无误，Server0 的状态亦完成闭环，由 SYN-RCVD（同步已接收）正式转换为 ESTABLISHED（连接已建立） 。此时，模拟器底层日志提示："该设备...接收到一个TCP ACK分段... TCP连接成功。设备将连接状态设置为ESTABLISHED"。至此，双向 TCP 运输连接宣告彻底建立，应用层的 HTTP 客户进程与服务器进程具备了交互网页报文的底层通道条件。

附：第一阶段（三报文握手）核心数据与状态转换汇总表

握手阶段	发送方向	TCP 首部标志位	序号 (seq)	确认号 (ack)	PC0 (客户端) 状态变化	Server0 (服务器) 状态变化
第一次	PC0 → Server0	SYN=1, ACK=0	0	0	CLOSED → SYN-SENT	LISTEN (保持被动监听)
第二次	Server0 → PC0	SYN=1, ACK=1	0	1	SYN-SENT (保持等待)	LISTEN → SYN-RCVD
第三次	PC0 → Server0	SYN=0, ACK=1	1	1	SYN-SENT → ESTABLISHED	SYN-RCVD → ESTABLISHED

3.2 第二阶段：应用层数据交互与 TCP 可靠确认

在 TCP 三报文握手圆满完成、双方进程均进入 ESTABLISHED（连接已建立）状态后，应用层的 HTTP 客户进程正式开始交互网页报文。在单步模拟过程中，可以清晰地观察到 PC0 节点同时生成了紫色的 HTTP 报文与绿色的 TCP 报文，这直观地展示了计算机网络体系结构中"下层为上层提供服务并进行数据封装（Encapsulation）"的过程。

(1) PC0 发送 HTTP 请求报文段与 Server0 的入站处理

本环节由 PC0 发往 Server0。PC0 的 HTTP 客户进程生成获取网页的请求，交由底层 TCP 封装后发往服务器。当报文抵达 Server0 时，点击查看其入站 PDU 详细信息（Inbound PDU Details），可观察到报文依次通过第 1 层（物理层接收）、第 2 层（数据链路层 MAC 校验）与第 3 层（网络层 IP 校验为 192.168.0.2）。在最为核心的第 4 层（运输层）处理中，系统识别到该 TCP 分段的首部标志位中，推送标志位（PSH）与确认标志位（ACK）均被置为 1 。此时，序号（seq）为 1 ，确认号（ack）为 1 ，且携带的有效数据长度（Data Length）为 100 字节（此即为应用层 HTTP 请求数据的实际大小）。PSH 标志位在此处发挥了关键指令作用：它要求 Server0 的运输层在收到该报文后，无需等待接收缓存填满，直接将这 100 字节的有效载荷迅速向上（第 7 层）交付给 Web 服务器进程进行处理。

(2) Server0 响应 HTTP 网页数据与 TCP 确认号计算逻辑

当 Server0 的应用层读取 HTTP 请求并调用本地资源生成完整的 HTML 网页代码后，开始准备回送数据。通过查看 Server0 此时生成的出站 PDU 详细信息（Outbound PDU Details），可以精确验证 TCP 的可靠确认机制。在出站报文的第 4 层封装中，Server0 准备发送的数据长度达到了 471 字节 。其 TCP 首部的 ACK 标志位依然保持为 1 。此时 Server0 分配的序号（seq）为 1 （此为服务器端发出的第一个带有实际数据的字节序号）。最核心的变化在于其确认号（ack）变为了 101 。此数值的变动完美印证了 TCP 的累积确认公式：确认号 = 接收到的对端序号 + 接收到的有效数据长度。由于 Server0 刚刚接收到 PC0 发来的 seq = 1 且长度为 100 字节的报文段，故系统计算 ack = 1 + 100 = 101。这一精准的确认号向 PC0 明确传达了底层含义："前 100 个字节的数据我已经完整且安全地收到，下一次请从第 101 个字节开始向我发送数据。"

3.3 第三阶段：四报文挥手（释放连接）及模拟器实况分析

当应用层的 HTTP 网页数据交互顺利完成后，通信双方已无新的应用层数据需要传输，TCP 运输连接开始进入释放阶段。在单步模拟环境下，当 PC0 完整接收到来自 Server0 的 Web 响应载荷后，其本地立即生成一个准备释放连接的绿色 TCP 报文段，从而拉开了连接释放的序幕。

(1) 第一次挥手：PC0 发送连接释放请求报文段（FIN + ACK）

本次通信由 PC0 的 TCP 客户进程主动发起，目标为 Server0 的 TCP 服务器进程。在发起释放前，双端均处于 ESTABLISHED（连接已建立） 的稳定状态。随着 PC0 完成数据接收并决定关闭连接，其内部触发了主动关闭（Active Close）机制，向 Server0 发送连接释放报文段。

单击该报文段以解析其出站 PDU 详细信息（Outbound PDU Details），其运输层（Layer 4）首部的核心字段表现及数学逻辑如下：

首部标志位状态： 在 TCP 首部的 Flags 控制位中，终止标志位（FIN）被置为 1 ，表明此报文段为连接释放请求源；同时，确认标志位（ACK）同样保持为 1 （即发送的是 FIN+ACK 报文段），用以对前面接收到的所有服务器应用层数据进行最后的、持续性的累积确认。
序列号字段（seq）： 报文的序号被精确设定为 101 。其核心原理解析为：在第二阶段的数据交互中，PC0 发送 HTTP 请求时的初始序号 seq = 1，且该请求携带了 100 字节的有效载荷。依据序号顺延规则，本次新生成的报文序号应为 1 + 100 = 101。
确认号字段（ack）： 确认号字段被精确设定为 472 。其核心原理解析为：Server0 在上一阶段回传的 HTTP 响应报文段中，其起始序号 seq = 1，且携带的网页数据载荷长度为 471 字节。根据 TCP 确认机制公式 ack = 对端 seq + 数据长度，计算得出 1 + 471 = 472。该数值向服务器明确传达了"PC0 已经完美、无损地接收了全部 471 字节的网页数据，并向服务器报平安"的底层信息。
状态机转换与描述印证： 伴随着该报文段成功脱离 PC0 的网卡出站，PC0 的 TCP 状态正式由 ESTABLISHED 转变为 FIN-WAIT-1（终止等待 1） 状态，并在该状态下静静等待服务器对该 FIN 报文的确认。此时，模拟器 Layer 4 的出站描述信息完整记录并印证了这一过程："The TCP segment has the FIN and ACK flags set. It sets the sequence number to 101 and the acknowledgment number to 472.（该 TCP 报文段设置了 FIN 和 ACK 标志。它将序号设为 101，确认号设为 472，数据长度为 20 字节）"。20 字节的首部长度也再次证实，此挥手报文不含任何应用层附带数据。

(2) 第二次与第三次挥手（合并发出）：Server0 发送确认及连接释放报文段（FIN + ACK）

本次通信由 Server0 发往 PC0。在标准的 TCP 四报文挥手理论中，服务器在收到客户端的 FIN 报文后，应先回复一个纯 ACK 报文（第二次挥手），待自身数据发送完毕后，再发送 FIN 报文（第三次挥手）。然而，在本次模拟器实况中，我们观察到了一个极其经典的协议优化现象------报文合并与状态机的跃迁。

当 Server0 接收到 PC0 发来的 FIN+ACK 报文段后，其运输层首先确认了 PC0 已无新数据发送，状态机短暂切入 CLOSE-WAIT（关闭等待） 状态。紧接着，由于 Server0 的 Web 服务应用层也已经完成了所有网页数据的下发，没有额外数据需要缓冲和传输，应用层立即通知 TCP 协议栈释放连接。因此，Server0 的状态迅速从 CLOSE-WAIT 转变为 LAST-ACK（最后确认）。为了提升网络传输效率，Server0 的底层协议栈将理论上的"确认包（ACK）"与自身的"结束包（FIN）"合并为一个报文段发出。

单击该出站报文段（对应 Server0 的 Outbound PDU 详情），其核心控制字段与序号的递增逻辑表现如下：

首部标志位状态： 在 TCP 首部中，终止标志位（FIN）与确认标志位（ACK）均被置为 1 。其中 ACK = 1 代表 Server0 确认："我已经收到了你的断开请求"；而 FIN = 1 则代表 Server0 宣告："我的数据也已全部发送完毕，同样同意断开当前连接"。
序列号字段（seq）： 报文的发送序号被精确设定为 472。这一数值的推导逻辑为：在第二阶段的数据交互中，Server0 下发的 HTTP 网页数据总长度为 471 字节（起始序号为 1，消耗了 1 至 471 的序号空间）。因此，本次新发报文的序号严格顺延为 472。
确认号字段（ack）： 确认号被变更为 102 。这一核心参数完美体现了 TCP 的控制位序号消耗规则：在上一步中，PC0 发来的挥手报文 seq = 101。虽然该 FIN 报文段未携带任何应用层有效载荷（数据长度为 0），但按照 TCP 协议规范，FIN 控制位必须消耗一个序号 。因此，服务器在回送确认时，严格执行 ack = 接收到的 seq + 1，即 ack = 101 + 1 = 102。此确认号向 PC0 提供了明确的底层反馈："序列号为 101 的 FIN 断开请求已被正确接收处理"。

(3) 第四次挥手：PC0 发送最后的确认报文段（ACK）及连接彻底释放

在 Server0 发出合并的 FIN+ACK 报文段后，TCP 释放流程进入最终阶段。此阶段主要涵盖 PC0 对服务器结束请求的最终确认，以及 Server0 接收确认后的彻底关闭。

首先，PC0 的运输层接收到 Server0 发来的带有 FIN 标志的报文。在标准的 TCP 状态机理论中，PC0 接收到服务器的 FIN 后，本应从 FIN-WAIT-1 状态转入 TIME-WAIT 状态；然而，受限于 Cisco Packet Tracer 模拟器的特定时序判定机制（系统将其判定为双方同时发起断开连接），PC0 短暂进入了 CLOSING（同时关闭）状态。

随后，PC0 生成并发出本次会话的最后一个报文段。但严格来说，由于模拟器的特殊行为，其确认号并未遵循协议递增以真正确认服务器发出的 FIN 报文。解析其出站 PDU 详细信息（Outbound PDU Details），可观察到以下核心参数：

首部标志位状态： 报文的 确认标志位（ACK）被置为 1，且不再包含 FIN 标志，表明这是纯粹的结束确认报文。
序列号字段（seq）： 设定为 102 。由于 PC0 在第一次挥手时发出的 FIN 报文段（seq = 101）按规则需消耗一个序号，故当前发出的确认报文序号严格顺延为 102。
确认号字段（ack）： 设定为 472 。此处需作重要实验现象记录：按照严格的 TCP 理论，Server0 在上一步发出的 FIN 报文同样应消耗一个序号，客户端回复的确认号理应递增为 473（即 472 + 1）。但在本次 Cisco Packet Tracer 仿真抓包实况中，系统给出的实际确认号仍为 472。为保证实验结果的客观性，本报告严格记录模拟器底层实际抓取的真实物理层与运输层数据。
数据长度： 系统日志显示为 20 字节。此处"数据长度"实指 TCP 报文段的首部长度（Header Length），其真正的应用层载荷数据为 0 字节。这完全符合标准 TCP 纯确认报文的特征。

随着单步模拟的推进，该最终确认报文段成功抵达 Server0。Server0 的运输层对其进行入站解析。此处需要指出：按照严格的 TCP 理论，ack 必须为 473 才能真正确认 FIN 报文；但在此模拟器的特殊逻辑下，Server0 接收到该 ack = 472 的报文后，依然判定对端已做出回应，并顺势推进释放流程。随即，Server0 的 TCP 状态机由 LAST-ACK（最后确认）正式终结并设置为 CLOSED（完全关闭）。

至此，宣告双方的 TCP 运输连接完美释放，本次 Web 数据交互所占用的通信网络资源被系统全面回收。

附：第三阶段（四报文挥手）核心数据与状态转换汇总表

挥手阶段	发送方向	TCP 首部标志位	序号 (seq)	确认号 (ack)	PC0 (客户端) 状态变化	Server0 (服务器) 状态变化
第一次	PC0 → Server0	FIN=1, ACK=1	101	472	ESTABLISHED → FIN-WAIT-1	ESTABLISHED
第二次 & 第三次 (合并优化)	Server0 → PC0	FIN=1, ACK=1	472	102	FIN-WAIT-1 → CLOSING	ESTABLISHED → CLOSE-WAIT → LAST-ACK
第四次	PC0 → Server0	ACK=1	102	472	CLOSING → CLOSED	LAST-ACK → CLOSED

四、实验现象总结与拓展探讨

通过对 PC0 访问 Server0 全过程的单步模拟与 PDU 逐层剖析，本实验不仅成功验证了 TCP 运输连接建立与释放的标准状态机转换，还捕捉到了底层协议在实际运行时的动态优化与仿真软件的特定表现。以下针对实验中出现的两项核心现象进行深度总结与探讨：

4.1 关于"四次挥手"优化为"三次挥手"的原理解析

在标准的计算机网络理论中，TCP 连接的释放通常被称为"四报文挥手"（即客户端发 FIN → 服务器回 ACK → 服务器发 FIN → 客户端回 ACK）。但在本实验的实际模拟抓包中，完整的释放过程仅交互了三个报文段。

现象溯源： 当 Server0 中的 TCP 服务器进程收到 PC0 发来的 TCP 连接释放报文段（FIN+ACK）后，按规则会首先进入 CLOSE-WAIT（关闭等待） 状态。
优化机制（捎带确认/合并报文）： 由于此时 Web 网页数据已经全部传输完毕，TCP 服务器进程的发送缓存中没有任何需要发给客户进程的遗留数据。应用层立刻通知 TCP 释放连接，TCP 服务器进程随之迅速进入 LAST-ACK（最后确认） 状态。为了提升网络传输效率并节约带宽，底层协议栈触发了合并机制，将理论上应该分步发送的"确认报文（ACK）"与"连接释放报文（FIN）"合并为一个 FIN+ACK 报文段发送给 TCP 客户进程。
结论： 经典的"四报文挥手"被协议栈自动优化变成了"三报文挥手"。这一现象并非操作失误，而是完美印证了 TCP 协议在实际网络传输中为了追求高效而采取的灵活处理机制。

4.2 理论机制与仿真环境（Cisco Packet Tracer）的微小差异探讨

除了报文合并现象外，在第四次挥手阶段，我们通过对比 PDU 真实数据与理论推导，还发现了仿真软件特定环境下的微小差异：

关于 CLOSING（同时关闭）状态的触发：

按照严格理论，PC0 发出 FIN 报文后处于 FIN-WAIT-1 状态，若直接收到服务器的合并 FIN+ACK 报文，其状态应平滑过渡至 TIME-WAIT。但在模拟器实况中，PC0 却短暂进入了 CLOSING 状态。这通常是因为 Cisco Packet Tracer 的时序判定机制将这种极短时间内的双向 FIN 交互判定为了"双方同时发起断开连接"（Simultaneous Close），从而触发了这条特定的状态机分支。
关于最终确认号（ack）未严格递增的现象：

在最后一步中，Server0 发出的合并报文带有 FIN 标志。根据 TCP 协议的序号消耗规则，FIN 标志位必须消耗一个序号（即使没有数据载荷）。因此，理论上 PC0 最终发出的确认报文，其确认号理应递增为 473。但在本次仿真抓包中，系统实际赋予的确认号仍为 472。这表明 Cisco Packet Tracer 的 TCP 协议栈在处理此类合并挥手报文的序号确认时，并未完全遵循标准 RFC 793 的底层规范，而是采用了内部的简化逻辑。