我可以期望客户端/服务器 TCP 连接在野外持续多长时间？
我希望它保持永久连接，但是发生了一些事情，所以客户端必须重新连接。我在什么时候说代码有问题而不是某些外部设备有问题？
【问题讨论】：
标签： tcp
我认为这里最重要的想法是理论与实践。
最初的理论是连接没有生命周期。如果您有连接，即使没有流量，它也会永远保持打开状态，直到某个事件导致它关闭。
新理论是大多数操作系统版本都打开了保持活动计时器。这意味着连接将永远持续下去，只要另一端的系统响应偶尔的 TCP 级交换。
实际上，随着时间的推移，许多连接会因各种标准和情况而终止。
两个非常好的例子是：远程客户端使用 DHCP，租约到期，IP 地址更改。
另一个例子是防火墙，它似乎越来越智能，可以识别保持活动流量与真实数据，并根据任何高级标准（尤其是空闲时间）关闭连接。
您希望如何实现重新连接逻辑在很大程度上取决于您的架构、工作环境和您的性能目标。
【讨论】：
我同意 Zan Lynx 的观点。无法保证，但假设没有连接或带宽问题，您可以通过在其上发送数据几乎无限期地保持连接。
一般来说，我选择了应用程序级别的 keep-alive 方法，尽管这通常是因为它已经在客户端规范中，所以我不得不这样做。但只需每分钟或两分钟发送一些简短的数据，您希望得到某种确认。
您是否将一次失败视为连接失败由您决定。通常这是我过去所做的，尽管有一个案例我连续等待三个失败的响应以断开连接，因为连接另一端的应用程序在响应“你在吗”时非常不稳定？”请求。
如果连接失败，在某些时候它可能会失败，即使机器在同一个网络上，然后尝试重新建立它。如果失败了一定次数，那么你就有问题了。如果您的连接在连接一段时间后仍然持续失败，那么您就有问题了。在这两种情况下，最有可能的是一些网络问题，而不是你的代码，或者你机器上的 TCP/IP 堆栈有问题（已知：我在旧版本的 QNX 上遇到了这个问题——它会只是随机摔倒）。话虽如此，您可能遇到了软件问题，唯一确定的方法通常是附加调试器，或者在那里进行一些登录。例如。如果您始终可以成功连接，但一段时间后您停止收到 ACK，即使在重新连接后也是如此，那么您的服务器可能处于死锁状态，或者陷入循环或其他问题。
真正有用的是在各种负载条件下设置一系列长时间运行的测试，从仅发送 keep alive are you there?/ack 请求和响应，到彻底破坏服务器。这通常会让您对您的软件组件更有信心，并且对于消除一些非常奇怪的问题非常有用，这些问题不一定会导致您的连接出现问题，尽管它们可能会导致发生的事务出现问题。例如，我曾经写过一个电信应用服务器，它提供诸如号码转换之类的服务，而我们只是让它一次运行几天。问题是，当周六到来时，一整天，它会拒绝每一个打进来的电话请求，这相当于数百万个电话，我们不知道为什么。原来是因为某个日期转换代码中的一个拼写错误，只在星期六引起了问题。
希望对您有所帮助。
【讨论】：
您需要定期通过连接传输一些数据以使其保持活动状态 - 许多操作系统或防火墙会断开非活动连接。
【讨论】：
选择一个值。每小时一滴可能没问题。 5 分钟内意外断开 10 次连接可能表明存在问题。
TCP 连接通常会持续大约两个小时而没有任何流量。任何一端都可以发送保持活动的数据包，我认为这只是最后收到的数据包的 ACK。这通常可以在每个套接字上设置，也可以在每个 TCP 连接上默认设置。
应用程序级别的保持活动也是可能的。对于 FTP、SMTP、POP 或 IMAP 之类的 telnet 样式协议，例如发送返回、换行符和返回命令提示符。
【讨论】：
真的没有办法说。 TCP 本身没有任何东西会导致连接在一定时间后断开。使用可靠连接的人可能有多年的正常运行时间，而使用不同连接的人可能必须每 5 分钟重新连接一次。没有办法告诉甚至猜测。
【讨论】：
这并不重要，您应该将代码设计为自动重新连接，如果这是所需的行为。
【讨论】：