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

shr*_*000 4 scalability load-balancing tcpsocket

负载均衡器将根据其运行的平台对可以同时使用的tcp端口数量进行一些限制(例如,我在某处读取Linux可以同时打开最多65535个tcp端口).这意味着平衡器成为瓶颈,即使后端服务器场能够同时提供更多请求,也无法提供超出同时多个请求的服务.有办法克服这个问题吗?

Sco*_*amb 8

TCP和UDP端口号是16位,因此给定的IP只有65535(我相信端口0无效).但是TCP连接由4元组(源IP,源端口,目标IP,目标端口)标识.(看起来维基百科有链接了解更多信息.)

对于客户端 - >平衡器请求:只要每个入站连接具有不同的(源IP,源端口),就没有问题.客户通常会确保这一点.我回忆起这方面的唯一问题是,一个非常受欢迎的网站,当从巨大的ISP访问时,每页有许多图像,这些ISP使他们的客户在很少的IPv4地址之后.那可能不是你的情况.

平衡器 - >后端请求更有趣,因为您可能会创建与上面提到的NAT问题类似的情况.我认为Linux通常会尝试为每个套接字分配一个独特的短暂端口,默认情况下只有28,233个.而IIRC它也没有使用TIME_WAIT州内的那些,所以你可以在没有实际同时打开多个连接的情况下耗尽范围.IIRC如果达到此限制,您将EADDRINUSE失败connect(bind如果您在连接之前明确绑定套接字,则为on ).我不记得我以前是如何解决这个问题的,更不用说绝对最好的方式了,但这里有一些可能有用的东西:

  • 保持持久性平衡器 - >后端连接,而不是为每个(可能是短暂的)客户端 - >平衡器连接创建一个新连接.
  • SO_REUSEADDRbind/ 之前设置套接字connect.
  • 打开sysctl net.ipv4.tcp_tw_reuse和/或net.ipv4.tcp_tw_recycle.
  • 明确选择要使用的源IP和/或端口,bind而不是让内核自动分配connect.你不能有两个同时连接相同的4元组,但其他任何东西都没问题.(例外:我正在考虑TIME_WAIT重复使用相同的4元组是否合适;我必须TIME_WAIT通过阅读一些TCP RFC 来刷新我的记忆.)

你可能需要做一些实验.好消息是,一旦你理解了这个问题,就可以很容易地重现它并测试你是否已经修复它.