Résumé

  • RFC 675 constatait que des identifiants de port choisis séparément pouvaient entrer en collision ; l’adresse du TCP donnait au socket une portée à travers les réseaux reliés.
  • Une connexion était la paire de ses sockets d’extrémité : le même socket local pouvait ainsi participer à plusieurs connexions distinctes.
  • Les textes ultérieurs ont placé l’adressage des hôtes et le choix du protocole dans IP, tandis que le transport gardait les ports de processus. Ils ne datent pas l’adoption de ce modèle par toutes les implémentations.

La connexion se reconnaissait à ses deux extrémités

Il est facile de confondre « socket » et « connexion ». RFC 675 décrit une connexion par la paire de sockets situés à ses extrémités. Un socket local peut participer à plusieurs connexions avec des sockets étrangers différents, et les données circulent dans les deux sens. Il n’est donc pas nécessaire de réserver chaque nom local à une conversation permanente : l’autre extrémité complète la description.

Cette paire explique pourquoi la répétition d’un port local n’efface pas nécessairement la distinction entre connexions. Un service peut recevoir des demandes de plusieurs pairs ; les paires d’extrémités restent différentes même si le socket local est réutilisé. Le RFC décrit une interface de protocole. Il ne dit pas qu’un socket authentifie une personne, prouve la propriété d’une machine ou reste attribué à vie.

Le texte laisse aussi une séparation pratique. Il définit le nom du point d’extrémité, tandis que chaque hôte gère l’association de ses ports aux processus locaux. Nommer un point d’extrémité à travers des réseaux et décider quel processus reçoit le trafic sont deux tâches liées, mais différentes.

Le port local ne désignait pas tout le chemin

Un port n’avait pas besoin d’être unique partout. Il devait distinguer les processus dans le système qui l’interprétait. Publié en décembre 1974, RFC 675 rend cette limite explicite : systèmes d’exploitation, TCP et utilisateurs choisissaient indépendamment leurs identifiants de port ; deux choix pouvaient donc se recouper. Le défaut ne venait pas forcément d’un mauvais numéro, mais d’une portée trop étroite pour l’usage qu’on voulait en faire.

Imaginons deux TCP différents qui utilisent la même valeur. Le nombre seul ne permet pas de savoir à quel TCP, ni à quel réseau relié, l’on veut s’adresser. RFC 675 associe donc l’adresse Internet qui identifie un TCP à l’identifiant de port. Le nom de socket obtenu doit être unique dans l’ensemble des réseaux connectés. La spécification répond ainsi à une collision de noms : elle ajoute au port le contexte qui lui manque, au lieu de prétendre que chaque port local est mondialement unique. RFC 675, §2.7

L’adresse réseau et le port ont pris deux rôles distincts

La spécification TCP de 1980 décrit des ports à l’intérieur de chaque hôte, combinés aux adresses réseau et hôte de la couche Internet pour former un socket. Une connexion reste identifiée par une paire de sockets, et un même socket peut servir à plusieurs connexions. RFC 761 précise aussi que chaque hôte gère séparément l’association des ports aux processus. RFC 761, §§1.4 et 2.7

La spécification IP associée place l’adressage des hôtes et le choix du protocole dans l’en-tête Internet. Les adresses désignent les hôtes source et destination ; un champ protocole indique le protocole de niveau suivant. RFC 791 conserve ce champ distinct, tandis que le glossaire de RFC 793 définit le socket TCP comme une adresse Internet associée à un port TCP. Ces textes situent la joignabilité réseau et la distribution vers le prochain protocole dans IP, puis la sélection des processus dans le transport. RFC 760, §§1.1 et 3.1 · RFC 791, §3.1 · RFC 793, §3.1 et glossaire

UDP rend la séparation visible dans un autre transport. Sa spécification comporte des champs de port source et destination, tandis que l’interface UDP/IP récupère les adresses Internet et le champ protocole depuis l’en-tête IP. Un port prend donc sens dans un contexte d’adresse et de transport ; ce n’est pas un numéro universel qui nomme une application dans tous les réseaux et tous les protocoles. RFC 768, « Fields » et « IP Interface »

Le nom marquait une frontière entre couches

Le socket de RFC 675 résolvait un problème de coordination sans réclamer un registre mondial des ports. Il rendait un numéro local lisible au-delà du TCP qui l’avait choisi, en ajoutant l’adresse nécessaire pour distinguer les extrémités. Les spécifications suivantes ont explicité le partage du travail : IP identifie les hôtes et le protocole suivant, les ports de transport sélectionnent des processus, et une paire de noms d’extrémité décrit une connexion.

Il s’agit d’une histoire des limites écrites dans les spécifications, pas de la preuve d’une date de migration nette ni d’une adoption universelle. Les RFC indiquent où placer les champs et comment nommer une connexion ; elles ne disent pas quel réseau a déployé chaque version ni comment chaque système l’a représentée en interne. Leur enseignement est plus circonscrit : un port n’identifie un service local que dans son contexte, tandis qu’une connexion prend sa portée des deux extrémités et de leurs adresses réseau.

Sources et limites

Les textes primaires sont RFC 675, RFC 760, RFC 761, RFC 768, RFC 791 et RFC 793. Ils établissent le contenu et la terminologie des spécifications, pas leur adoption, une chronologie de déploiement, l’authentification, une identité durable de machine ou un comportement opérationnel actuel.