Resumen

  • RFC 675 advertía que identificadores de puerto elegidos por separado podían coincidir; añadir la dirección del TCP daba al socket alcance entre redes conectadas.
  • Una conexión era el par de sockets de sus extremos, por lo que un socket local podía participar en muchas conexiones distintas.
  • Las especificaciones posteriores situaron el direccionamiento de hosts y la selección del protocolo en IP, mientras el transporte conservaba los puertos de proceso. Los documentos no indican cuándo adoptaron el modelo todas las implementaciones.

IP tomó a su cargo la dirección y el siguiente protocolo

La especificación TCP de 1980 describió puertos dentro de cada host y los combinó con las direcciones de red y de host de la capa de Internet para formar un socket. El par de sockets seguía identificando una conexión; un mismo socket podía usarse en varias. RFC 761 también dice que cada host gestiona por separado la asociación de puertos con procesos. RFC 761, §§1.4 y 2.7

La especificación IP asociada colocó el direccionamiento de hosts y la selección del protocolo en la cabecera de Internet. Sus direcciones identificaban los hosts de origen y destino; un campo de protocolo indicaba el protocolo del nivel siguiente. RFC 791 conservó ese campo separado, y el glosario de RFC 793 definió el socket TCP como una dirección de Internet unida a un puerto TCP. En conjunto, los textos ubican la alcanzabilidad de red y la selección del protocolo en IP, y la elección del proceso en el transporte. RFC 760, §§1.1 y 3.1 · RFC 791, §3.1 · RFC 793, §3.1 y glosario

UDP muestra la separación desde otro transporte. Su especificación define campos de puerto de origen y destino, mientras la interfaz UDP/IP obtiene las direcciones de Internet y el campo de protocolo de la cabecera IP. Así, un puerto cobra sentido dentro de un contexto de dirección y transporte; no es un número universal que nombre una aplicación en todas las redes y protocolos. RFC 768, «Fields» e «IP Interface»

La pareja de extremos explica la reutilización

Es fácil usar «socket» como sinónimo de «conexión», pero RFC 675 no lo hace. La conexión queda especificada por el par de sockets situados en sus extremos. Un socket local puede participar en muchas conexiones con distintos sockets extranjeros, y los datos circulan en ambos sentidos. Por tanto, no hace falta reservar cada nombre local para una conversación permanente: el otro extremo completa la descripción.

El par es la clave. Si un servicio escucha en un extremo local, pueden acercarse varios pares remotos. Las conexiones siguen siendo distinguibles porque cambia el par, aunque se reutilice el socket local. El RFC describe una interfaz de protocolo; no afirma que un socket autentique a una persona, pruebe quién posee una máquina ni permanezca asignado indefinidamente.

También deja visible una frontera operativa. La especificación define cómo se nombra el extremo, mientras que cada host gestiona la asociación entre sus puertos y sus procesos locales. Nombrar un extremo entre redes y decidir qué proceso local recibe el tráfico son tareas relacionadas, pero distintas.

RFC 675 respondió al límite que dejaba el puerto

Un puerto no tenía que ser único en todas partes. Debía distinguir procesos dentro del sistema que lo interpretaba. RFC 675, publicado en diciembre de 1974, dejó claro ese límite: los sistemas operativos, los TCP y los usuarios elegían identificadores de puerto de forma independiente, así que dos valores podían coincidir. El problema no era necesariamente una mala elección del número; era pedirle que identificara algo fuera de su ámbito.

Imaginemos dos TCP distintos que usan el mismo valor. El número, por sí solo, no indica a cuál de ellos, ni a cuál de las redes conectadas, hay que dirigirse. RFC 675 combinó por ello la dirección de Internet que identifica un TCP con el identificador de puerto. El nombre de socket resultante debía ser único en el conjunto de redes conectadas. La especificación respondió a una colisión de nombres añadiendo el alcance que faltaba, en lugar de fingir que cada puerto local era único en todo el mundo. RFC 675, §2.7

El nombre marcaba el límite entre capas

El socket de RFC 675 resolvió un problema de coordinación sin pedir un registro global de puertos. Hizo que un número útil localmente pudiera leerse más allá del TCP que lo había elegido, incorporando el alcance necesario para distinguir los extremos. Las especificaciones posteriores hicieron más explícita la división del trabajo: IP identificaba hosts y el protocolo siguiente, los puertos de transporte seleccionaban procesos y un par de nombres de extremo describía una conexión.

Esta es una historia de límites en las especificaciones, no la prueba de una fecha de migración precisa ni de adopción universal. Los RFC indican dónde iban los campos y qué contenía un nombre de conexión. No demuestran qué red desplegó cada versión ni cómo lo representaba internamente un sistema concreto. La lección es más acotada: un puerto solo identifica un servicio local en su contexto, mientras que el alcance de la conexión procede de ambos extremos y sus direcciones de red.

Fuentes y límites

Los registros primarios son RFC 675, RFC 760, RFC 761, RFC 768, RFC 791 y RFC 793. Demuestran el texto y la terminología de las especificaciones; no prueban adopción, una cronología de despliegue, autenticación, identidad duradera de una máquina ni el comportamiento operativo actual.