Resumo

  • No TCPMUX, o cliente se conectava à porta TCP 1 e só então informava o serviço desejado. Uma resposta positiva liberava o início do protocolo na mesma conexão.
  • Um programa privado podia usar essa entrada sem receber uma porta oficial própria. Isso não dispensava nomes compatíveis, configuração local nem a manutenção das portas dos serviços já existentes.
  • O inetd podia responder positivamente em nome do programa. A aceitação na entrada não comprovava autenticação, funcionamento da aplicação ou conclusão do pedido.

A linha de configuração que ainda não abre a porta

Uma máquina pode ter um serviço TCPMUX descrito em sua configuração e, mesmo assim, não estar aceitando pedidos na entrada comum. O manual do FreeBSD exige ativar o próprio multiplexador, além dos serviços que dependem dele. Esse detalhe operacional mostra que nome, programa e ponto de acesso são peças diferentes, embora um inventário apressado possa tratá-las como uma só.

A origem dessa separação está em RFC 1078, publicado em novembro de 1988. M. Lottor propôs o TCP Port Service Multiplexer para que vários serviços fossem encontrados por uma porta TCP compartilhada. O cliente chegava à porta 1 e enviava um nome, encerrado por retorno de carro e avanço de linha. Maiúsculas e minúsculas não alteravam a identificação do serviço.

A resposta começava com um sinal de mais ou de menos, podia trazer uma explicação e terminava com os mesmos caracteres de fim de linha. Com uma resposta positiva, começava o protocolo escolhido. Com uma negativa, a conexão era fechada. Não era preciso receber outro endereço e abrir uma segunda conexão: a conversa seguia no canal já estabelecido.

O termo multiplexador merece cuidado. A especificação não oferecia vários fluxos de aplicação simultâneos dentro de uma conexão, com mensagens intercaladas e identificadores próprios. Ela reunia as opções no ponto de encontro e escolhia uma para cada conexão. O ganho estava no acesso comum, não na execução concorrente de protocolos sobre o mesmo fluxo de bytes.

O que a numeração resolvia antes disso

Uma porta conhecida permite que programas independentes concordem sobre onde iniciar uma conversa. Sem um ponto de contato compartilhado, cada cliente precisaria de informação adicional para cada servidor. A atribuição de números era, portanto, uma forma de reduzir o custo de encontrar serviços, não uma observação sobre o estado de cada máquina.

RFC 1010, a edição de Assigned Numbers de maio de 1987 citada pelo TCPMUX, registra essa função. O documento reúne valores e orienta desenvolvedores a procurar a coordenação responsável quando precisam de uma atribuição. A tabela ajuda implementações diferentes a usar o mesmo número com o mesmo significado.

RFC 1078 descrevia os números bem conhecidos de sua época na faixa de 0 a 255. Não se deve ler isso como se TCP só tivesse 256 portas possíveis. A faixa então tratada como conjunto de contatos reconhecidos não era o campo inteiro de porta do protocolo. Também não corresponde à classificação usada hoje.

Para um protocolo privado, talvez não fosse necessário repetir o processo de obter um contato oficial exclusivo. Se cliente e servidor já podiam combinar um nome, uma única entrada comum bastava para encaminhar o pedido. A partir daí, uma tabela da própria máquina escolheria o executável. O que antes poderia parecer uma nova decisão de numeração global passava a ser uma decisão local de oferta de serviço.

Essa autonomia não criava acesso automático. O operador ainda precisava disponibilizar a entrada, definir o programa, escolher sua identidade de execução e aplicar controles de uso. O cliente precisava conhecer o nome e entender o protocolo seguinte. Compartilhar uma porta não fabricava confiança nem obrigava outras máquinas a oferecer o mesmo serviço.

Compatibilidade também limita quem muda

TCPMUX não autorizava retirar as portas anteriores. Serviços que já possuíam atribuições distintas deveriam continuar disponíveis nelas. O acesso pela porta 1 era adicional e facultativo. Assim, a introdução da nova convenção não convertia todos os clientes instalados em participantes obrigatórios.

A razão aparece no primeiro instante da conversa. Um cliente antigo poderia esperar uma saudação imediata da aplicação; o multiplexador esperava primeiro o nome. Redirecionar esse cliente para a porta comum, sem adaptar o início do diálogo, não resolvia a diferença. Os dois lados poderiam permanecer à espera.

