O TCP pode fornecer mais de 65535 portas?

50

É possível configurar um sistema Linux para fornecer mais de 65.535 portas? A intenção seria ter mais de 65 mil daemons ouvindo em um determinado sistema.

Claramente, há portas sendo usadas, portanto, isso não é possível por esses motivos; portanto, pense nisso como um exercício teórico para tentar entender onde o TCP seria restritivo ao fazer algo assim.

slm
fonte
11
Qual é a motivação para esta pergunta? Por que você quer ouvir tantos daemons?
Warren Young
11
Além disso, será difícil iniciar muitos processos. (Eu suponho que você quer dizer um processo por daemon.)
Warren Young
13
Embora não exista nada que o impeça de usar 65 pares de calças de uma só vez, seria idiotice prática tentar. Se você pode me mostrar uma máquina que pode processar frutuosamente 10.000 portas TCP simultaneamente, isso pode ser uma questão abstrata interessante.
msw
13
A natureza deste Q é completamente teórica, sem outra finalidade senão entender as limitações do TCP e o número de portas.
slm
11
O problema é que você o expressou de uma maneira que o vincula a várias questões práticas que envolvem o espaço de RAM exigido pelos processos de daemon de 64k +. Qualquer máquina que você provavelmente tenha agora ou na próxima década ficará sem memória RAM antes de atingir o limite do ouvinte. Se você reformular a pergunta para falar apenas sobre ouvintes de TCP , deixando totalmente a conversa sobre daemons, esse problema desaparecerá. É possível amortizar o espaço de pilha atribuindo mil soquetes a cada daemon controlado por evento de thread único, por exemplo.
22814 Warren Young

Respostas:

84

Observando a RFC para TCP: RFC 793 - Transmission Control Protocol , a resposta parece não ser devido ao fato de um cabeçalho TCP estar limitado a 16 bits para o campo da porta de origem / destino.

    ss # 1

O IPv6 melhora as coisas?

Não. Embora o IPv6 nos dê um espaço de endereço IP muito maior, 32 bits vs. 128 bits, ele não tenta melhorar a limitação do pacote TCP de 16 bits para os números de porta. Curiosamente, a RFC para IPv6: Protocolo da Internet, versão 6 (IPv6) , o campo IP precisava ser expandido.

Quando o TCP é executado no IPv6, o método usado para calcular a soma de verificação é alterado, conforme RFC 2460 :

Qualquer transporte ou outro protocolo da camada superior que inclua os endereços do cabeçalho IP em seu cálculo de soma de verificação deve ser modificado para uso em IPv6, para incluir os endereços IPv6 de 128 bits em vez dos endereços IPv4 de 32 bits.

                 ss # 2

Então, como você pode obter mais portas?

Uma abordagem seria empilhar endereços IP adicionais usando mais interfaces. Se o seu sistema possui várias NICs, isso é mais fácil, mas mesmo com apenas uma NIC, é possível fazer uso de interfaces virtuais (também conhecidas como aliases ) para alocar mais IPs, se necessário.

NOTA: O uso de aliases foi substituído pelo iproute2qual você pode usar para empilhar endereços IP em uma única interface (por exemplo eth0).

Exemplo

$ sudo ip link set eth0 up
$ sudo ip addr add 192.0.2.1/24 dev eth0
$ sudo ip addr add 192.0.2.2/24 dev eth0
$ ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Fonte: iproute2: Vida após o ifconfig

Referências

slm
fonte
3
Não seria possível selecionar entre 65.536+ daemons usando apenas a porta de destino, mas se alguém tivesse memória e largura de banda ilimitadas, poderia ter mais de 32.000 conexões com todos os endereços TCP distintos em todas as portas de entrada.
Supercat
7

É possível configurar um sistema Linux para fornecer mais de 65.535 portas?

Não.

A intenção seria ter mais de 65 mil daemons ouvindo em um determinado sistema.

