意外的TCP RST数据包

Question

我们的环境中出现了随机RST数据包问题，导致一些意外行为。下面这张图片是Wireshark生成的TCP数据快照，显示了问题：

1. 客户端（117.136.2.181）成功与服务器（192.168.40.16）建立连接。
2. 客户端向服务器发送一些数据和KEEP_ALIVE信号。
3. 服务器接收数据，处理后将结果发送回客户端。
4. 服务器关闭套接字。
5. 服务器没有收到客户端的ACK信号，所以它重新传输结果数据和FIN信号，这是TCP协议自动完成的。但是，服务器仍然没有收到来自客户端的ACK信号。
6. 服务器向客户端发送RST信号，以关闭连接。

经过分析，我们认为在第3步之后发生了某些网络问题，因此来自服务器的所有结果数据和FIN信号都没有被客户端确认，但我们对服务器发送的RST信号感到非常困惑。根据我们的理解，如果半关闭套接字接收到一些数据，或者当关闭套接字时接收队列中有数据，就会发送一个RST信号。但是，这两个原因似乎都不是我们案例的根本原因。

请问有人可以详细说明为什么会出现这种情况吗？

- asticx

---

为什么我们在数据之后立即看到保持连接信号？看起来发送保持连接信号的一端TCP堆栈出现了严重问题。 - David Schwartz

我需要深入代码才能找出这个问题，这可能会导致RST发生吗？ - asticx

这绝对是引发事件的原因。 - David Schwartz

你能否详细解释一下这个问题？此外，我们还看到其他意外的RST而没有KEEP_ALIVE~ - asticx

这些是自定义/实验性的TCP堆栈还是标准的？ - Jan Wrobel

我相信这是标准的TCP协议栈~ - asticx

Answer 1

RST通常发生在套接字上调用close而没有使用shutdown，或者在另一方仍在尝试发送数据（仍未回复FIN）的情况下进行shutdown之后。

一些编程语言有一个socket.close(timeout)，例如.NET，它在timeout过去后调用shutdown然后调用close。

因此，客户端有最多timeout时间来完成发送并使用FIN关闭连接，如果无法这样做，则会通过RST强制关闭连接。

有关close和shutdown之间差异的更详细解释，请参见https://dev59.com/Rm855IYBdhLWcg3ww3Sa#23483487。

- Ayoub Kaanich