TCP：半关闭连接上的数据答案

【问题标题】：TCP: data on a half-closed connectionTCP：半关闭连接上的数据
【发布时间】：2013-10-23 23:11:58
【问题描述】：

我正在实现一个 TCP 堆栈，并且遇到了半关闭连接的问题。

我的实现充当服务器端。客户端建立连接，然后发送一些数据，然后发送“FIN”消息。然后服务器确认来自客户端的数据，发送自己的一些数据，然后才关闭它的一半连接（发送“FIN”）。

问题是客户端在半关闭的连接上没有确认服务器发送的数据，也没有确认它的最终“FIN”消息。根据 netstat，客户端处于状态 FIN_WAIT2。在服务器不发送任何数据的相同场景中，事情进展顺利。有问题的客户是netcat，所以我认为问题出在我的最后:)

屏幕截图可用here。实际的 PCAP 文件在here 可用。

我的问题是，一般来说，我是否应该期望在半关闭的连接上发送数据的 ACKS？尤其是我在上面的例子中做错了什么。

任何帮助将不胜感激！

【问题讨论】：

从对等体的角度来看，你不知道它是一个半封闭的连接。客户端可能已经完全关闭了连接，在这种情况下，端口在您这边的 CLOSE_WAIT 和对等方的 FIN_WAIT_2 中，但是对等方将发送 RST 而不是 ACK 到您的发送。您的链接下载.exes，就我而言，这可能是病毒。还有其他方法可以使它们可用吗？
感谢您的评论。我已经更新了链接 - 希望它们现在可以正确显示。
屏幕截图中的最后一行是您的第一个 PSH 的 ACK。还有吗？
我把它搁置了几分钟，没有其他事情发生。另外，netcat 客户端没有完成运行，即没有返回提示。
两边的端口状态是什么？

标签： tcp

【解决方案1】：

也许服务器应该在 FIN/ACK 中发送 ACK=2561 而不是 2562？

【讨论】：

我刚刚尝试使用 2561 而不是 2562。这产生了类似的结果 - 客户端重复其 [FIN,PSH,ACK] 消息，但序列号为 2562 - 所以我相信 2562 是正确的首先考虑确认（FIN 计为 1 个字节）。 EJP，我在之前的回复中犯了一个错误。 Netstat 说在原始问题（acking 2562）中，客户端处于 FIN-WAIT-2 中。使用2561时，处于FIN-WAIT-1。
是的，我错了：应该是 2562。显然，客户不希望出于未知原因确认您的数据。您可以尝试重新传输您的数据，看看会发生什么。

【解决方案2】：

FIN-WAIT-2 表示它看到了 ACK，所以序列号一定是正确的，但也表示它没有看到同一段的 FIN。如果 FIN 算作 1 个字节，LEN 应该是 1？

【讨论】：

我认为“LEN”不是数据包中的实际字段-它只是wireshark告诉你tcp段包含多少字节。 FIN 是标头中的标志而不是实际字节，所以我认为 0 是正确的。我同意您的评估，即客户忽略了鳍。问题似乎更早开始，当它不确认在 fin 之前发送的任何数据时。这是我最初的问题的一部分 - 我是否应该期望客户端确认这些数据，已经关闭了它的连接端？
是的，您应该期待所有数据的 ACK。