Os nomes já definidos em Assigned Numbers também mantinham seus significados. Para serviços privados, a proposta recomendava reduzir a chance de colisão, por exemplo usando um prefixo com o nome da organização. Um sufixo podia distinguir versões. São práticas de nomenclatura, não uma verificação da identidade de quem apresenta o nome.

O nome reservado HELP produzia uma lista dos serviços disponíveis, um por linha, e encerrava a conexão. Isso permitia consultar as opções oferecidas por aquele host. Não era um catálogo global, uma autorização para usar todos os itens ou um laudo sobre a capacidade atual de cada programa concluir uma operação.

A diferença importa porque uma lista pode parecer mais definitiva do que é. O fato de o operador anunciar um nome não significa que qualquer cliente entenda sua versão. A presença de uma opção tampouco comprova que o processo não falhará após ser iniciado. O menu é uma informação de seleção, e sua utilidade depende de permanecer nessa categoria.

Quem assume o sinal de mais

O manual do inetd no NetBSD explica a busca do nome na tabela fornecida por /etc/inetd.conf. Ele também distingue tcpmux/, em que o servidor invocado deve enviar a resposta positiva, de tcpmux/+, em que o multiplexador responde em seu lugar. A segunda forma facilita o uso de programas antigos que leem da entrada padrão e escrevem na saída padrão.

Esse pequeno recurso de adaptação altera a evidência disponível ao cliente. Uma aceitação pode ter sido produzida pelo componente que seleciona o programa, e não pelo programa que realizará o trabalho. Por isso, receber o sinal de mais não é o mesmo que comprovar que a aplicação já está pronta para tudo o que virá a seguir.

Mesmo uma aceitação emitida pela própria aplicação ainda antecede o resultado do pedido. Ela pode exigir credenciais, recusar uma operação ou encerrar depois de um erro. Seleção, autenticação e conclusão são etapas diferentes, com responsáveis e modos de falha distintos.

Também é necessário combinar quem envia a primeira resposta. Se os dois componentes responderem, bytes extras podem chegar à interpretação da aplicação; se cada um esperar que o outro faça isso, o cliente pode não receber nada. Esses são riscos deduzidos da divisão de funções, não relatos de incidentes que as fontes tenham documentado.

A fonte do manual do inetd no FreeBSD descreve tanto a ativação separada do multiplexador quanto a entrega da conexão pelos descritores de entrada e saída do programa. O texto apresenta o recurso como útil para servidores desenvolvidos localmente. Isso confirma uma possibilidade implementada, sem demonstrar quantos operadores a habilitaram.

Os manuais tornam visível o lugar onde a escolha ganha efeito: a configuração local. O registro público conserva o significado do ponto de encontro; o operador decide qual processo está atrás do nome. Confundir essas funções atribuiria ao cadastro um poder que ele não exerce sobre a execução da máquina.

A cautela necessária ao contar essa história

Em 2011, RFC 6335 documentou as faixas de portas de sistema, de 0 a 1023; de usuário, de 1024 a 49151; e dinâmicas, de 49152 a 65535. O documento admite registrar um nome de serviço sem uma porta fixa. A separação entre identidade convencional e número de contato continuava sendo uma opção real de projeto.

RFC 7605, de 2015, discute como evitar atribuições desnecessárias, inclusive usando informações dentro do protocolo para distinguir versões e encaminhar comunicações. É um contexto posterior para a mesma família de problemas. Não prova que TCPMUX tenha sido a origem direta das recomendações.

O registro de serviços e portas da IANA ainda lista tcpmux na porta 1. Há linhas para TCP e UDP, mas a troca descrita por RFC 1078 é TCP. A existência da linha UDP não fornece uma conversa de datagramas que o texto nunca definiu.

Também não se pode transformar uma linha preservada no registro em contagem de uso. Publicação da especificação, suporte documentado, configuração ativa e tráfego observado são evidências diferentes. O conjunto de fontes permite descrever o desenho e seus limites; não oferece uma participação de mercado nem uma causa única de eventual desuso.

TCPMUX ajuda a enxergar uma decisão arquitetural sem precisar de uma narrativa de vitória. Era possível manter uma convenção compartilhada pequena e deixar novas escolhas com quem operava os programas. Mas a liberdade só era útil se o cliente entendesse a entrada e se ninguém confundisse o aceite do nome com o resultado da aplicação.