Então você precisa:

  • uma iptablesconfiguração que redireciona o conteúdo do tráfego ou

  • um "serviço de intermediário de serviço" ou "serviço multiplexador" que aceitará conexões de entrada em uma única porta e a encaminhará para o daemon apropriado "atrás dela". Se você deseja que os protocolos padrão passem sem modificação, pode ser necessário implementar a detecção / reconhecimento de protocolo nesse serviço multiplexador, de maneira que um firewall IDS ou camada 7 ana-analise; completamente possível com a grande maioria dos protocolos.

No segundo item, você pode projetar esse serviço para lidar com mais de 2 ^ 16 "portas", se realmente quiser. Tenho certeza de que o impacto no desempenho será mínimo em comparação com a carga de 2 ^ 16 + ouvintes em execução.

Os daemons no Linux podem estar ouvindo nos soquetes unix existentes no sistema de arquivos, portanto, o seu "serviço multiplexador" pode manter um mapeamento interno da porta externa <-> soquete unix interno. Você provavelmente encontrará um limite de processo do kernel (processos de 32 KB)? Antes de ficar sem inodes em qualquer sistema de arquivos moderno.

LawrenceC
fonte
Eu diminuí a votação porque você diz que não é possível e, em seguida, explica como fazê-lo usando vários IPs e balanceamento de carga, embora de uma maneira indireta muito confusa.
Suprjami
2
Mais de 64K portas em um único sistema são impossíveis. Provavelmente, é possível haver mais de 64 mil ouvintes , mas você precisa ter ouvintes proxy ou de front-end que "dividam" as conexões de entrada com os ouvintes de "back-end" reais e certos. Você pode fazer algo insano como um NAT interno para vários endereços IP internos, por exemplo.
LawrenceC
2
Errado. As pessoas conseguiram obter meio milhão de conexões simultâneas em um único sistema. Sim, são necessários vários IPs e balanceadores de carga (não necessariamente no mesmo sistema), mas um único sistema pode abrir mais de 64k portas e até mais de 64k listeners, se bem feito.
Suprjami
2

Só porque não há uma boa resposta que eu queira conversar.

Uma maneira de fazer isso seria adicionar uma opção IP que especifique a extensão da porta. A opção deve ser projetada para caber na parte opcional do cabeçalho IP e seria ignorada por saltos desconhecidos.

Você usaria essa opção e suas informações para estender a origem, o destino ou os dois números de porta.

As limitações não funcionarão automaticamente no software existente apenas adicionando a opção de qualquer maneira; elas terão que ser reescritas para tirar proveito da opção, independentemente de como ela é implementada, o software e os firewalls existentes irão ignorar o pacote ou processá-lo normalmente. usando o valor nos campos da porta de origem e de destino.

Em resumo, não é fácil e seria melhor usar um único ouvinte reutilizável e dados contidos na carga útil do pacote.

Você também pode permitir mais facilmente a reutilização de portas no software, o que pode ajudar a superar essa limitação reutilizando as portas do servidor para várias conexões de clientes.

O Rtsp, por exemplo, pode usar o cabeçalho SessionId em conjunto com vários outros cabeçalhos na carga útil do pacote IP para determinar para qual conexão a solicitação foi emitida e agir de acordo, por exemplo, se o soquete do qual a mensagem foi entregue não for o mesmo do soquete. Se o endereço remoto ao qual a sessão corresponde, pode-se permitir que uma sessão seja atualizada com o novo soquete para processamento, negar a mensagem ou várias outras ações, dependendo do aplicativo.

Um servidor HTTP também pode fazer isso ou qualquer outro tipo de servidor.

A principal coisa a lembrar ao permitir a reutilização de portas é que você também deve levar em consideração o endereço IP de origem.

Jay
fonte
-2

Sim você pode !

Isso já foi feito antes, por exemplo, o servidor de criptografia Edgehill, com mais de 25.000.000 de deamons em execução online.

Corrida de touros
fonte
9
Considere expandir sua resposta para incluir algumas orientações sobre como o OP pode fazer isso, documentação que suporta sua resposta ou explicação relacionada.
HalosGhost
Você pode fornecer referências a esta declaração? Uma pesquisa rápida me faz acreditar que, seja o que for, está distribuído em muitas máquinas.
Thomas Guyot-Sionnest