Résumé

  • Lors d’une ouverture simultanée, les deux pairs lancent un OPEN actif vers la même paire de sockets. Les SYN nus se croisent, chaque pile passe en SYN-RECEIVED, puis les SYN-ACK croisés produisent une seule connexion.
  • La coordination ne dépend pas d’un arbitre qui nommerait client et serveur. Chaque pair vérifie localement le numéro initial de l’autre et reçoit l’accusé de réception du sien.
  • Des NAT ont ensuite codé le scénario courant « SYN sortant, SYN-ACK entrant » comme s’il épuisait TCP. RFC 5382 a dû leur imposer de respecter aussi l’arrivée d’un SYN sur une connexion déjà autorisée.

Le client et le serveur n’étaient pas des castes

RFC 793 distingue bien l’ouverture passive de l’ouverture active. Mais il affirme aussi que deux processus qui s’ouvrent activement l’un vers l’autre au même moment seront correctement connectés. Cette souplesse était jugée critique pour des composants distribués dont les actions ne sont pas synchronisées par une autorité commune.

Le schéma classique en trois flèches n’était donc qu’un cas fréquent. Il ne conférait pas au premier pair une qualité permanente de demandeur ni au second un monopole de l’accueil. TCP exigeait des preuves de séquence, pas une hiérarchie sociale.

Cette nuance disparaît facilement dans le vocabulaire. « Serveur » décrit souvent l’application, « écoute » un état local et « réponse » l’ordre observé. Aucun de ces mots ne suffit à définir la connexion sur le réseau.

Deux appels, une seule association

Imaginons A avec le numéro initial 100 et B avec 300. A émet un SYN à 100 et entre dans SYN-SENT. B fait la même chose à 300. Les segments se croisent. À la réception du SYN nu de B, A n’y voit pas un concurrent à sa propre tentative. Il mémorise 300, passe en SYN-RECEIVED et renvoie SYN-ACK avec l’accusé 301. B effectue l’opération miroir et accuse 101.

Lorsque ces deux SYN-ACK se croisent, chaque pair dispose des deux faits nécessaires : il connaît le départ de la séquence distante et sait que l’autre a reçu le sien. RFC 9293 conserve ce trajet : CLOSED, SYN-SENT, SYN-RECEIVED, puis ESTABLISHED des deux côtés.

Le nombre d’appels système n’est pas le nombre de connexions. RFC 1122 prévient expressément les implémenteurs : deux tentatives simultanées créent une connexion, et il ne faut pas « corriger » cette décision intentionnelle. La paire de sockets vue dans des sens opposés désigne la même association.

Le SYN occupait une place dans le temps logique

Un SYN consomme un numéro de séquence. L’accusé 301 ne signifie donc pas seulement « j’ai vu quelque chose venant de B » ; il certifie que le contrôle situé à 300 appartient désormais au passé reçu. Un ACK vide, lui, ne consomme aucune place : autrement les pairs devraient accuser les accusés sans fin.

Chaque côté garde son espace d’émission. La symétrie de l’initiative ne mélange pas les compteurs. RFC 6528 a plus tard renforcé le choix des numéros initiaux avec une fonction pseudo-aléatoire secrète liée au quadruplet d’adresses et de ports. La rencontre reste symétrique, les origines numériques demeurent indépendantes et difficiles à deviner.

Voilà le cœur de l’accord : des éléments localement vérifiables suffisent. Nul registre de session et nul chef de rendez-vous ne doit déclarer qui a le droit d’être le premier.

L’état devait garder la mémoire de son chemin

Deux connexions peuvent afficher SYN-RECEIVED tout en venant d’histoires différentes. L’une répond à un OPEN passif ; l’autre a reçu un SYN après son propre OPEN actif. RFC 1122 et RFC 9293 exigent de conserver cette provenance, car la réaction à un reset et le retour éventuel à l’écoute en dépendent.

RFC 793 signalait déjà une ambiguïté plus ancienne : un vieux SYN dupliqué peut ressembler au début d’une ouverture simultanée. La solution n’est pas d’interdire les SYN croisés. Les numéros attendus, les accusés et la validation des resets permettent de distinguer le rendez-vous courant d’un reste d’une incarnation précédente.

Réduire l’état à une étiquette fait perdre cette distinction. Le diagramme devient plus simple, mais la machine ne sait plus pourquoi elle se trouve là. Dans un protocole de reprise, l’histoire est parfois une donnée présente.

