不过，我完全糊涂了。这里有什么安全优势？

没有什么。最可能的情况是介于 5 分钟后连接超时以节省资源。这可能是防火墙、WAN 加速器、SSL 加速器等。或者它可能只是一个糟糕的默认设置。谁知道？

网络管理员通常与其他人有不同的担忧，这往往会与其他人发生冲突。我们在一个孤立的世界中工作，没有考虑整体情况。

不要假设每个设置都有一个特别好的理由，但要留出空间，让 5 分钟超时可以快速解决他们遇到的其他问题，而您的应用程序问题是反冲的。

这听起来像是安全“货物崇拜”的一个很好的例子。在不了解所涉及的上下文或确实正确实施的情况下，盲目地实施了安全控制。

一般来说，在安全性方面，空闲超时点是为了降低客户端机器无人看管和恶意用户进入机器并在其上执行未经授权的命令的风险。这些超时的平衡往往是可用性（有利于更长或没有超时）和安全性（有利于更短的超时）之一。

您有时可以准确地发现安全货物崇拜，即系统的操作员实际上正在帮助您绕过名义控制（在您的情况下，建议使用保活）

不过，我完全糊涂了。这里有什么安全优势？

这可能不是安全问题，但有不同的原因。不幸的是，您的问题仅提供您的观点，因此我们只能推测真正的原因可能是什么。

一种解释可能是有一个简单的有状态数据包过滤器，其中状态在 120 秒不活动后超时。这意味着在此不活动之后传输的任何数据都将被阻止，因为不再有打开状态。造成这种情况的原因可能是设备资源非常有限，因此不能同时保持太多状态打开，例如防火墙设计时考虑了 10 个用户，但现在有 100 个用户使用。

当然，也可能是BOFH正在运行该系统，这可能更符合您对这个问题的看法 :) 但如果不深入了解实际系统，这很难说清楚。

您可能已经注意到，这与安全性无关。相反，杀死长期休眠的 TCP 连接的做法与错误有关——这是一种解决错误软件的方法。

使 TCP 会话挂起的软件最著名的例子之一是 Internet Explorer（至少到版本 7）。IE 习惯于不正确结束 TCP 会话，因此在客户端 PC/笔记本电脑/电话上，套接字被认为是关闭的，服务器仍然认为连接是打开的。而 IE 只是比较知名的例子之一。那里有很多错误的软件。

那么服务器为什么要关心呢？因为每个打开的套接字也是一个打开的文件描述符。不处理这种情况会导致服务器用完文件描述符。从理论上讲，服务器也可以用完套接字 ID，但这个数字远远高于操作系统可以处理的打开文件描述符的数量。

正因为如此，TCP 堆栈的各种实现包括死套接字超时。在某些操作系统上，您可以配置此超时。