我有一个客户端和服务器在同一台Linux机器上运行，并且它们之间有TCP连接。 我观察到，当我杀死客户端时，内核/操作系统会在客户端被杀死后的确切两秒钟后发送RST数据包。 我的问题是哪个内核参数或Socket选项控制这个计时器（2秒）？
2个回答
2
在正常的连接终止中，对等方通常不会发送
RST，而是发送FIN。当你关闭客户端时，会在连接上发送一个FIN，以向服务器指示客户端将不再发送任何数据。但是，当客户端被关闭时，服务器显然没有注意到接收到的FIN（即它需要尝试在套接字上进行recv，并适当地对其将获得的文件结束指示做出反应--通常意味着close自己的套接字）。随后，服务器尝试向客户端send数据，但连接已关闭。这导致发送RST数据包。 RST的意思是（大致）：“没有可用的活动连接来接收您正在发送的数据；发送更多数据是无意义的。” 因此，RST的时间很可能基于服务器下一次尝试向客户端send，而不是任何内核/操作系统配置设置。如果服务器既不尝试send也不close，则连接应该永远处于空闲状态，不会发送RST。- Gil Hamilton
4
随机笔记。如果被关闭的客户端正在运行Windows，则Windows不会发送该FIN。如果您尝试发送到套接字，则仍会给您RST。另一个注意事项。客户端半关闭是完全合法的，也就是说，发送它的FIN，但仍然接收服务器可能发送的内容。因此，从客户端获取FIN并不一定意味着所有表现良好的服务器都必须停止发送。最后一个注意事项是，有TCP超时时间，它很长（几个小时），但肯定不是永远。因此，即使在最终情况下，连接也将最终消失。 - user7610
当你杀死一个客户端时，Windows肯定会发送一个FIN。在进程退出时，Windows关闭所有打开的文件和套接字（就像大多数操作系统一样）。这将导致发送一个FIN（FIN是由操作系统而不是应用程序发送的）。 - Gil Hamilton
你说得对，收到FIN并不会阻止进一步发送。半关闭连接有各种有趣的用途。 - Gil Hamilton
据我所知，TCP没有不活动超时。您可以选择设置保持活动状态，但默认情况下没有会话超时。两个对等方可以保持空闲会话数天甚至数周，而不发送数据。各种交换机、路由器、防火墙和NAT可能会强制执行空闲会话超时，但这不是TCP本身的功能。如果您认为有误，请提供RFC参考文献。 - Gil Hamilton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
kill -9 <client_pid>来终止它。因此，客户端将没有时间关闭套接字。 - rohitsoren