Résumé

  • Le mécanisme TAO de RFC 1644 comparait le compteur de connexion d’un SYN au dernier compteur gardé pour le client. Une valeur supérieure autorisait la livraison anticipée des données au processus serveur.
  • CC.NEW annulait cette confiance après redémarrage, bouclage du compteur ou absence d’historique et imposait la poignée de main normale. CC.ECHO rattachait le SYN/ACK au compteur envoyé par le client.
  • La frontière couvrait les anciens doublons de transport, pas l’identité, l’autorisation ou le commit applicatif. RFC 6247 a ensuite classé T/TCP Historic, faute d’usage répandu et avec des problèmes de sécurité signalés.

Le cache décidait avant l’application

RFC 1644 proposait expérimentalement un TCP pour échanges courts. Le client plaçait la requête et un compteur CC de 32 bits dans le SYN initial. Le serveur conservait, pour chaque hôte client, la dernière valeur tenue pour valide.

Si le nouveau CC dépassait la valeur mémorisée, TCP Accelerated Open considérait le SYN comme nouveau, mettait le cache à jour et transmettait les données au processus utilisateur. Dans le cas contraire, le serveur ne pouvait distinguer un vieux doublon d’un segment arrivé dans le désordre : il revenait donc à la poignée de main à trois temps.

La comparaison prouvait une relation locale entre deux nombres. Sa validité dépendait de la continuité du compteur, de la durée du cache et du choix de la clé client. Elle ne démontrait pas qui contrôlait le pair ni ce que ferait ensuite le programme.

CC.NEW matérialisait la perte de continuité. Après un redémarrage ou un bouclage possible du compteur, le client signalait que l’ancien cache ne devait plus être utilisé. Le serveur invalidait l’entrée et exigeait la validation TCP ordinaire. Sur le chemin retour, CC.ECHO permettait au client de vérifier que le SYN/ACK répondait au compteur de son ouverture. Il s’agissait d’une liaison d’échange, non d’une identité cryptographique.

« Au plus une fois » restait une propriété de transport

Le texte avertissait que son mot « transaction » ne conférait pas les propriétés d’un commit applicatif. Le service visé était la livraison fiable et ordonnée, avec protection contre la répétition provoquée par un paquet de requête dupliqué. Même l’échange minimal comportait trois segments.

Une donnée remise au processus n’est pas encore une action achevée. L’application peut refuser l’autorisation, échouer au décodage, écrire partiellement, déclencher un service aval puis perdre sa réponse, ou valider durablement avant que le client ne reçoive quoi que ce soit. En cas de silence, le compteur CC ne permet pas au client de choisir entre « jamais livré », « livré mais non exécuté » et « exécuté mais réponse perdue ».

Une opération irréversible exige donc son propre identifiant, un registre de déduplication durable et un reçu du résultat sous l’autorité de l’application. Le cache transport ne peut pas porter cette responsabilité.

La portée historique doit aussi rester exacte. RFC 6247 a déplacé RFC 1644 vers Historic en indiquant que ces extensions n’avaient pas connu d’usage répandu et que des problèmes de sécurité T/TCP avaient été rapportés. La spécification TCP actuelle est RFC 9293. Le dispositif de 1994 ne prouve donc ni déploiement contemporain, ni sécurité des middleboxes, ni comportement d’un noyau actuel.

TIME-WAIT conservait ses conditions

T/TCP utilisait aussi CC pour distinguer les incarnations courtes et raccourcir TIME-WAIT. Mais la réduction ne s’appliquait qu’aux connexions inférieures au maximum segment lifetime ; les connexions longues revenaient au délai ordinaire. Quand les hypothèses de transaction cessaient de tenir, la conception rejoignait le TCP normal.

Cette modestie est la bonne lecture : un test réussi autorise une transition précise, pas une conclusion générale. Le reçu du transport et celui de l’application appartiennent à deux autorités différentes.

Sources et limites

Ces sources ne démontrent ni exécution applicative exactement une fois, ni identité authentifiée, ni déploiement actuel.