设置 TCP 空闲超时时需要考虑什么？

Question

具有 [low] TCP 空闲超时的目的是什么？例如，为什么在防火墙或负载平衡器上有 60 秒的超时？它是内存管理还是/性能优化？高超时是否涉及安全风险？

如何确定合适或可接受的最大设置？

Answer 1

长时间空闲连接可能意味着连接已断开（任一方应用程序崩溃、网络电缆拔出等），但资源仍会分配，这意味着：

• 性能会受到轻微影响。
• 您的应用程序可能有 X 个同时连接的限制，因此，您可能会拒绝对实际上没有连接的新客户端的访问。
• 如果您对源和目标都使用固定端口，则可能无法重新连接客户端（有点不常见，但可能）。
• 您可能会达到连接/路由限制，从而阻碍与任何其他端口的新连接或导致意外行为或服务器本身崩溃。
• 许多应用程序只有在所有连接正确关闭后才会停止，因此关闭或重新启动服务将花费更长的时间
• 如果不检查 TPC 流量一段时间或依赖应用程序日志，您将无法区分断开的连接和活动的连接
• 大多数客户端应用程序不知道如何对断开的连接做出反应：有些将等待内部超时，但其他应用程序将永远等待，如果客户端需要重新启动，则会导致潜在的数据丢失。

如果您设置的 TCP 空闲超时低于所需的值，也会发生最后一种情况，因为某些系统会简单地从 TCP 表中删除连接，而其他系统则会向另一部分发送 RST 数据包。

根据您管理的流量类型使用空闲超时（例如，Apache 服务器的默认超时为 5 分钟，因此任何连接的空闲时间都不会超过 5 分钟[和几秒钟]），但切勿建立较低的超时（或者完全相同）TCP 空闲超时比应用程序的超时。至少每隔几分钟在长时间连接上实施保活，以确保连接处于活动状态（在套接字创建时定义的 TCP 保活有两个小时的超时，我认为这个超时太高了）。当用户阅读时，用户交互软件（如 ssh 会话、远程桌面、FTP）会空闲几分钟，所以我不会使用少于 15 分钟的时间。

注意：我不建议任何低于几分钟的 TCP 空闲超时，除非空闲时间不会超过几秒钟的高度密集连接。如果可能，请根据您的流量设置不同的空闲超时（即 Web 服务器为 6 分钟，ssh 会话为 15 分钟等）。

如果需要更高的超时（有人请求“永久”TCP 连接），请尝试在应用程序层使用 keepalive。