Quantas conexões de soquete um servidor da web pode manipular?

Digamos que se eu quisesse ter uma hospedagem compartilhada, virtual ou dedicada, li em algum lugar que um servidor / máquina só pode lidar com 64.000 conexões TCP por vez, isso é verdade? Quantas qualquer tipo de hospedagem pode lidar, independentemente da largura de banda? Estou assumindo que o HTTP funciona sobre o TCP.

Isso significaria que apenas 64.000 usuários poderiam se conectar ao site e, se eu quisesse servir mais, teria que mudar para um web farm?

Resumindo: você deve ser capaz de alcançar na ordem de milhões de conexões TCP ativas simultâneas e, por extensão, solicitação (ões) HTTP. Isso indica o desempenho máximo que você pode esperar com a plataforma certa com a configuração certa.

Hoje, eu estava preocupado se o IIS com ASP.NET ofereceria suporte na ordem de 100 conexões simultâneas (veja minha atualização, espere cerca de 10 mil respostas por segundo em versões mais antigas do ASP.Net Mono). Quando vi esta pergunta / respostas, não pude resistir a responder a mim mesmo, muitas respostas para a pergunta aqui estão completamente incorretas.

Melhor caso

A resposta a esta pergunta deve se preocupar apenas com a configuração de servidor mais simples para desacoplar das inúmeras variáveis ​​e configurações possíveis downstream.

Portanto, considere o seguinte cenário para minha resposta:

1. Nenhum tráfego nas sessões TCP, exceto para pacotes keep-alive (caso contrário, você obviamente precisaria de uma quantidade correspondente de largura de banda de rede e outros recursos do computador)
2. Software projetado para usar soquetes e programação assíncronos, em vez de um thread de hardware por solicitação de um pool. (ou seja, IIS, Node.js, Nginx ... servidor da web [mas não Apache] com software de aplicativo projetado assíncrono)
3. Bom desempenho / CPU / Ram em dólares. Hoje, arbitrariamente, digamos i7 (4 núcleos) com 8 GB de RAM.
4. Um bom firewall / roteador para combinar.
5. Sem limite / governador virtual - ou seja. Linux somaxconn, IIS web.config ...
6. Sem dependência de outro hardware mais lento - sem leitura do disco rígido, porque seria o menor denominador comum e gargalo, não IO de rede.

Resposta Detalhada

Projetos síncronos vinculados a threads tendem a ter o pior desempenho em relação às implementações de E / S assíncronas.

O WhatsApp obtém um milhão de tráfego COM em uma única máquina com sistema operacional Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

E, finalmente, este, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , apresenta muitos detalhes , explorando como até 10 milhões poderiam ser alcançados. Os servidores geralmente têm mecanismos de descarregamento de TCP de hardware, ASICs projetados para essa função específica com mais eficiência do que uma CPU de uso geral.

Boas opções de design de software

O projeto de IO assíncrono será diferente entre os sistemas operacionais e plataformas de programação. Node.js foi projetado com assíncrono em mente. Você deve usar Promises pelo menos, e quando o ECMAScript 7 aparecer, async/ await. C # /. Net já tem suporte assíncrono completo, como node.js. Qualquer que seja o sistema operacional e a plataforma, deve-se esperar que o assíncrono funcione muito bem. E qualquer que seja o idioma que você escolher, procure a palavra-chave "assíncrona", a maioria dos idiomas modernos terá algum suporte, mesmo que seja algum tipo de complemento.

Para a WebFarm?

Qualquer que seja o limite para sua situação particular, sim, um web farm é uma boa solução para o dimensionamento. Existem muitas arquiteturas para fazer isso. Uma é usar um balanceador de carga (os provedores de hospedagem podem oferecer isso, mas mesmo esses têm um limite, junto com o teto de largura de banda), mas não sou a favor dessa opção. Para aplicativos de página única com conexões de longa duração, prefiro ter uma lista aberta de servidores que o aplicativo cliente escolherá aleatoriamente na inicialização e reutilizará durante a vida útil do aplicativo. Isso remove o ponto único de falha (balanceador de carga) e permite o dimensionamento em vários data centers e, portanto, muito mais largura de banda.

Acabando com um mito - portas de 64K

Para abordar o componente da pergunta sobre "64.000", isso é um equívoco. Um servidor pode se conectar a mais de 65535 clientes. Consulte /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

A propósito, o Http.sys no Windows permite que vários aplicativos compartilhem a mesma porta do servidor no esquema de URL HTTP. Cada um deles registra uma ligação de domínio separada, mas, em última análise, há um único aplicativo de servidor que faz o proxy das solicitações para os aplicativos corretos.

Atualização 30/05/2019

Aqui está uma comparação atualizada das bibliotecas HTTP mais rápidas - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

• Data do teste: 06/06/2018
• Hardware usado: Dell R440 Xeon Gold + 10 GbE
• O líder tem aproximadamente 7 milhões de respostas em texto simples por segundo (respostas, não conexões)
• O segundo Fasthttp para golang anuncia 1,5 milhões de conexões simultâneas - consulte https://github.com/valyala/fasthttp
• As linguagens principais são Rust, Go, C ++, Java, C e até mesmo C # classifica em 11 (6,9 milhões por segundo). Scala e Clojure são classificados mais abaixo. Python ocupa a 29ª posição com 2,7 milhões por segundo.
• No final da lista, noto laravel e cakephp, rails, aspnet-mono-ngx, symfony, zend. Tudo abaixo de 10k por segundo. Observe que a maioria dessas estruturas são construídas para páginas dinâmicas e, bastante antigas, podem haver variantes mais novas que aparecem no topo da lista.
• Lembre-se de que este é um texto simples HTTP, não para a especialidade do Websocket: muitas pessoas que vêm aqui provavelmente estarão interessadas em conexões simultâneas para websocket.

