我正在学习关闭 TCP 连接的过程，这个过程在我遇到的许多来源中都不同。在官方 Cisco cert guide (100-105) 中，过程如下：
1) ACK, FIN ---->
2) <---- ACK
3) <---- ACK, FIN
4) ACK ---->
我只是没有看到 3) 中 ACK 的目的，因为 2) 中已经有一个确认。此外，在较旧的 Cisco 学习材料中，该过程也没有 2)。
最重要的是，我有这个 WireShark 捕获让我更加困惑：
基本上相同的事情，数据包#38 中额外的 ACK 是做什么用的？确认已在#37 中发送。并且两者也具有相同的确认号。
如果在某些情况下所有这些都是可能的，或者哪一个是正确的，有人能给我一点见解吗？
当确认号有效时，设置 ACK 标志。因此，它设置在 TCP 流中除初始 SYN 数据包之外的所有数据包上，因此当您发送 FIN 时，所有数据包都将是 ACK。你不必担心它。
确认不是一次性的，如果没有收到更多数据（到发送 ACK 的那一端），后续数据包将全部确认相同的数据。这在两个方向都有效。
TCP Close 序列实际上是：
1) FIN ---->
2) <---- ACK
3) <---- FIN
4) ACK ---->
就像在TCP 启动序列中一样，有四个事件发生。一侧表明他们已完成与 FIN 的数据发送，另一侧确认收到 FIN。然后，当另一方完成发送数据时（通常是紧接其后，但并非必须如此），它会发送自己的 FIN，并且第一方对其进行确认。
通常，#2 和#3 组合在同一个数据包中。
此外，#1 中的 FIN 通常还伴随着一个 ACK，以确认从另一端接收到的最后一个数据。
您在数据包捕获中也看到了这一点：
请注意，数据包 39 处理了上述序列中的第 2 步和第 3 步。
您捕获的奇怪之处在于重复的 ACK。请注意，数据包 37 和数据包 38 中的 ACK 正在确认使用确认# 之前发送的数据22951。只看那 5 个数据包，我不知道为什么会这样。我确实看到数据包 37 和 38 之间有大约 5 秒的延迟，我想知道这是否以某种方式起作用。