Encontrei a resposta mais detalhada à minha pergunta no StackOverflow .
com os websockets e conexões TCP persistentes, como os balanceadores de carga vão lidar com o limite de portas de 64k se estiverem lidando com um grande farm de servidores no backend? precisar. someideas em configurar o infra para um aplicativo que pode. potencialmente tem 100k conexões.
Encontrei a resposta mais detalhada à minha pergunta no StackOverflow .
Sua pergunta parece assumir um balanceador de carga de conversão SNAT (também conhecido como NAPT). Aqui estão algumas idéias sobre como resolver o problema das portas efêmeras de 64k. Minha experiência é com o produto BIG-IP da F5 Networks (assim os links são para o site deles), mas os conceitos são os mesmos para outros fornecedores:
Não faça SNAT. Se as portas de origem não forem traduzidas, não haverá limite de 64k. Para desativar o SNAT, você precisa ter o endereço interno do balanceador de carga definido como a rota (geralmente a rota padrão) nos servidores internos.
Use um SNAT Pool . Isso disponibiliza um pool de endereços IP internos para o balanceador de carga. Por exemplo, dois endereços IP em um pool SNAT fornecerão portas efêmeras de 128k para 128k conexões TCP simultâneas.
Abordagens mais avançadas:
Devo salientar que os Websockets são um desafio especial para os balanceadores de carga HTTP tradicionais, já que as conexões duram muito mais tempo - as pessoas deparam-se com o problema de portas efêmeras quando podem nunca tê-lo antes. Na minha opinião, a melhor solução é aquela que remove o requisito SNAT (primeira ou terceira soluções acima). A escala é muito melhorada e a carga no balanceador de carga é reduzida. A complexidade adicional vale a pena.
Aqui está um bom artigo sobre a questão, da Lori MacVittie da F5: HTML5 Web Sockets altera o jogo de escalabilidade
Tenha em mente que um soquete é uma tupla de endereço sec / dst, portas src / dst e protocolo e, como tal, o número de permutações é muito maior que 64k. Há algumas situações nas quais as conexões de saída em servidores proxy podem ter problemas com base em implementações específicas, mas a numeração de porta não tem sido um grande problema tradicionalmente.
Eu sei que esta pergunta é antiga, mas eu tenho algumas coisas para adicionar no caso de outra pessoa pesquisar "WebSockets Load Balancer" ...
WebSockets não precisam de balanceadores de carga. Lá eu disse isso. A razão é que os navegadores não fazem conexões WebSocket de saída até que após a página seja carregada.
Então, se a página já está sendo carregada e você tem acesso para executar o JavaScript, por que, no mundo, você precisaria de um balanceador de carga nesse ponto? Você não faria. Você pode fazer algo simples, como escolher uma conexão ws: // ou wss: // aleatoriamente a partir de uma matriz ou obter uma chamada AJAX que retorne um determinado servidor WebSocket para se conectar. Você pode até colocar o URL do WebSocket na página do código do lado do servidor por meio de um modelo.
Ampliar aplicativos WebSocket é trivial ... Basta adicionar mais servidores. Sempre que você fizer isso, basta adicioná-los à sua lista de conexões de saída. Eles podem estar localizados em qualquer parte do mundo - mesmo em diferentes domínios / origens!
WebSockets também não possuem restrições de origem cruzada de URLs HTTP (S) comuns. Faça uma conexão com wss: //foo.com do link . Vai funcionar bem! Apenas sobre todos os problemas tradicionais associados com o dimensionamento de aplicações web foram resolvidos com WebSockets. Você pode até mesmo entregar CSS, imagens, JavaScript e qualquer outra coisa no WebSocket assim que a conexão for estabelecida (e armazenar esses arquivos localmente no navegador agora também!). Relegando balanceadores de carga e coisas como CDNs obsoletos.
Tags load-balancing