Résumé

  • CONNECTION_CLOSE met immédiatement fin à la connexion QUIC et ferme implicitement ses flux ouverts.
  • L’émetteur passe en closing et le récepteur en draining, avec des obligations de réponse différentes.
  • Le code et le texte de motif décrivent le transport, pas l’achèvement métier, la validation durable ou la cause.

Un CONNECTION_CLOSE protégé est un signal de transport authentifié provenant du pair. Il établit que l’extrémité réceptrice a observé une trame valide et que la connexion a suivi le chemin de terminaison correspondant. Il ne transforme pas cet événement réseau en accusé de réception métier. La confusion apparaît souvent lorsqu’un registre d’exploitation reçoit NO_ERROR et marque comme terminés tous les travaux associés à la connexion.

QUIC termine immédiatement le transport. Les flux ouverts deviennent aussitôt fermés et peuvent être considérés comme implicitement réinitialisés. L’émetteur entre dans closing, tandis que le pair qui reçoit la trame entre dans draining. Cette transition démontre l’état de la connexion, mais ne démontre pas qu’un arrêt gracieux a été négocié au niveau applicatif, que chaque message a été reçu ou traité, qu’un état durable a été enregistré, qu’une compensation a été effectuée ou qu’un processus métier est achevé.

Il faut conserver la variante de la trame. Le type 0x1c transporte les erreurs QUIC, dont NO_ERROR, et contient le champ qui désigne le type de trame à l’origine de l’erreur; ce champ vaut zéro lorsque ce type est inconnu. Le type 0x1d transporte les codes d’erreur du protocole applicatif et ne contient pas ce champ. Un code de transport n’est pas un reçu applicatif. NO_ERROR signifie seulement que le code de transport sans erreur a été utilisé. Le texte de motif est un diagnostic facultatif fourni par le pair; il peut être vide et ne porte aucune étiquette de langue. Il ne constitue pas une analyse complète de la cause.

Closing et draining existent aussi pour absorber les paquets retardés ou réordonnés. Ils devraient normalement persister au moins trois fois l’intervalle PTO courant. Un autre mécanisme documenté empêchant les paquets tardifs de provoquer une réponse peut toutefois autoriser une libération plus précoce. À la fin de l’un ou l’autre état, l’état de connexion est supprimé et un paquet ultérieur peut recevoir un Stateless Reset. L’heure de suppression doit donc être enregistrée séparément de l’achèvement applicatif.

Les deux états ne sont pas symétriques. En closing, l’extrémité conserve seulement les informations nécessaires pour reconnaître les paquets de connexion et produire des réponses CONNECTION_CLOSE. Elle n’a pas à traiter les trames reçues; ses réponses doivent être limitées, et les limites d’amplification restent applicables lorsque les paquets entrants ne peuvent être validés. En draining, aucun paquet ne doit être envoyé. Un seul paquet de fermeture au maximum peut précéder l’entrée dans cet état, après quoi l’extrémité reste silencieuse. Ce silence ne prouve donc pas une réussite métier.

Le niveau de protection compte. Après confirmation de la négociation, CONNECTION_CLOSE doit être envoyé dans un paquet 1-RTT. Avant cette confirmation, plusieurs niveaux de protection disponibles peuvent être nécessaires pour que le pair puisse traiter au moins une copie. Un client ne peut pas supposer qu’un serveur a accepté une fermeture envoyée uniquement en 0-RTT. Une fermeture non visible ne prouve donc pas automatiquement que le pair l’a ignorée. Chaque copie et son niveau de protection doivent figurer dans le registre.

Les preuves applicatives doivent rester distinctes: négociation d’un arrêt ordonné, acceptation par opération, validation durable, compensation et achèvement. La cause d’un incident doit être établie indépendamment de la trame. Le texte de motif peut orienter l’enquête, mais ne remplace aucune de ces preuves.