Resumo

  • A RFC 675 observou que identificadores de porta escolhidos de forma independente podiam colidir; somar o endereço do TCP deu ao socket alcance entre redes interligadas.
  • Uma conexão era identificada pelo par de sockets das pontas, permitindo que um socket local participasse de várias conexões distintas.
  • As especificações posteriores colocaram endereçamento de hosts e despacho de protocolo no IP, enquanto o transporte manteve portas de processo. Os documentos não dizem quando todas as implementações adotaram esse modelo.

A porta não resolvia o alcance sozinha

Uma porta não precisa ser única no planeta. Basta distinguir processos dentro do sistema que interpreta o número. A RFC 675, publicada em dezembro de 1974, explicitou esse limite: sistemas operacionais, TCPs e usuários escolhiam identificadores de porta independentemente, então dois valores podiam coincidir. O problema não era necessariamente o número escolhido, mas pedir que um nome local identificasse algo fora do próprio escopo.

Imagine dois TCPs diferentes usando o mesmo valor. O número sozinho não informa a qual TCP, nem a qual rede conectada, o tráfego deve chegar. Por isso, a RFC 675 combinou o endereço de Internet que identifica um TCP com o identificador da porta. O nome de socket resultante deveria ser único em todas as redes interligadas. A solução da especificação foi acrescentar o escopo que faltava, em vez de supor que cada porta local fosse única no mundo. RFC 675, §2.7

A camada de Internet assumiu o endereço de rede

A especificação TCP de 1980 descreveu portas dentro de cada host e sua combinação com os endereços de rede e de host da camada de Internet para formar um socket. O par de sockets continuou identificando a conexão, e um socket podia participar de várias conexões. A RFC 761 também diz que cada host administra de modo independente a associação entre portas e processos. RFC 761, §§1.4 e 2.7

A especificação IP correspondente colocou o endereçamento de hosts e a escolha do protocolo no cabeçalho de Internet. Os endereços indicavam os hosts de origem e destino; um campo de protocolo identificava o protocolo do nível seguinte. A RFC 791 manteve esse campo separado, e o glossário da RFC 793 definiu o socket TCP como endereço de Internet combinado a uma porta TCP. Em conjunto, esses textos situam a alcançabilidade da rede e o despacho ao próximo protocolo no IP, e a seleção do processo no transporte. RFC 760, §§1.1 e 3.1 · RFC 791, §3.1 · RFC 793, §3.1 e glossário

A especificação UDP mostra a divisão em outro transporte. Ela define portas de origem e destino, enquanto a interface UDP/IP obtém do cabeçalho IP os endereços de Internet e o campo de protocolo. Uma porta faz sentido no contexto de endereço e transporte; não é um número universal que nomeia uma aplicação em todas as redes e protocolos. RFC 768, “Fields” e “IP Interface”

O par de pontas identificava a conexão

É tentador usar “socket” como sinônimo de “conexão”, mas o texto de 1974 distingue os dois. Uma conexão é especificada pelo par de sockets em suas pontas. O mesmo socket local pode participar de várias conexões com sockets estrangeiros diferentes; os dados seguem nos dois sentidos. Não é preciso reservar cada nome local para uma conversa permanente, porque a outra ponta completa a identificação.

Esse par explica por que uma porta local pode ser reutilizada sem apagar a distinção entre conexões. Um serviço pode conversar com vários pares remotos, cada um com uma combinação própria de pontas. A RFC descreve uma interface de protocolo; não afirma que um socket autentique uma pessoa, comprove a posse de uma máquina ou permaneça atribuído para sempre.

Há também uma fronteira prática. A especificação define o nome do ponto de extremidade, mas cada host cuida da associação entre suas portas e os processos locais. Nomear uma ponta através de redes e decidir qual processo local recebe os dados são decisões conectadas, porém diferentes.

O nome marcava a fronteira entre camadas

O socket da RFC 675 resolveu um problema de coordenação sem exigir uma autoridade global de alocação de portas. Ele tornou um número útil localmente legível além do TCP que o escolheu, acrescentando o endereço necessário para distinguir as pontas. As especificações seguintes tornaram mais explícita a divisão: IP identifica hosts e o próximo protocolo; portas de transporte selecionam processos; o par de nomes nas pontas descreve uma conexão.

Essa é uma história dos limites estabelecidos nos documentos, não a prova de uma data de migração uniforme nem de adoção universal. Os RFCs indicam onde os campos ficam e o que compõe o nome de uma conexão, mas não mostram quais redes implantaram cada versão nem a representação interna de cada sistema operacional. A conclusão sustentada é mais estreita: uma porta só identifica um serviço local dentro de seu contexto, e o alcance da conexão depende das duas pontas e de seus endereços de rede.

Fontes e limites

Os registros primários são RFC 675, RFC 760, RFC 761, RFC 768, RFC 791 e RFC 793. Eles demonstram o texto e os termos das especificações, não sua adoção, uma cronologia de implantação, autenticação, identidade permanente de máquinas ou comportamento operacional atual.