是什么导致发送TCP / IP重置（RST）标志？

我试图弄清楚为什么我的应用程序的TCP / IP连接每10分钟（准确地说是在1-2秒内）不断打h。我运行Wireshark，发现在闲置10分钟后，另一端正在发送设置了重置（RST）标志的数据包。谷歌搜索告诉我“ RESET标志表示接收器已变得混乱，因此想中止连接”，但这与我需要的详细信息略有不同。是什么原因造成的？沿途有路由器负责吗，还是总是来自另一个端点？

编辑：在我的计算机和另一个端点之间有一个路由器（特别是Linksys WRT-54G）-在路由器设置中我应该寻找什么吗？

一个“路由器”可能正在做任何事情-特别是NAT，它可能涉及到任何数量充斥着错误的混乱的流量...

设备将发送RST的原因之一是响应收到封闭套接字的数据包。

很难给出一个坚定而笼统的答案，因为自TCP诞生以来，所有可能的变态都已经在TCP上进行了访问，并且各种各样的人可能正在插入RST来试图阻止流量。（例如，某些“国家防火墙”的工作原理是这样的。）

在对等方上也运行一个数据包嗅探器（例如Wireshark），以查看是发送RST的对等方还是中间的某个人。

我刚刚花了很多时间来解决这个问题。所提出的解决方案均无效。原来，我们的系统管理员错误地将相同的静态IP分配给属于不同组但位于同一网络上的两个不相关的服务器。最终结果是断断续续地断开了vnc连接，必须多次刷新浏览器才能获取网页，以及其他奇怪的事情。

RST由执行主动关闭的一方发送，因为它是发送最后一个ACK的一方。因此，如果从错误状态下进行被动关闭的那一侧接收到FIN，则它将发送RST数据包，该数据包指示发生错误的另一侧。

如果连接闲置了x分钟，某些防火墙会这样做。一些ISP也出于各种原因将其路由器设置为执行此操作。

在这个时代，您将需要妥善处理（根据需要重新建立）该条件。

如果存在执行NAT的路由器，尤其是资源少的低端路由器，它将首先老化最旧的TCP会话。为此，它RST在数据包中设置标志，该标志有效地告诉接收站（非常讨厌）关闭连接。这样做是为了节省资源。

要注意的一件事是许多Linux netfilter防火墙配置错误。

如果您有类似的东西：

-A前进-m状态-状态相关，已确定-j接受

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

然后，数据包的重新排序可能导致防火墙认为数据包无效，从而生成重置，这将破坏正常的连接。

无线网络特别可能会进行重新排序。

相反，它应该是：

-A前进-m状态-状态相关，已确定-j接受

-A FORWARD -m状态--state无效-j DROP

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

基本上只要您有：

... -m状态-状态相关，已确定-j接受

随后应立即：

... -m状态-状态无效-j DROP

最好先丢弃一个数据包，然后生成可能破坏tcp重置的协议。当重置被证明是正确的东西时，重置会更好……因为这样可以避免超时。但是，如果有可能它们是无效的，那么它们会引起这种痛苦。

这是因为网络中还有另一个进程将RST发送到您的TCP连接。

通常在以下情况下将发送RST

• 启用使用SO_LINGER选项的套接字时，进程将关闭套接字
• 当您的进程退出而不关闭套接字时，操作系统正在执行资源清理。

在您的情况下，听起来好像进程正在连接您的连接（IP +端口），并在建立连接后继续发送RST。