最近我一直在阅读TCP协议，因为我对使用某些标记的方式和原因有点好奇。
在我发现的信息中，我们谈到了一个正常的closuresTCP FIN应该被用来closures一个连接，但是它也谈到TCP RST可以被用来在一个活动的连接上closures一个exception终止。
我的问题是，为什么要使用RST中止/closures使用TCP FIN的活动连接？
（指的是一个活动连接作为一个连接，两个端点在标准的三次握手之后发送和接收数据，当客户端发送一个没有监听的服务器端口的SYN时，服务器可以使用RST）
你通常不会看到一个TCP RST。 我猜想第7层中止应用程序可能会生成RST，但是我认为你会发现RST通常是由两台主机之间的防火墙生成的。 以下是TCP / IP指南中可能的原因列表：
从接收该段的设备当前没有连接的任何设备（不包括请求新连接的SYN）接收任何TCP段。
接收带有无效或不正确序号或确认号码字段的消息，指示该消息可能属于先前的连接或者以其他方式伪造。
在没有进程监听连接的端口上收到SYN消息。
一些Web服务器使用RST而不是FIN来closures（持续）连接。 这被看作是一种“优化”，因为它避免了“半closures”状态，避免了一些FIN包丢失的问题（任何进一步的传输只会产生另一个RST），否则需要记住状态（2xMaximum段时间IIRC）在服务器端更长。
请参阅： 本文和维基百科关于连接终止 。 （我会尝试挖掘一些更有趣的参考）。
如果套接字应用程序崩溃（segfault？），主机重新启动，或NAT表项在连接本身之前超时，您可能还会看到RST！
这是一个边缘案例，但我觉得它很有趣：
有些过滤软件（如web sense（ab））使用RST数据包。 会发生什么事情呢，而不是所有的交通之间的websense嗅探交通线。 如果它看到一个阻塞的站点，它欺骗了一个RST数据包到客户端（我想也许是服务器）。
这更是一个聪明的把戏，然后它是一个预期的用途。