Le NAT transforma une habitude en grammaire

L’arrivée des NAT plaça un observateur à état au milieu de la connexion. Pour le cas client-serveur ordinaire, un SYN sortant crée une traduction, puis un SYN-ACK entrant la confirme. Beaucoup de produits apprirent ce parcours dominant et traitèrent le SYN entrant d’une ouverture simultanée comme du trafic non sollicité.

RFC 5382 décrit les deux pannes typiques : blocage du SYN entrant ou mauvaise traduction du SYN-ACK sortant. Les hôtes suivent pourtant la machine TCP, et le NAT a déjà créé un contexte à partir du SYN local.

Une politique de filtrage peut légitimement refuser une connexion. Mais si elle l’autorise, un suivi d’état fidèle doit comprendre toutes ses transitions valides. Confondre « interdit » et « ordre de paquets inhabituel » déplace une décision d’architecture dans une optimisation de firmware invisible.

RFC 5382 exige donc la prise en charge de l’ouverture simultanée pour les connexions permises. Il ne supprime pas la politique du NAT ; il borne son interprétation du protocole.

Six secondes pour ne pas prétendre connaître l’avenir

Le cas limite survient lorsque le SYN distant arrive avant que le SYN local ait franchi le NAT et créé la traduction. À cet instant, le paquet paraît réellement non sollicité. Un reset immédiat donne une erreur rapide, mais condamne le rendez-vous si le SYN local retardé arrive un instant plus tard.

La norme choisit une attente minimale de six secondes. Si le SYN sortant correspondant apparaît, le NAT abandonne silencieusement le premier paquet et la retransmission distante pourra utiliser la traduction. Sinon, une erreur peut être envoyée sous réserve de la politique de sécurité.

Cette attente matérialise le prix de l’incertitude. La réponse rapide optimise les échecs certains ; la patience préserve les succès encore possibles. Un intermédiaire ne voit qu’un fragment temporel et doit éviter de convertir cette ignorance en verdict irréversible.

Le pair-à-pair redonna une utilité à la symétrie

Lorsque deux machines se trouvèrent derrière des traducteurs, aucune ne pouvait toujours recevoir directement une ouverture. Chacune pouvait toutefois produire un état sortant vers l’autre. Avec les bonnes adresses, ports et temporalités, les SYN se rencontraient à travers ces ouvertures préparées.

RFC 6544 intégra cette possibilité dans ICE TCP sous la forme d’un candidat S-O, à côté des candidats actifs et passifs. Le document recommande plusieurs techniques et des relais, parce que la validité TCP ne garantit ni l’API du système, ni le comportement du NAT, ni la politique du pare-feu.

L’ouverture simultanée n’est donc pas une baguette universelle de traversée. Elle est une possibilité d’extrémité que l’environnement peut préserver ou étouffer. L’échec d’un chemin direct ne prouve pas que TCP l’interdit ; il localise souvent la restriction dans les systèmes adjacents.

La leçon durable : vérifier sans distribuer les rôles

TCP fixe un petit noyau commun : identité de la paire, numéros initiaux distincts, accusés vérifiables et transitions définies. Le choix d’appeler, d’écouter ou d’essayer les deux reste local. Cette combinaison permet une coordination sans autorité permanente au-dessus des pairs.

Le NAT a montré comment la convention peut devenir pouvoir. Le scénario majoritaire fut implémenté comme norme totale, puis les autres acteurs durent s’adapter à une restriction qui ne figurait pas dans TCP. RFC 5382 rétablit une frontière saine : l’intermédiaire décide ce qu’il permet, mais ne réécrit pas silencieusement la grammaire de ce qu’il permet.

Quand les deux côtés appelèrent, TCP ne demanda pas lequel méritait de gagner. Il demanda à chacun de démontrer ce qu’il avait envoyé et reçu. La connexion unique naquit de ces preuves partagées, non d’un titre préalable.

Sources et limites de preuve

RFC 793, RFC 1122, RFC 5382, RFC 6528, RFC 6544 et RFC 9293 fondent cette reconstruction. Ils ne mesurent ni l’usage actuel, ni toutes les API, ni la conformité de tous les NAT. Les pertes et retransmissions peuvent aussi modifier la trace sans changer la logique.