关闭TCP连接时不必要的ACK
我正在学习关闭TCP连接的过程，在我遇到的许多来源中，这个过程是不同的。在思科证书官方指南(100-105)中，这一过程如下：
1) ACK, FIN ---->
2) <---- ACK
3) <---- ACK, FIN
4) ACK ---->我只是不明白ACK在3中的用途，因为在2中已经有了确认。此外，在较早的思科研究材料中，这一过程也没有进行。
最重要的是，我有一个WireShark捕获，这让我更加困惑：
基本上一样，38号包中的额外ACK是用来做什么的？确认已经在第37号发送了。而且两者都有相同的Ack号。
有人能给我一点洞察力吗?如果在某些情况下所有这些都是可能的，或者哪一个是正确的？
回答 2
Network Engineering用户
发布于 2016-07-07 13:37:10
确认号有效时设置ACK标志。因此，它被设置在TCP流中的所有数据包上，除了初始的SYN数据包，所以当您发送FINs时，所有数据包都将是ACK。你不需要担心。
确认不是一次性的事情，如果没有收到更多的消息(在发送ACK的末尾)，随后的数据包都将确认相同的数据。这在两个方向都有作用。
Network Engineering用户
发布于 2016-07-07 16:11:00
TCP关闭序列实际上是：
1) FIN ---->
2) <---- ACK
3) <---- FIN
4) ACK ---->就像在TCP启动序列，有四个事件发生一样。一方表示已完成与鳍一起发送数据，另一方确认接收了鳍。然后，当另一方发送数据时(通常是在后面，但不一定是这样)，它就会发送自己的鳍，而第一方承认这一点。
通常，#2和#3合并在同一个数据包中。
而且，通常1号中的鳍也伴随着ACK来确认从另一边接收到的最后一次数据。
在您的数据包捕获中也可以看到这一点：
- 数据包38是最初的鳍。
- 数据包39是响应的ACK和另一方的鳍
- 第40包是最后的ACK。
注意，数据包39负责上述步骤2和步骤3。
奇怪的是你捕获的是重复的ACK。注意，数据包37和分组38中的ACK正在确认在使用acknowledgement# 22951之前发送的数据。只看那5包，我不知道为什么会这样。我确实看到了37号包到38号包之间的~5s延迟，我想知道这是否有什么关系。
https://networkengineering.stackexchange.com/questions/32921
复制相似问题
腾讯云开发者
