Como um balanceador de carga gira em torno do limite de porta de 64k? [duplicado]

Question

Quando uma solicitação é enviada, ela é roteada novamente para um dos vários servidores disponíveis para a solicitação. Mas há apenas 64k portas disponíveis, portanto, a qualquer momento, só pode haver solicitações de saída de 64k no máximo. Então, como alguns sites podem atender a milhões de solicitações simultâneas? Se alguém pudesse esclarecer essa confusão, seria incrível. Obrigado!

    

Answer 1

Os já vinculados Como os sites de alto tráfego atendem a mais de 65535 conexões TCP? e outras perguntas sobre o Stack Overflow explicam 5-tuplas e como isso (um pouco menos que) 64K limite é por IP - você obtém uma conexão por porta efêmera. Isso ainda se aplica a cargas de trabalho "load balancer", é uma pilha de software IP também.

Digamos que você execute um serviço na porta 443 do IP 203.0.113.80. E, de alguma forma, cada um dos 1 milhão de IPs em 172.16.0.0/12 individualmente o atinge. Portas de 64K não importam porque elas já são exclusivas por endereço IP. O cliente 172.16.0.1 também pode fazer conexões 64K e o cliente 172.16.0.2. Porque esses fluxos são diferentes:

Proto Source IP port Target IP  port
TCP 203.0.113.80 443 172.16.0.1 44321
TCP 203.0.113.80 443 172.16.0.2 44321

Na prática, o serviço de back-end e o dispositivo que interliga as conexões precisam de ajuste e aumento de escala para chegar a um milhão. Você precisa de muitos hosts e para que você ajuste suas pilhas TCP para ficar tão alto.

Normalmente, o único momento em que dezenas de milhares de conexões ocorrem entre os mesmos IPs na mesma porta é ao usar os utilitários de teste de carga. A maioria dos IPs únicos não tem trabalho suficiente para configurar milhares de conexões simultâneas.

    

Answer 2

Depende do protocolo da camada 4 envolvido.

Para UDP e outros protocolos de transporte sem conexão (UDP-Lite, RUDP, DCCP e alguns outros), isso não importa. Como não há conexão, você não precisa se preocupar com um soquete sendo persistentemente associado a um host remoto específico e, portanto, não precisa se preocupar com o fato de que os números de porta são um inteiro de 16 bits. Você acabou de enviar mensagens para o backend de destino e acompanhar o andamento das atividades. Dependendo do software de balanceamento de carga e de como ele está configurado, pode haver um limite funcional de 65536 solicitações pendentes para servidores de back-end.

Para SCTP e outros protocolos de transporte orientados a conexões com multiplexação inerente (TIPC, por exemplo, embora quase ninguém use isso), isso também não importa. Você faz exatamente uma conexão a partir do balanceador de carga para cada servidor de back-end e multiplexa apenas quantos fluxos precisar dessa conexão, porque o protocolo de transporte suporta fazer isso. A mesma coisa pode ser feita com alguns protocolos da camada de aplicação, como o HTTP / 2 (mas não o HTTP 1.1 ou anterior) ou o protocolo SSH.

Para TCP e outros protocolos de transporte orientados a conexão de fluxo único, fica um pouco mais complicado. Algumas configurações multiplexam solicitações sobre um número definido de conexões persistentes (mantendo as conexões persistentes, você economiza tempo, já que a configuração de uma conexão TCP é insanamente lenta), enquanto outras usam extensões proprietárias na camada de aplicativo para multiplexar coisas em uma única conexão.

Para qualquer um dos itens acima, há também a opção de usar várias redes de back-end, seja por meio de várias redes físicas, por meio de VLANs ou por meio de outra tecnologia de multiplexação de rede. Essa abordagem é mais comum quando os servidores de backend são máquinas virtuais, mas ainda é amplamente usada em outras situações. Por ter uma sub-rede separada para cada sistema backend, seu limite de porta de 64k vai de frontend para per-backend (ou seja, em vez de seu balanceador de carga permitir conexões ativas de 64k para todos os servidores backend, ele pode manipular 64k para cada servidor back-end), o que empurra o gargalo para o número de back-ends e o quão poderoso cada um deles é.