意外的TCP RST数据包

在我们的环境中，我们面临随机RST数据包问题，这会导致一些意外行为，下图是wireshark生成的tcp数据的快照，显示了问题：

客户端（117.136.2.181）已成功建立与服务器（192.168.40.16）的连接

客户端向服务器发送一些数据，以及KEEP_ALIVE信号

服务器接收数据，对其进行处理，并将结果发送回客户端

服务器关闭套接字

服务器不接收来自客户端的ACK信号，因此它会重新传输结果数据以及FIN信号，这是由TCP协议自动完成的。然而，服务器仍然没有收到来自客户端的ACK信号

服务器向客户端发送RST信号，以便关闭连接

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

---

有人能解释一下为什么会发生这种情况吗？

RST

通常发生在未关闭

的情况下在套接字上调用
关闭
，或者在关闭
后，当另一方仍试图发送数据时（仍然没有用
FIN
回复）

一些编程语言有一个
socket.close（timeout）
for，它调用
shutdown
，然后在
timeout
结束后调用
close

因此，客户端最多有
timeout
来完成发送和关闭与
FIN
的连接，如果失败，将由
RST
强制关闭连接

有关
close
和
shutdown
之间差异的更详细解释，请参阅？看起来好像有人在发送keep alives的最后严重破坏了TCP堆栈。我必须深入研究代码才能发现，这会导致RST发生吗？这显然是一个煽动性事件。你能解释一下吗？除此之外，我们还看到了其他没有KEEP_的意外RST ~这些是定制/实验TCP堆栈还是标准？