负载平衡网络插座 [英] Loadbalancing web sockets

问题描述

我有一个有关如何平衡Web套接字负载的问题.

我有一台支持Web套接字的服务器.浏览器连接到我的网站，每个浏览器都打开一个www.mydomain.com的Web套接字.这样，我的社交网络应用可以将消息推送到客户端.

传统上，我只使用HTTP请求，就可以通过在两个Web服务器之前添加第二台服务器和一个负载均衡器来进行扩展.

使用Web套接字，连接必须直接与Web服务器连接，而不是直接与负载均衡器连接，因为如果一台计算机的物理限制为64k个开放端口，并且客户端正在连接到负载均衡器，则我无法不支持超过64k的并发用户.

那我怎么-

1. 让客户端在页面加载时直接连接到Web服务器(而不是负载平衡器)吗?我是否只是从节点加载JavaScript，然后每次最初请求页面时，负载均衡器(或其他负载)都会随机修改脚本的URL?

2. 处理波纹开始?浏览器将注意到，随着Web服务器关闭，连接已关闭.我可以编写JavaScript代码来尝试重新打开连接，但是该节点将消失一会儿.所以我想我将不得不回到负载均衡器来查询要使用的下一个节点的地址?

3. 我确实想知道负载均衡器是否在初始请求上发送了重定向，以便浏览器最初请求www.mydomain.com并被重定向到www34.mydomain.com.在节点失效之前，这种方法非常有效，而Facebook之类的网站则无法做到这一点.他们是如何做到的?

解决方案

放置一个L3负载均衡器，该负载均衡器将基于源IP端口哈希的IP数据包分发到WebSocket服务器场.由于L3平衡器不保持任何状态(使用散列的源IP端口)，它将在低端硬件(例如10GbE)上扩展到线速.由于分布是确定性的(使用散列的源IP端口)，因此可以与TCP(以及WebSocket)一起使用.

还请注意，对于给定的(源)IP地址，64k硬限制仅适用于传出的 TCP/IP.它不适用于传入的TCP/IP.我们已经测试了高速公路(一种高性能的WebSocket服务器)，它在2核，4GB RAM VM上具有200k活动连接. >

还请注意，您可以在初始WebSocket握手期间宣布的HTTP路径上进行L7负载平衡.在那种情况下，负载均衡器必须维持状态(哪个源IP端口对将到达哪个后端节点).尽管如此，通过适当的设置，它可能会扩展到数百万个连接.

免责声明:我是高速公路的原始作者，并且为Tavendo工作.

I have a question about how to load balance web sockets.

I have a server which supports web sockets. Browsers connect to my site and each one opens a web socket to www.mydomain.com. That way, my social network app can push messages to the clients.

Traditionally, using just HTTP requests, I would scale up by adding a second server and a load balancer in front of the two web servers.

With web sockets, the connection has to be directly with the web server, not the load balancers, because if a machine has a physical limit of say 64k open ports, and the clients were connecting to the load balancer, then I couldn't support more than 64k concurrent users.

So how do I -

1. get the client to connect directly to the web server (rather than the load balancer) when the page loads? Do I simply load the JavaScript from a node, and the load balancers (or whatever) randomly modifies the URL for the script, every time the page is initially requested?

2. handle a ripple start? The browser will notice that the connection is closed as the web server shuts down. I can write JavaScript code to attempt to reopen the connection, but the node will be gone for a while. So I guess I would have to go back to the load balancer to query the address of the next node to use?

3. I did wonder about the load balancers sending a redirect on the initial request, so that the browser initially requests www.mydomain.com and gets redirected to www34.mydomain.com. That works quite well, until the node goes down - and sites like Facebook don't do that. How do they do it?

解决方案

Put a L3 load-balancer that distributes IP packets based on source-IP-port hash to your WebSocket server farm. Since the L3 balancer maintains no state (using hashed source-IP-port) it will scale to wire speed on low-end hardware (say 10GbE). Since the distribution is deterministic (using hashed source-IP-port), it will work with TCP (and hence WebSocket).

Also note that a 64k hard limit only applies to outgoing TCP/IP for a given (source) IP address. It does not apply to incoming TCP/IP. We have tested Autobahn (a high-performance WebSocket server) with 200k active connections on a 2 core, 4GB RAM VM.

Also note that you can do L7 load-balancing on the HTTP path announced during the initial WebSocket handshake. In that case the load balancer has to maintain state (which source IP-port pair is going to which backend node). It will probably scale to millions of connections nevertheless on decent setup.

Disclaimer: I am original author of Autobahn and work for Tavendo.

这篇关于负载平衡网络插座的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！