在使用 FIN 数据包发起终止后从 TCP 连接接收数据包有多常见？答案

【问题标题】：How common is it to receive packets from a TCP connection AFTER initiating termination w/ a FIN packet?在使用 FIN 数据包发起终止后从 TCP 连接接收数据包有多常见？
【发布时间】：2019-10-27 16:02:17
【问题描述】：

我最近在好的 ol' Wikipedia[1] 上阅读了有关 TCP 连接终止的信息，并且提到的文章提到了半打开状态的可能性 [2]。基本上，启动关闭 TCP 连接的机器“应该”继续读取数据，直到另一端也终止。这是在每一端使用设置了 FIN 标志的 TCP 段/数据包完成的。

我很担心“应该”这个词。我有两个健全性检查问题：

首先，这有多普遍，真的吗？在我看来，一般来说，资源的客户端或请求者将是发起终止 TCP 连接的人，并且他们会在收到他们需要的所有内容后执行此操作。在正常情况下，当 TCP 连接终止时，不应该有任何数据包通过线路，对吧？

在相关的说明中，连接终止符“应该”继续接受数据的声明是一个强烈的要求还是更多的指导方针？如上所述，从我的角度来看，如果出现问题，连接只会过早关闭，在这种情况下，继续读取数据可能不可行。在我看来，继续处理数据实际上是一个安全漏洞。我可以通过打开一堆与流氓客户端的 TCP 连接来执行第 4 层 DDOS 攻击，并在不发送 FIN 数据包的情况下发送连续的垃圾邮件数据。

[1]https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination [2]https://en.wikipedia.org/wiki/TCP_half-open

【问题讨论】：

FIN 表示您已发送完毕。对等方可能尚未完成向您发送数据，如果您调用shutdown() 而不是close()，您仍然可以接收该数据。但是，如果您调用了close()，则对等方将重置连接。
我想我错过了你的观点。我知道对方可能还没有完成发送给我的信息，但我仍然可以阅读。我的问题是（1）我为什么要关心？如果我已经决定停止发送，为什么还要读取数据？ (2) 这实际上会在什么时候发生？即使我告诉他们停止，他们什么时候还想继续向我发送数据？我的假设是发送 FIN 数据包与传达我想尽快终止连接的同义词。

标签： tcp

【解决方案1】：

我的假设是发送一个 FIN 数据包与传达我想尽快终止连接的同义词

事实并非如此。发送一个 FIN 仅仅意味着这一方已经完成了数据的发送，而不是它已经完成了接收数据。例如，这样的half-close 可以被客户端用来表示请求的结束，但仍然等待服务器的响应——然后服务器的响应也会以 FIN 终止，从而导致完全关闭的连接。尽管如此，虽然这种协议设计在理论上是可能的，但在实践中并不常见。

但是在使用 HTTP 持久连接时，您可能会在服务器 FIN 之后遇到客户端数据：服务器可能会在发送请求响应后随时关闭空闲连接。但是客户端可能会在仍然打开的连接上发送新请求。由于在服务器上发送 FIN 与在客户端接收和处理它之间存在一些延迟，因此服务器上空闲连接的关闭和客户端上新请求的发送可能会重叠。在这种情况下，即使服务器套接字因发送而关闭，也会在服务器套接字上获得新数据。

【讨论】：