Résumé

  • Accepter des données 0-RTT atteste une décision de transport, pas l’unicité de l’effet métier.
  • La preuve utile relie le traitement des données précoces, le périmètre anti-rejeu, les nouvelles tentatives et la validation définitive de l’application.

Un client reprend une connexion afin de provisionner un service. Il envoie un POST avant la fin de la poignée de main. Un point de présence accepte les données précoces, mais la réponse se perd et la requête repart vers un autre point de présence. Le tableau de bord voit une connexion rapide et une réponse positive. Il ne répond pourtant pas à la question décisive : un seul service a-t-il été créé, ou deux ?

Il s’agit d’un mécanisme hypothétique, non d’un incident attribué. La frontière vient des normes elles-mêmes. La RFC 8446 autorise les données 0-RTT avec un secret de reprise partagé, tout en précisant qu’elles n’offrent aucune garantie de non-rejeu entre connexions. Dans une même connexion, un enregistrement dupliqué ne peut pas être accepté une seconde fois ; une infrastructure distribuée doit toutefois résoudre un autre problème : savoir ce qu’un autre nœud a déjà accepté.

Une protection globale suppose donc un état anti-rejeu cohérent ou une méthode équivalente. Cette coordination a un coût d’exploitation, et la RFC reconnaît que tous les déploiements ne la maintiennent pas. L’acceptation locale d’un ticket ne démontre pas qu’un second domaine d’acceptation rejettera la même opération logique.

QUIC ne supprime pas cette responsabilité. La RFC 9001 avertit que des données applicatives en 0-RTT peuvent être traitées plusieurs fois et confie au protocole applicatif la définition des usages acceptables et des mesures de réduction du risque. Une poignée de main achevée authentifie la connexion ; elle ne rend pas rétroactivement unique une action déjà lancée.

HTTP fournit un signal indispensable. La RFC 8470 définit Early-Data: 1 afin de conserver, à travers les intermédiaires, le fait qu’une requête a été envoyée tôt sur un saut précédent. Attendre la fin d’une autre poignée de main ne la rend pas sûre. Un serveur qui refuse ce risque répond 425 Too Early, puis la nouvelle tentative doit être émise après la poignée de main.

La sémantique de la méthode reste déterminante. Selon la RFC 9110, une méthode est idempotente lorsque plusieurs requêtes identiques ont le même effet voulu qu’une seule. Un POST n’acquiert pas cette propriété par simple étiquette. Une application peut le rendre réessayable grâce à une clé, mais seulement si le périmètre, la durée de conservation, les conflits et le résultat autoritatif sont effectivement définis.

Le reçu d’acceptation doit réunir sans les confondre : identité de requête, méthode et ressource, décision 0-RTT, nœud d’entrée, origine, domaine anti-rejeu, propagation d’Early-Data, réponse 425, chemin de reprise, identifiant de transaction et nombre définitif de validations. Le secret reste secret ; son périmètre d’acceptation doit être observable.

L’objectif n’est pas d’interdire 0-RTT. Les lectures et opérations conçues pour tolérer le rejeu peuvent en profiter. Il est d’empêcher qu’un résultat de latence soit présenté comme une garantie d’exécution. La connexion est rapide ; seule l’application peut prouver ce que les octets ont produit.

Sources