Résumé

  • QUIC retient la plus petite valeur non nulle annoncée, puis impose un plancher égal à trois PTO courants.
  • Le minuteur repart lors d’événements précis de réception et d’envoi ; tout paquet sortant ne le prolonge pas indéfiniment.
  • Une longue valeur QUIC ne réserve ni mappage UDP, ni affinité serveur, ni état applicatif.

Les deux extrémités annoncent trente minutes. Le tableau de bord en déduit qu’une session silencieuse survivra une demi-heure. Après quatre-vingt-dix secondes, un pare-feu supprime pourtant son mappage UDP. Le prochain paquet n’atteint plus le serveur qui conserve encore l’état QUIC. Le paramètre de transport n’avait jamais réservé ce chemin.

La section 10.1 de la RFC 9000 définit une limite d’état protocolaire. Si une extrémité annonce un max_idle_timeout non nul, la valeur effective est le minimum des deux annonces, ou l’unique valeur non nulle. Au-delà de cette période d’inactivité, l’extrémité ferme silencieusement la connexion et supprime son état.

Le mot « maximum » est décisif. Cette durée borne le silence toléré ; elle ne loue pas une connexion utilisable pendant au moins autant de temps. L’extrémité qui annonce une valeur s’engage à initier une fermeture immédiate si elle abandonne volontairement la connexion avant l’échéance effective. Une expiration applicative, une fermeture explicite, une réinitialisation sans état, une route perdue ou un intermédiaire défaillant peuvent rendre la session inutilisable plus tôt.

Les règles de redémarrage ne se résument pas au dernier paquet vu dans un compteur. Le minuteur repart après réception et traitement réussi d’un paquet du pair. Il repart aussi à l’envoi d’un paquet sollicitant un accusé, mais seulement si aucun autre paquet de ce type n’a été envoyé depuis le dernier paquet du pair reçu et traité. Des émissions locales répétées sans progrès du pair ne créent donc pas une prolongation infinie.

La configuration n’est pas toujours l’échéance opératoire. La RFC 9000 exige au moins trois fois le Probe Timeout courant. La section 6.2 de la RFC 9002 donne au PTO un rôle distinct : déclencher des sondes quand l’accusé attendu manque ou que la validation d’adresse reste incomplète. Son expiration ne constitue pas à elle seule un verdict de perte.

La section 6.2.1 calcule le PTO à partir du RTT lissé, de sa variation, de la granularité du minuteur et, selon le cas, du délai maximal d’accusé. En cas d’expirations successives, une temporisation exponentielle augmente la durée du PTO. Le plancher de trois PTO varie donc avec l’état de récupération ; ne conserver que les millisecondes négociées détruit cette explication.

Une sonde de vitalité aide, sans promettre la suite. La section 10.1.1 de la RFC 9000 avertit qu’un paquet envoyé près de l’échéance peut arriver après que le pair a supprimé son état. Un PING peut tester le transport. Son ACK ne prouve ni la santé de l’application, ni la validité d’une session utilisateur, ni la sûreté d’une reprise de transaction.

La section 10.1.2 permet à une implémentation de différer l’échéance avec des PING périodiques. Le protocole applicatif doit guider ce choix, car les sondes inutiles consomment des paquets, du traitement et de la capacité réseau, et peuvent dégrader les performances. La même section prévient qu’un middlebox peut expirer plus tôt que QUIC. NAT, pare-feu et répartiteur possèdent leurs propres horloges.

La section 18.2 désactive ce délai lorsque les deux parties omettent le paramètre ou indiquent zéro. Elle ne désactive ni les politiques applicatives, ni les expirations de sécurité, ni les pannes de chemin. Une patience QUIC infinie ne conserve pas les états extérieurs.

Le registre défendable réunit les deux annonces, leur minimum, le PTO courant, le dernier paquet du pair traité, le dernier envoi local admissible, les résultats PING/ACK, l’état du chemin, l’affinité serveur, l’expiration applicative et le mécanisme final de terminaison.