负载均衡器的可扩展性和最大#tcp端口

Question

负载平衡器将基于它运行的平台，它可以同时使用多少个tcp端口有一些限制（例如，我读了某处可以同时打开最多65535个tcp端口的Linux） 。这意味着即使后端服务器场能够同时处理更多的请求，平衡器也会成为瓶颈，并且无法超越那些同时发生的请求。有什么办法可以解决这个问题吗？

Answer 1

TCP和UDP端口号是16位的，所以给定的IP只有65535个端口（我相信端口0是无效的）。但TCP连接由4元组（源IP，源端口，目标IP，目标端口）标识。 （看起来像wikipedia有链接了解更多信息。）

对于客户机 - >平衡器请求：只要每个入站连接具有不同的（源IP，源端口），就没有问题。客户通常会确保这一点。我记得在这方面遇到的唯一问题是，当从庞大的ISP访问非常受欢迎的网站时，每页都有许多图像，这些ISP将客户NAT后面的IPv4地址很少。这可能不是你的情况。

平衡器 - >后端请求更有趣，因为你可能会创建一个类似于我上面提到的NAT问题的情况。我认为Linux通常会尝试为每个套接字分配一个不同的ephemeral port，默认情况下只有28,233个套接字。而且IIRC它不使用TIME_WAIT状态中的那个，所以你可以耗尽范围而不需要同时打开许多连接。 IIRC如果您达到此限制，您将在connect（或如果您在连接之前显式绑定套接字时在bind上）获得EADDRINUSE故障。我不记得确切我如何解决此之前，更谈不上绝对的最佳途径得到，但这里有几件事情，可以帮助：

• 保持持续balancer->后端连接，而不是创建一个新的每个（可能是短暂的）客户端 - >平衡器连接。
• 设置SO_REUSEADDR在bind/connect之前的插座上。
• 开启sysctl net.ipv4.tcp_tw_reuse和/或net.ipv4.tcp_tw_recycle。
• 明确地选择通过bind使用的源IP和/或端口，而不是让内核自动分配到connect。你不能有同一个4元组的两个同时连接，但其他任何事情都可以。 （例外：我撑船通过TIME_WAIT重复使用相同的4元组是否是好的思想，我不得不通过一些TCP RFC文档阅读，刷新了我对TIME_WAIT内存。）

你可能会必须做一些实验。好消息是，一旦你理解了这个问题，重现它并且测试是否已经修复它是相当容易的。