5. Fermeture de connexion (Connection Closure)

Une fois établie, une connexion HTTP/3 peut être utilisée pour de nombreuses requêtes et réponses au fil du temps jusqu'à ce que la connexion soit fermée. La fermeture de connexion peut se produire de plusieurs manières différentes.

5.1. Connexions inactives (Idle Connections)

Chaque point de terminaison QUIC déclare un délai d'inactivité (Idle Timeout) pendant la négociation. Si la connexion QUIC reste inactive (aucun paquet reçu) pendant une durée supérieure à cette durée, le pair supposera que la connexion a été fermée. Les implémentations HTTP/3 devront ouvrir une nouvelle connexion HTTP/3 pour de nouvelles requêtes si la connexion existante a été inactive pendant une durée supérieure au délai d'inactivité négocié pendant la négociation QUIC, et elles DEVRAIENT (SHOULD) le faire si elles approchent du délai d'inactivité ; voir la section 10.1 de [QUIC-TRANSPORT].

Les clients HTTP sont censés demander que le transport maintienne les connexions ouvertes tant qu'il y a des réponses en attente pour les requêtes ou les push serveur, comme décrit dans la section 10.1.2 de [QUIC-TRANSPORT]. Si le client n'attend pas de réponse du serveur, il est préférable de laisser une connexion inactive expirer plutôt que de dépenser des efforts pour maintenir une connexion qui pourrait ne pas être nécessaire. Une passerelle PEUT (MAY) maintenir des connexions en prévision du besoin plutôt que d'encourir le coût de latence de l'établissement de connexion aux serveurs. Les serveurs NE DEVRAIENT PAS (SHOULD NOT) maintenir activement les connexions ouvertes.

5.2. Arrêt de connexion (Connection Shutdown)

Même lorsqu'une connexion n'est pas inactive, l'un ou l'autre point de terminaison peut décider d'arrêter d'utiliser la connexion et d'initier une fermeture de connexion gracieuse (Graceful Connection Close). Les points de terminaison initient l'arrêt gracieux d'une connexion HTTP/3 en envoyant une trame GOAWAY. La trame GOAWAY contient un identifiant qui indique au récepteur la plage de requêtes ou de push qui ont été ou pourraient être traités dans cette connexion. Le serveur envoie un ID de flux bidirectionnel initié par le client ; le client envoie un ID de push. Les requêtes ou les push avec l'identifiant indiqué ou supérieur sont rejetés (section 4.1.1) par l'expéditeur du GOAWAY. Cet identifiant PEUT (MAY) être zéro si aucune requête ou push n'a été traité.

Les informations dans la trame GOAWAY permettent à un client et à un serveur de convenir des requêtes ou des push qui ont été acceptés avant l'arrêt de la connexion HTTP/3. Lors de l'envoi d'une trame GOAWAY, le point de terminaison DEVRAIT (SHOULD) annuler explicitement (voir les sections 4.1.1 et 7.2.3) toutes les requêtes ou push ayant des identifiants supérieurs ou égaux à celui indiqué, afin de nettoyer l'état de transport pour les flux affectés. Le point de terminaison DEVRAIT (SHOULD) continuer à le faire à mesure que davantage de requêtes ou de push arrivent.

Les points de terminaison NE DOIVENT PAS (MUST NOT) initier de nouvelles requêtes ou promettre de nouveaux push sur la connexion après réception d'une trame GOAWAY du pair. Les clients PEUVENT (MAY) établir une nouvelle connexion pour envoyer des requêtes supplémentaires.

Certaines requêtes ou push peuvent déjà être en transit :

• À la réception d'une trame GOAWAY, si le client a déjà envoyé des requêtes avec un ID de flux supérieur ou égal à l'identifiant contenu dans la trame GOAWAY, ces requêtes ne seront pas traitées. Les clients peuvent réessayer en toute sécurité les requêtes non traitées sur une connexion HTTP différente. Un client incapable de réessayer les requêtes perd toutes les requêtes en transit lorsque le serveur ferme la connexion.

  Les requêtes sur des ID de flux inférieurs à l'ID de flux dans une trame GOAWAY du serveur ont peut-être été traitées ; leur statut ne peut être connu jusqu'à ce qu'une réponse soit reçue, que le flux soit réinitialisé individuellement, qu'un autre GOAWAY soit reçu avec un ID de flux inférieur à celui de la requête en question, ou que la connexion se termine.

  Les serveurs PEUVENT (MAY) rejeter des requêtes individuelles sur des flux en dessous de l'ID indiqué si ces requêtes n'ont pas été traitées.

