是什么导致发送 TCP/IP 重置 (RST) 标志？答案

【问题标题】：What causes a TCP/IP reset (RST) flag to be sent?是什么导致发送 TCP/IP 重置 (RST) 标志？
【发布时间】：2010-09-20 01:22:27
【问题描述】：

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

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

【问题讨论】：

这是另一个：康卡斯特
呵呵，幸运的是我对 Comcast 没有依赖，因为这是在 LAN 中发生的。我希望我能轻松地推卸责任；）
你有没有想过这个问题？我无法发表评论，因为我没有足够的积分，但我遇到了和你一样的问题，我正在寻找解决方法。
这个特殊案例指的是什么服务？可以在套接字上设置keepalive（从应用程序级别），这样长时间的空闲时间不会导致某人（在中间或不在中间）因为缺乏资源而试图强制重置连接。
“康卡斯特”你说？ :D 查看这个相关的回购：github.com/tylertreat/comcast

标签： networking tcp

【解决方案1】：

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

在当今时代，您需要优雅地处理（根据需要重新建立）这种情况。

【讨论】：

重新建立连接就好了，问题是短暂的断开连接会导致不必要的警报。
我在使用 Cisco PIX/ASA 设备时遇到了问题。它们的默认超时时间特别短。在这方面，更便宜的设备通常“更好”（因为它们不会很快超时）......
我什至要补充一点，从持久连接的角度来看，TCP 实际上从来都不是完全可靠的。它只是不时变得更加明显。另一个有趣的例子：有些人可能会实现在检测到连接关闭或重置时将 TCP 客户端标记为离线的逻辑。然后有时他们不会费心给客户重新连接的机会。这显然不完全正确。

【解决方案2】：

“路由器”可以做任何事情 - 尤其是 NAT，它可能涉及到任何数量的错误缠身的流量...

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

很难给出一个明确但普遍的答案，因为自 TCP 诞生以来，所有可能的变态都已在 TCP 上被访问过，并且各种各样的人都可能会插入 RST 以试图阻止流量。（例如，一些“国家防火墙”就是这样工作的。）

【讨论】：

要么路由器有 10 分钟的 TCP 连接超时，要么路由器启用了“网关智能数据包检测”。
建议路由器可能存在错误有点丰富。

【解决方案3】：

同时在对等点上运行数据包嗅探器（例如 Wireshark），以查看发送 RST 的对等点还是中间人。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

【讨论】：

正常关闭时双方发送和接收一个FIN。这种情况没有任何问题，因此一方没有理由发出重置。第一句话甚至没有意义。
[RST, ACK] 也可以由在未被侦听的端口上接收 SYN 的一方发送。在我遇到的一个案例中，RST/ACK 在第一个 SYN 之后大约 60 秒出现。 FWIW
@MarquisofLorne，第一句话本身可能被视为不正确。但是第二句中的“处于错误状态”这一短语使其在某种程度上是有效的。

【解决方案6】：

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

【讨论】：

【解决方案7】：

需要注意的一点是，许多 Linux netfilter 防火墙配置错误。

如果你有类似的东西：

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

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

然后数据包重新排序可能会导致防火墙认为数据包无效，从而生成重置，然后会中断其他健康的连接。

无线网络特别有可能重新排序。

这应该是：

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -m state --state INVALID -j DROP

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

基本上任何时候都有：

... -m state --state RELATED,ESTABLISHED -j ACCEPT

应该紧跟在后面：

... -m state --state INVALID -j DROP

最好丢弃一个数据包然后生成一个潜在的协议中断 tcp 重置。当它们被证明是正确的发送时，重置会更好......因为这消除了超时。但是，如果它们有任何可能无效，那么它们可能会导致这种痛苦。

【讨论】：

【解决方案8】：

这是因为网络中有另一个进程向你的 TCP 连接发送 RST。

正常情况下会发送RST

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

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

【讨论】：

【解决方案9】：

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

【讨论】：