65536 +1 Conexão em um sistema

Existem 65536 portas para todos os sistemas da rede e todas as conexões ou envio / recebimento usarão uma delas.

Minha pergunta é: o que acontece se tivermos 65536 + 1 conexões ?!

Eu sei que isso não acontece da maneira normal, mas estou curioso para saber como os Sistemas Operacionais lidam com isso.

networking operating-systems

— Omid Golparvar
fonte

A conexão seria recusada. Mas você realisticamente terá problemas muito antes de 65535 abrir conexões.

— ChrisInEdmonton

@ChrisInEdmonton Não. Se for uma conexão de saída, receberá um erro de ligação, pois não pode alocar uma porta local. Se for uma conexão de entrada, o limite da porta não se aplica.

— user207421

se a conexão for recebida, você receberá uma conexão recusada; se for de saída, sua chamada de soquete terá erro. Não vou colocar isso como resposta, porque não tenho certeza.

— Jorge Aldo

Esteja ciente de que um sistema pode lidar com mais de 65536 conexões simultâneas, porque cada uma delas não necessariamente usa uma porta separada.

Uma conexão TCP ou fluxo UDP é definida pela 4-tupla:

(source IP address, source port, destination IP address, destination port)

Portanto, mesmo se você tiver uma máquina de servidor da Web com apenas um único endereço IP e um único pacote de software de servidor HTTP ouvindo apenas na porta 80, teoricamente, ele poderia lidar com 65536 conexões por endereço IP do cliente conectado a ela . Portanto, conexões de 64Ki do endereço IP do cliente 1, mais conexões de 64Ki do endereço IP do cliente 2, etc.

Portanto, os protocolos suportam, em uma primeira aproximação, 2 ⁴⁸ conexões / fluxos para uma única porta TCP ou UDP em um único endereço IPv4. Considere o TCP e o UDP juntos, o espaço de endereço do IPv4 e o espaço de endereço cósmico / cômico grande do IPv6. Você pode ver que os próprios protocolos provavelmente nunca serão a fonte do limite para o número de conexões simultâneas que um host pode aguentar.

Da mesma forma, não há nada nos protocolos TCP ou UDP que impeça uma máquina cliente de usar uma única porta de origem em um único endereço IP para fazer várias conexões de saída para vários endereços e portas do servidor. Às vezes, as APIs de rede de um determinado sistema operacional podem não facilitar isso, mas é importante lembrar que, digamos, a antiga e venerável API "[BSD] Sockets" é apenas uma API para TCP e UDP. TCP e UDP podem ter recursos que não são expostos pela API tradicional de soquetes.

Portanto, o número de conexões TCP ou fluxos UDP simultâneos que um determinado host pode manipular é limitado não tanto pelos números de portas, mas pelos recursos do sistema, como o espaço de RAM e o tempo de CPU necessário para acompanhar todas essas conexões e atendê-las a todos. Os detalhes específicos da implementação de um sistema operacional também podem impor limites artificiais. Por exemplo, na filosofia "tudo é um arquivo" do Unix, pode haver um descritor de arquivo para cada conexão TCP ou fluxo UDP. Se o seu kernel do Unix tem um limite para o número de descritores de arquivos que ele pode acompanhar, esse limite de descritor de arquivo é um limite artificial para o número de conexões TCP simultâneas ou fluxos UDP que o kernel pode suportar.

— Spiff
fonte

Pode valer a pena vincular a en.wikipedia.org/wiki/C10k_problem nesta excelente resposta.

— 22415 ChrisInEdmonton

Eu implementei um servidor TCP que poderia acomodar 65.534 conexões de todos os endereços IP possíveis simultaneamente. Ele não faz muito - ele simplesmente reproduz o texto recebido com algumas substituições de caracteres - mas é executado em uma plataforma de hardware muito pequena. Eu não acho que seja totalmente compatível com RFC, mas parece funcionar muito bem, apesar de não saber nem se importar com quantas conexões TCP estão abertas na maioria de suas portas.

— Supercat

Se você realmente precisar conectar mais de 65536 conexões entre duas máquinas, poderá configurar as máquinas para usar vários endereços IP. Cada endereço IP adicionado às duas máquinas aumenta o número máximo de conexões quadraticamente (pelo menos em teoria, é mais provável que você encontre outros problemas primeiro).

— Lie Ryan