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

Question

我正在试图找出为什么我的应用程序的TCP / IP连接每10分钟（确切地说，在1-2秒内）打嗝。我运行Wireshark并发现在10分钟不活动后，另一端正在发送一个设置了重置（RST）标志的数据包。谷歌搜索告诉我“RESET标志表示接收器已经变得混乱，因此想要中止连接”但这有点不足我需要的细节。可能是什么导致了这个？并且沿途的某个路由器是否有可能对此负责，或者这总是来自另一个端点？

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

Answer 1

“路由器”可能正在做任何事情 - 特别是NAT，这可能涉及任何数量的错误缠身的流量......

设备发送RST的一个原因是响应接收到已关闭套接字的数据包。

很难给出一个坚定但一般性的答案，因为从一开始就已经在TCP上访问过每个可能的变态，并且各种各样的人可能会插入RST以试图阻止流量。 （例如，某些“国家防火墙”就像这样工作。）

Answer 2

在对等体上也运行数据包嗅探器（例如，Wireshark），看看它是发送RST的对手还是中间人。

Answer 3

我花了很长时间来解决这个问题。所提出的解决方案都没有奏效。 原来我们的系统管理员错误地将相同的静态IP分配给属于不同组但位于同一网络的两个不相关的服务器。最终结果是间歇性地丢弃连接，浏览器必须刷新几次以获取网页，以及其他奇怪的事情。

Answer 4

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

在这个时代，你需要优雅地处理（根据需要重新建立）这种状况。

Answer 5

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

Answer 6

RST由执行主动关闭的一方发送，因为它是发送最后一个ACK的一方。因此，如果它从处于错误状态的被动关闭的一侧收到FIN，它会发送一个RST数据包，指示另一方发生了错误。

Answer 7

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

如果您有类似的东西：

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

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

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

使用无线网络进行重新排序特别容易。

这应该是：

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

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

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

基本上在任何时候都可以：

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

紧随其后的是：

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

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

Answer 8

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

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

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

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

Answer 9

在大多数应用程序中，套接字连接都有超时。如果在超时内客户端和服务器之间没有通信，则连接将根据您的观察重置。 一个很好的例子是一个 FTP 服务器，如果你连接到服务器，然后离开连接而不浏览或下载文件，服务器会踢你的连接，通常允许其他人能够连接。我想这就是您在连接时遇到的情况。因此，请查看服务器应用程序，如果这是您从中获取重置的地方，并查看它是否确实在源代码中为连接设置了超时。