客户端被杀死或崩溃时内核发送的 TCP RST答案

【问题标题】：TCP RST sent by kernel when client is killed or crashed客户端被杀死或崩溃时内核发送的 TCP RST
【发布时间】：2017-11-05 19:45:18
【问题描述】：

我有一个客户端和服务器在同一台服务器（Linux 机器）上运行，它们之间有 TCP 连接。我观察到当我杀死客户端时，内核/操作系统在客户端被杀死后正好 2 秒后发送 RST 数据包。我的问题是哪个内核参数 os Socket 选项控制这个计时器（2 秒）？

【问题讨论】：

【解决方案1】：

RST 通常不会在正常连接终止的对等方之间发送。 FIN 是。当您终止客户端时，会在连接上发送一个FIN 以向服务器指示客户端将不再发送任何数据。

但是服务器显然没有注意它在客户端被杀死时收到的FIN（即它需要在套接字上尝试一个recv并适当地反应到最后-of-file 指示它将获得——通常这意味着close 它自己的套接字）。随后，服务器尝试将send 数据发送给客户端，但连接已关闭。那是导致发送RST 数据包的原因。

RST 意味着（大致）“没有可用的活动连接来接收您发送的数据；发送更多是没有意义的。”

因此RST 的时间可能基于服务器下一次尝试send 到客户端的时间，而不是任何内核/操作系统配置设置。如果服务器没有尝试send并且它没有close，则连接应该永远闲置在那里，并且不会发送RST。

【讨论】：

随机笔记。如果被杀死的客户端在 Windows 上运行，则 Windows 不会发送该 FIN。如果您尝试发送到套接字，它仍然会给您 RST。另一个注意事项。客户端半关闭是完全合法的，即发送其 FIN，但仍接收服务器可能发送的内容。因此，从客户端获得 FIN 并不一定意味着所有表现良好的服务器都必须停止发送。最后要注意的是，有 TCP 超时，它很长（几小时），但肯定不是永远的。因此，即使在最后的情况下，这种联系最终也会消失。
当你杀死一个客户端时，Windows 肯定会发送一个 FIN。在进程退出时，Windows 会关闭所有打开的文件和套接字（就像大多数操作系统一样）。这将导致发送 FIN（FIN 由操作系统而不是应用程序发送）。
您是正确的，接收 FIN 不会阻止进一步发送。半封闭连接有各种有趣的用途。
AFAIK 没有 TCP 不活动超时。您可以选择设置 keepalives，但默认情况下没有会话超时。两个对等方可以保持空闲会话打开数天或数周而无需发送数据。各种交换机、路由器、防火墙和 NAT 可能会施加空闲会话超时，但这不是 TCP 本身。如果您不这么认为，我会很高兴看到对 RFC 的引用。

【解决方案2】：

正如UNIX Network programming Volume 1 Section Generic socket options 中提到的，如果客户端被杀死，TCP 将通过连接发送一个 FIN。

【讨论】：