Esta pergunta é bastante difícil. Não há limitação real de software no número de conexões ativas que uma máquina pode ter, embora alguns sistemas operacionais sejam mais limitados do que outros. O problema passa a ser de recursos. Por exemplo, digamos que uma única máquina deseja oferecer suporte a 64.000 conexões simultâneas. Se o servidor usar 1 MB de RAM por conexão, precisará de 64 GB de RAM. Se cada cliente precisar ler um arquivo, a carga de acesso ao disco ou ao storage array torna-se muito maior do que esses dispositivos podem suportar. Se um servidor precisar bifurcar um processo por conexão, o sistema operacional passará a maior parte do tempo trocando de contexto ou privando de processos pelo tempo de CPU.

A página de problemas do C10K tem uma discussão muito boa sobre esse assunto.

Para adicionar meus dois centavos à conversa, um processo pode ter simultaneamente aberto um número de soquetes conectados igual a este número (em sistemas de tipo Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Este número pode ser modificado em tempo real (apenas pelo usuário root, é claro)

echo 1024> / proc / sys / net / core / somaxconn

Mas depende inteiramente do processo do servidor, do hardware da máquina e da rede, o número real de soquetes que podem ser conectados antes de travar o sistema

Parece que a resposta é pelo menos 12 milhões se você tiver um servidor robusto, seu software de servidor for otimizado para isso, você tiver clientes suficientes. Se você testar de um cliente para um servidor, o número de números de porta no cliente será um dos limites de recursos óbvios (cada conexão TCP é definida pela combinação única de IP e número de porta na origem e no destino).

(Você precisa executar vários clientes, caso contrário, você atingirá o limite de 64 K em números de porta primeiro)

No fundo, este é um exemplo clássico do gracejo de que "a diferença entre teoria e prática é muito maior na prática do que na teoria" - na prática, atingir os números mais altos parece ser um ciclo de a. propor alterações específicas de configuração / arquitetura / código, b. teste-o até atingir um limite, c. Eu terminei? Se não, então d. descobrir qual era o fator limitante, e. volte ao passo a (enxágue e repita).

Aqui está um exemplo com 2 milhões de conexões TCP em uma caixa robusta (128 GB de RAM e 40 núcleos) executando Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - eles terminaram precisando de cerca de 50 servidores razoavelmente significativos apenas para fornecer a carga do cliente (seus clientes menores iniciais atingiram o limite máximo, por exemplo, "maximizaram nossa caixa de 4 núcleos / 15 gb @ 450k clientes").

Aqui está outra referência para ir desta vez em 10 milhões: http://goroutines.com/10m .

Parece ser baseado em java e 12 milhões de conexões: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

Observe que o HTTP normalmente não mantém as conexões TCP abertas por mais tempo do que leva para transmitir a página ao cliente; e normalmente leva muito mais tempo para o usuário ler uma página da web do que para baixar a página ... enquanto o usuário está visualizando a página, ele não adiciona carga ao servidor.

Portanto, o número de pessoas que podem estar visualizando seu site simultaneamente é muito maior do que o número de conexões TCP que ele pode atender simultaneamente.

no caso do protocolo IPv4, o servidor com um endereço IP que escuta em apenas uma porta pode lidar com 2 ^ 32 endereços IP x 2 ^ 16 portas, portanto 2 ^ 48 soquetes exclusivos. Se você fala sobre um servidor como uma máquina física e é capaz de utilizar todas as 2 ^ 16 portas, pode haver no máximo 2 ^ 48 x 2 ^ 16 = 2 ^ 64 soquetes TCP / IP exclusivos para um endereço IP. Observe que algumas portas são reservadas para o sistema operacional, portanto, esse número será menor. Resumindo:

1 IP e 1 porta -> 2 ^ 48 soquetes

1 IP e todas as portas -> 2 ^ 64 soquetes

todos os soquetes IPv4 exclusivos do universo -> 2 ^ 96 soquetes

Existem duas discussões diferentes aqui: Uma é quantas pessoas podem se conectar ao seu servidor. Este foi respondido adequadamente por outros, então não vou entrar nisso.

Outro é quantas portas seu servidor pode escutar? Eu acredito que é daí que veio o número 64K. Na verdade, o protocolo TCP usa um identificador de 16 bits para uma porta, que se traduz em 65536 (um pouco mais de 64K). Isso significa que você pode ter tantos "ouvintes" diferentes no servidor por endereço IP.

Acho que o número de conexões de soquete simultâneas que um servidor da web pode manipular depende muito da quantidade de recursos que cada conexão consome e da quantidade de recursos total disponível no servidor, exceto qualquer outra configuração de limitação de recurso do servidor da web.

Para ilustrar, se cada conexão de soquete consumisse 1 MB de recursos do servidor e o servidor tivesse 16 GB de RAM disponível (teoricamente), isso significaria que ele só seria capaz de lidar com conexões simultâneas (16 GB / 1 MB). Acho que é tão simples como isso ... REALMENTE!

Portanto, independentemente de como o servidor da web lida com as conexões, cada conexão consumirá algum recurso.