我最近一直在阅读有关 TCP 协议的文章，因为我有点好奇如何以及为何使用某些标志。
在我发现的信息中，它讨论了应该使用正常关闭 TCP FIN 来关闭连接，但它还讨论了可以使用 TCP RST 来中止关闭活动连接。
我的问题是，为什么要使用 RST 来中止/关闭 TCP FIN 上的活动连接？
（活动连接是指在标准三向握手之后两个端点都发送和接收数据的连接。我知道当客户端向未监听的服务器端口发送 SYN 时，服务器可以使用 RST）
答案1
您通常不会看到 TCP RST。我猜想第 7 层的应用程序中止可能会生成 RST，但我认为您会发现 RST 最常由两台主机之间的防火墙生成。以下是来自以下原因的列表：TCP/IP 指南：
从任何设备接收任何 TCP 段，但接收该段的设备当前尚未与其建立连接（请求新连接的 SYN 除外）。
收到带有无效或不正确的序列号或确认号字段的消息，表明该消息可能属于先前的连接或以其他方式伪造。
在没有进程监听连接的端口上收到 SYN 消息。
答案2
一些 Web 服务器使用 RST 而不是 FIN 来关闭（持久）连接。这被视为一种“优化”，因为它避免了“半关闭”状态并避开了一些丢失 FIN 数据包的问题（任何进一步的传输都只会产生另一个 RST），否则服务器端需要更长时间记住状态（2xMaximum 段时间 IIRC）。
看：这张纸和维基百科上有关连接终止的信息（我也会尝试挖掘出一些更有趣的参考资料）。
如果套接字的应用程序崩溃（段错误？）、主机重新启动或者在连接本身之前 NAT 表条目超时，您也可能会看见 RST！
答案3
这是一个极端的情况，但我发现它很有趣：
某些过滤软件（如 web sense）会 (ab) 使用 RST 数据包。websense 不会位于所有流量之间，而是会嗅探线路上的流量。如果它发现被阻止的站点，就会向客户端（我想也可能是服务器）伪造一个 RST 数据包。
然而，这更多的是一个聪明的技巧，而不是预期的用途。
答案4
TCP 是一种可靠的协议。因此，在 TCP 连接的整个生命周期中，消息在任何方向上都不应丢失。连接终止是最后一个部分。因此，TCP 应确保在关闭连接之前已传送所有数据包。FIN用于在每个方向上正常关闭 TCP 连接，而 TCPRST用于 TCP 连接无法从错误中恢复且需要强制重置连接的场景。根据此tcp 连接终止文章，RSET用于异常情况。