• Si un serveur reçoit une trame GOAWAY après avoir promis des push avec un ID de push supérieur ou égal à l'identifiant contenu dans la trame GOAWAY, ces push ne seront pas acceptés.

Les serveurs DEVRAIENT (SHOULD) envoyer une trame GOAWAY lorsque la fermeture d'une connexion est connue à l'avance, même si le préavis est court, afin que le pair distant puisse savoir si une requête a été partiellement traitée ou non. Par exemple, si un client HTTP envoie un POST au même moment où un serveur ferme une connexion QUIC, le client ne peut pas savoir si le serveur a commencé à traiter cette requête POST si le serveur n'envoie pas de trame GOAWAY pour indiquer sur quels flux il a pu agir.

Un point de terminaison PEUT (MAY) envoyer plusieurs trames GOAWAY indiquant différents identifiants, mais l'identifiant dans chaque trame NE DOIT PAS (MUST NOT) être supérieur à l'identifiant dans toute trame précédente, car les clients ont peut-être déjà réessayé des requêtes non traitées sur une autre connexion HTTP. Recevoir un GOAWAY contenant un identifiant plus grand que celui reçu précédemment DOIT (MUST) être traité comme une erreur de connexion de type H3_ID_ERROR.

Un point de terminaison qui tente d'arrêter gracieusement une connexion peut envoyer une trame GOAWAY avec une valeur définie sur la valeur maximale possible (2^62-4 pour les serveurs, 2^62-1 pour les clients). Cela garantit que le pair cesse de créer de nouvelles requêtes ou push. Après avoir laissé le temps à toutes les requêtes ou push en transit d'arriver, le point de terminaison peut envoyer une autre trame GOAWAY indiquant quelles requêtes ou push il pourrait accepter avant la fin de la connexion. Cela garantit qu'une connexion peut être fermée proprement sans perdre de requêtes.

Un client a plus de flexibilité dans la valeur qu'il choisit pour le champ Push ID dans un GOAWAY qu'il envoie. Une valeur de 2^62-1 indique que le serveur peut continuer à exécuter les push qui ont déjà été promis. Une valeur plus petite indique que le client rejettera les push avec des ID de push supérieurs ou égaux à cette valeur. Comme le serveur, le client PEUT (MAY) envoyer des trames GOAWAY ultérieures tant que l'ID de push spécifié n'est pas supérieur à toute valeur précédemment envoyée.

Même lorsqu'un GOAWAY indique qu'une requête ou un push donné ne sera pas traité ou accepté à la réception, les ressources de transport sous-jacentes existent toujours. Le point de terminaison qui a initié ces requêtes peut les annuler pour nettoyer l'état de transport.

Une fois que toutes les requêtes et push acceptés ont été traités, le point de terminaison peut permettre à la connexion de devenir inactive, ou il PEUT (MAY) initier une fermeture immédiate de la connexion. Un point de terminaison qui termine un arrêt gracieux DEVRAIT (SHOULD) utiliser le code d'erreur H3_NO_ERROR lors de la fermeture de la connexion.

Si un client a consommé tous les ID de flux bidirectionnels disponibles avec des requêtes, le serveur n'a pas besoin d'envoyer une trame GOAWAY, car le client est incapable de faire d'autres requêtes.

5.3. Fermeture immédiate de l'application (Immediate Application Closure)

Une implémentation HTTP/3 peut fermer immédiatement la connexion QUIC à tout moment. Cela entraîne l'envoi d'une trame QUIC CONNECTION_CLOSE au pair indiquant que la couche application a terminé la connexion. Le code d'erreur d'application dans cette trame indique au pair pourquoi la connexion est fermée. Voir la section 8 pour les codes d'erreur qui peuvent être utilisés lors de la fermeture d'une connexion en HTTP/3.

Avant de fermer la connexion, une trame GOAWAY PEUT (MAY) être envoyée pour permettre au client de réessayer certaines requêtes. Inclure la trame GOAWAY dans le même paquet que la trame QUIC CONNECTION_CLOSE améliore les chances que la trame soit reçue par les clients.

S'il existe des flux ouverts qui n'ont pas été explicitement fermés, ils sont implicitement fermés lorsque la connexion est fermée ; voir la section 10.2 de [QUIC-TRANSPORT].

5.4. Fermeture du transport (Transport Closure)

Pour diverses raisons, le transport QUIC pourrait indiquer à la couche application que la connexion s'est terminée. Cela peut être dû à une fermeture explicite par le pair, à une erreur au niveau du transport ou à un changement de topologie réseau qui interrompt la connectivité.

Si une connexion se termine sans trame GOAWAY, les clients DOIVENT (MUST) supposer que toute requête qui a été envoyée, en tout ou en partie, a pu être traitée.