我试图弄清楚为什么我的应用程序的 TCP/IP 连接每 10 分钟（确切地说，在 1-2 秒内）不断打嗝。我运行了 Wireshark，发现在 10 分钟不活动后，另一端正在发送一个设置了重置 (RST) 标志的数据包。谷歌搜索告诉我“RESET 标志表示接收器变得混乱，因此想要中止连接”，但这有点缺乏我需要的细节。这可能是什么原因造成的？沿途的某个路由器是否可能对此负责，或者这是否总是来自另一个端点？
编辑：在我的计算机和另一个端点之间有一个路由器（特别是 Linksys WRT-54G）——我应该在路由器设置中寻找什么吗？
“路由器”可以做任何事情 - 特别是 NAT，它可能涉及任何数量的错误缠身的流量......
设备发送 RST 的一个原因是为了响应接收到已关闭套接字的数据包。
很难给出一个明确但普遍的答案，因为自从 TCP 开始以来，所有可能的变态都在 TCP 上被访问过，并且各种各样的人都可能会插入 RST 以试图阻止流量。（例如，一些“国家防火墙”就是这样工作的。）
同时在对等点上运行数据包嗅探器（例如，Wireshark），以查看发送 RST 的对等点还是中间人。
我刚刚花了很多时间来解决这个问题。所提出的解决方案都没有奏效。原来，我们的系统管理员错误地将相同的静态 IP 分配给了属于不同组但位于同一网络上的两台不相关的服务器。最终结果是间歇性地断开 vnc 连接，浏览器必须刷新几次才能获取网页，以及其他奇怪的事情。
RST 由执行主动关闭的一方发送，因为它是发送最后一个 ACK 的一方。因此，如果它在错误状态下从执行被动关闭的一方接收到 FIN，它会发送一个 RST 数据包，指示另一方发生了错误。
如果有一个路由器在做 NAT，尤其是一个资源很少的低端路由器，它将首先老化最旧的 TCP 会话。为此，它RST在数据包中设置标志，有效地告诉接收站（非常不礼貌地）关闭连接。这样做是为了节省资源。
如果连接空闲 x 分钟，某些防火墙会这样做。一些 ISP 也出于各种原因将其路由器设置为这样做。
在当今时代，您需要优雅地处理（根据需要重新建立）这种情况。
需要注意的一件事是许多 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 无效 -j DROP
最好丢弃一个数据包，然后生成一个潜在的协议中断 tcp 重置。当它们被证明是正确的发送时，重置会更好......因为这消除了超时。但是，如果它们有任何可能无效，那么它们可能会导致这种痛苦。
这是因为网络中有另一个进程向您的 TCP 连接发送 RST。
通常在以下情况下会发送 RST
在您的情况下，听起来一个进程正在连接您的连接（IP + 端口）并在建立连接后继续发送 RST。
在大多数应用程序中，套接字连接都有超时。如果在超时时间内客户端和服务器之间没有通信，则按照您的观察重置连接。一个很好的例子是一个 FTP 服务器，如果你连接到服务器，只是离开连接而不浏览或下载文件，服务器会踢掉你的连接，通常是为了让其他人能够连接。我想这就是您在连接时遇到的问题。因此，请查看服务器应用程序，如果这是您从中获取重置的位置，并查看它是否确实为源代码中的连接设置了超时。