Résumé

  • Avec le cookie remis auparavant par le serveur, RFC 7413 autorise un client à joindre des données applicatives au SYN et le serveur à les traiter avant la fin de la poignée de main.
  • Le mécanisme peut économiser un aller-retour, mais les données du SYN peuvent être livrées plusieurs fois ; une opération qui ne tolère pas ce rejeu ne doit pas l'utiliser.
  • L'exploitation exige donc des clés de cookie maîtrisées, une limite du travail non confirmé, une mémoire des échecs par chemin et un repli fiable vers TCP classique.

Dans TCP classique, le premier paquet ouvre une conversation ; il ne devrait pas encore en porter la conséquence applicative. TCP Fast Open brouille volontairement cette séparation. Le paquet qui demande « pouvons-nous établir cette connexion ? » peut déjà contenir « voici ma première requête ». Sur un chemin compatible, le serveur peut la remettre à l'application sans attendre le troisième paquet de la poignée de main.

RFC 7413 a été publié en décembre 2014 comme spécification expérimentale, et non comme norme Internet. Ce statut importe : le document propose un échange mesurable entre délai et sémantique. Il ne promet ni déploiement universel ni résultat identique sur tous les chemins. Son ambition est plus étroite : gagner jusqu'à un aller-retour sur les connexions nouvelles lorsque la première unité applicative est assez petite et que le service peut accepter les risques associés.

Le gain n'est pas offert au premier contact. Le client demande d'abord un cookie Fast Open dans une connexion ordinaire. Le serveur fabrique un tag d'authentification opaque et le renvoie dans son SYN-ACK. Le client le met en cache. Lors d'une connexion suivante, il renvoie le cookie avec des données dans le SYN. Si le cookie est valide, le serveur peut acquitter le SYN et les données, remettre celles-ci à l'application et répondre avant la fin de la poignée de main. Sinon, il ignore les données précoces et poursuit la séquence TCP normale.

Ce cookie atteste une joignabilité récente ; il n'authentifie ni un utilisateur ni une transaction. RFC 7413 prévoit de 4 à 16 octets et recommande un MAC lié à l'adresse IP source. Le client n'en interprète pas le contenu. Le serveur choisit la clé, sa durée de vie, le moment de l'expiration et, éventuellement, une période où plusieurs clés restent valides. Une rotation trop brutale détruit le gain par des rejets ; une rotation trop large prolonge une preuve ancienne. La politique de clé devient donc un élément de disponibilité.

La rupture sémantique centrale est le rejeu. La poignée de main TCP protège notamment contre de vieux SYN qui réapparaissent après la disparition de l'état qui les expliquait. En livrant les données du SYN avant la fin de cette vérification, Fast Open accepte qu'un premier message puisse parvenir plusieurs fois à l'application. Le document interdit donc une activation par défaut et exige une décision explicite par port de service.

Une lecture peut souvent être répétée sans changer l'état durable. Une création, un débit ou une requête POST non protégée ne le peut pas. Un identifiant transactionnel au niveau applicatif peut détecter un doublon ; le cookie Fast Open, lui, ne garantit jamais une exécution exactement unique. L'équipe qui gagne du temps dans la couche transport doit démontrer que l'application sait reconnaître la répétition.

L'anticipation augmente aussi l'exposition du serveur. Avant la confirmation complète de l'adresse du client, une requête peut consommer du processeur, de la mémoire et préparer une réponse. RFC 7413 impose un plafond de requêtes Fast Open en attente. Lorsque ce plafond est dépassé, le serveur doit désactiver le traitement rapide des nouvelles demandes et revenir au SYN classique. Le mécanisme de sécurité n'est donc pas seulement le cookie : c'est aussi la faculté de cesser d'y croire sous pression.

Le chemin garde enfin un droit de veto. Des pare-feu et boîtiers intermédiaires peuvent supprimer un SYN porteur de données ou d'une option inconnue. Après expiration du temporisateur, le client doit pouvoir retransmettre un SYN sans données ni option Fast Open. Les réponses négatives — refus des données, erreur ICMP ou absence totale de SYN-ACK — doivent être mémorisées. RFC 7413 recommande de désactiver temporairement l'optimisation pour la combinaison d'adresses et de ports concernée.

Cette mémoire négative est une partie du chemin rapide. Sans elle, chaque nouvelle connexion répète un délai d'échec avant de revenir à TCP. Avec elle, un incident transitoire ne doit toutefois pas devenir une exclusion permanente. L'exploitation doit donc savoir quand inscrire un chemin, quand réessayer et comment distinguer une incompatibilité stable d'une perte ordinaire.

L'histoire de TCP Fast Open montre ainsi qu'une latence supprimée ne disparaît pas : elle se transforme en état et en responsabilité. Le service doit qualifier les opérations rejouables, gouverner ses clés, plafonner le travail avant confirmation et tester le repli. RFC 7413 n'a pas seulement avancé quelques octets ; il a rendu visible le contrat nécessaire pour agir avant que la connexion soit pleinement établie.

Sources