TCP连接流失是什么意思？

Question

在web服务的上下文中，我使用过术语“TCP连接流失”。特别是Twitter finagle有办法避免它发生。它是如何发生的？这是什么意思？

Answer 1

这个术语可能有多种用途，但我总是看到它在很短的时间内进行很多TCP连接的情况下使用，从而导致客户端和服务器上的性能问题。

当客户端代码被写入时，通常会发生这种情况，该代码会自动连接到任何类型的TCP故障。如果在连接失败之前（或者在协议交换中很早）出现连接失败，那么客户端可能会进入一个接近繁忙的循环，不断进行连接。这可能会导致客户端的性能问题 - 首先，在非常繁忙的循环中会有一个进程吸入CPU周期，其次，每次连接尝试都会消耗一个客户端端口号 - 如果速度足够快，软件可以环绕当它们达到最大端口号时（因为端口只有16位数，这当然不是不可能的）。

虽然编写健壮的代码是一个有价值的目标，但这种简单的“自动重试”方法有点太天真了。您可以在其他情况下看到类似的问题 - 例如一个父进程不断重启一个立即崩溃的子进程。避免这种情况的一种常见机制是某种增加的后退。所以，当第一次连接失败时，您立即重新连接。如果在短时间内（例如30秒）再次失败，则等待重新连接前2秒钟。如果在30秒内再次失败，则等待4秒钟，以此类推。阅读the Wikipedia article on exponential backoff（或this blog post可能更适合此应用程序）以获取有关此技术的更多背景信息。

此方法的优点是不会压倒客户端或服务器，但这也意味着客户端仍可以在无人工干预的情况下恢复（这对于无人参与的服务器上的软件尤其重要，例如，或者大型集群）。

在恢复时间很关键的情况下，TCP连接创建的简单速率限制也是很有可能的 - 可能不会超过每秒1次。但是，如果每台服务器的客户端数量众多，这种更简单的方法仍然会使服务器受到负载的影响而关闭较高的连接速率。

如果您计划采用指数回退，我会建议一个最大等待时间，或者您可能会发现，一旦服务器端再次开始接受连接，长时间的故障会使客户端花费很长时间来恢复。在大多数情况下，我会建议像5分钟这样的合理的最大值，但当然这取决于应用程序。