5. Verbindungsschluss (Connection Closure)

Einmal hergestellt, kann eine HTTP/3-Verbindung im Laufe der Zeit für viele Anfragen und Antworten verwendet werden, bis die Verbindung geschlossen wird. Der Verbindungsschluss kann auf verschiedene Weise erfolgen.

5.1. Leerlaufende Verbindungen (Idle Connections)

Jeder QUIC-Endpunkt deklariert während des Handshakes einen Leerlauf-Timeout (Idle Timeout). Wenn die QUIC-Verbindung länger als diese Dauer im Leerlauf bleibt (keine Pakete empfangen werden), nimmt der Peer an, dass die Verbindung geschlossen wurde. HTTP/3-Implementierungen müssen eine neue HTTP/3-Verbindung für neue Anfragen öffnen, wenn die vorhandene Verbindung länger im Leerlauf war als der während des QUIC-Handshakes ausgehandelte Leerlauf-Timeout, und sie SOLLTEN (SHOULD) dies tun, wenn sie sich dem Leerlauf-Timeout nähern; siehe Abschnitt 10.1 von [QUIC-TRANSPORT].

Von HTTP-Clients wird erwartet, dass sie verlangen, dass der Transport Verbindungen offen hält, während ausstehende Antworten auf Anfragen oder Server-Pushes vorliegen, wie in Abschnitt 10.1.2 von [QUIC-TRANSPORT] beschrieben. Wenn der Client keine Antwort vom Server erwartet, ist es vorzuziehen, eine im Leerlauf befindliche Verbindung zeitlich ablaufen zu lassen, anstatt Aufwand für die Aufrechterhaltung einer möglicherweise nicht benötigten Verbindung aufzuwenden. Ein Gateway KANN (MAY) Verbindungen in Erwartung des Bedarfs aufrechterhalten, anstatt die Latenzkosten für den Verbindungsaufbau zu Servern zu tragen. Server SOLLTEN (SHOULD NOT) Verbindungen nicht aktiv offen halten.

5.2. Verbindungsherunterfahren (Connection Shutdown)

Auch wenn eine Verbindung nicht im Leerlauf ist, kann jeder Endpunkt entscheiden, die Verwendung der Verbindung einzustellen und einen ordnungsgemäßen Verbindungsschluss (Graceful Connection Close) einzuleiten. Endpunkte leiten das ordnungsgemäße Herunterfahren einer HTTP/3-Verbindung ein, indem sie einen GOAWAY-Frame senden. Der GOAWAY-Frame enthält eine Kennung, die dem Empfänger den Bereich der Anfragen oder Pushes anzeigt, die in dieser Verbindung verarbeitet wurden oder werden könnten. Der Server sendet eine vom Client initiierte bidirektionale Stream-ID; der Client sendet eine Push-ID. Anfragen oder Pushes mit der angegebenen Kennung oder größer werden vom Sender des GOAWAY abgelehnt (Abschnitt 4.1.1). Diese Kennung KANN (MAY) Null sein, wenn keine Anfragen oder Pushes verarbeitet wurden.

Die Informationen im GOAWAY-Frame ermöglichen es einem Client und einem Server, sich darauf zu einigen, welche Anfragen oder Pushes vor dem Herunterfahren der HTTP/3-Verbindung akzeptiert wurden. Beim Senden eines GOAWAY-Frames SOLLTE (SHOULD) der Endpunkt alle Anfragen oder Pushes, die Kennungen größer oder gleich der angegebenen haben, explizit abbrechen (siehe Abschnitte 4.1.1 und 7.2.3), um den Transportzustand für die betroffenen Streams zu bereinigen. Der Endpunkt SOLLTE (SHOULD) dies weiterhin tun, wenn weitere Anfragen oder Pushes eintreffen.

Endpunkte DÜRFEN (MUST NOT) nach Empfang eines GOAWAY-Frames vom Peer keine neuen Anfragen initiieren oder neue Pushes versprechen. Clients KÖNNEN (MAY) eine neue Verbindung herstellen, um zusätzliche Anfragen zu senden.

Einige Anfragen oder Pushes könnten bereits unterwegs sein:

• Beim Empfang eines GOAWAY-Frames, wenn der Client bereits Anfragen mit einer Stream-ID gesendet hat, die größer oder gleich der im GOAWAY-Frame enthaltenen Kennung ist, werden diese Anfragen nicht verarbeitet. Clients können nicht verarbeitete Anfragen sicher auf einer anderen HTTP-Verbindung wiederholen. Ein Client, der Anfragen nicht wiederholen kann, verliert alle Anfragen, die während des Schließens der Verbindung durch den Server übertragen werden.

  Anfragen auf Stream-IDs, die kleiner sind als die Stream-ID in einem GOAWAY-Frame vom Server, könnten verarbeitet worden sein; ihr Status kann erst bekannt sein, wenn eine Antwort empfangen wird, der Stream einzeln zurückgesetzt wird, ein weiterer GOAWAY mit einer niedrigeren Stream-ID als die der fraglichen Anfrage empfangen wird oder die Verbindung beendet wird.

  Server KÖNNEN (MAY) einzelne Anfragen auf Streams unterhalb der angegebenen ID ablehnen, wenn diese Anfragen nicht verarbeitet wurden.

• Wenn ein Server einen GOAWAY-Frame erhält, nachdem er Pushes mit einer Push-ID versprochen hat, die größer oder gleich der im GOAWAY-Frame enthaltenen Kennung ist, werden diese Pushes nicht akzeptiert.

Server SOLLTEN (SHOULD) einen GOAWAY-Frame senden, wenn das Schließen einer Verbindung im Voraus bekannt ist, auch wenn die Vorankündigung gering ist, damit der entfernte Peer wissen kann, ob eine Anfrage teilweise verarbeitet wurde oder nicht. Wenn beispielsweise ein HTTP-Client einen POST sendet, während ein Server gleichzeitig eine QUIC-Verbindung schließt, kann der Client nicht wissen, ob der Server mit der Verarbeitung dieser POST-Anfrage begonnen hat, wenn der Server keinen GOAWAY-Frame sendet, um anzuzeigen, auf welche Streams er möglicherweise eingewirkt hat.

Ein Endpunkt KANN (MAY) mehrere GOAWAY-Frames senden, die verschiedene Kennungen anzeigen, aber die Kennung in jedem Frame DARF (MUST NOT) nicht größer sein als die Kennung in einem vorherigen Frame, da Clients möglicherweise bereits nicht verarbeitete Anfragen auf einer anderen HTTP-Verbindung wiederholt haben. Der Empfang eines GOAWAY, das eine größere Kennung als zuvor empfangen enthält, MUSS (MUST) als Verbindungsfehler vom Typ H3_ID_ERROR behandelt werden.

Ein Endpunkt, der versucht, eine Verbindung ordnungsgemäß herunterzufahren, kann einen GOAWAY-Frame mit einem Wert senden, der auf den maximal möglichen Wert gesetzt ist (2^62-4 für Server, 2^62-1 für Clients). Dies stellt sicher, dass der Peer aufhört, neue Anfragen oder Pushes zu erstellen. Nachdem Zeit für ankommende Anfragen oder Pushes gelassen wurde, kann der Endpunkt einen weiteren GOAWAY-Frame senden, der anzeigt, welche Anfragen oder Pushes er vor dem Ende der Verbindung akzeptieren könnte. Dies stellt sicher, dass eine Verbindung sauber heruntergefahren werden kann, ohne Anfragen zu verlieren.

Ein Client hat mehr Flexibilität bei dem Wert, den er für das Push-ID-Feld in einem GOAWAY wählt, das er sendet. Ein Wert von 2^62-1 zeigt an, dass der Server mit der Erfüllung bereits versprochener Pushes fortfahren kann. Ein kleinerer Wert zeigt an, dass der Client Pushes mit Push-IDs größer oder gleich diesem Wert ablehnen wird. Wie der Server KANN (MAY) der Client nachfolgende GOAWAY-Frames senden, solange die angegebene Push-ID nicht größer ist als ein zuvor gesendeter Wert.

Auch wenn ein GOAWAY anzeigt, dass eine bestimmte Anfrage oder ein bestimmter Push beim Empfang nicht verarbeitet oder akzeptiert wird, existieren die zugrunde liegenden Transportressourcen weiterhin. Der Endpunkt, der diese Anfragen initiiert hat, kann sie abbrechen, um den Transportzustand zu bereinigen.

Sobald alle akzeptierten Anfragen und Pushes verarbeitet wurden, kann der Endpunkt zulassen, dass die Verbindung im Leerlauf bleibt, oder er KANN (MAY) einen sofortigen Abschluss der Verbindung einleiten. Ein Endpunkt, der ein ordnungsgemäßes Herunterfahren abschließt, SOLLTE (SHOULD) den Fehlercode H3_NO_ERROR beim Schließen der Verbindung verwenden.

Wenn ein Client alle verfügbaren bidirektionalen Stream-IDs mit Anfragen verbraucht hat, muss der Server keinen GOAWAY-Frame senden, da der Client keine weiteren Anfragen stellen kann.

5.3. Sofortiger Anwendungsschluss (Immediate Application Closure)

Eine HTTP/3-Implementierung kann die QUIC-Verbindung jederzeit sofort schließen. Dies führt dazu, dass ein QUIC CONNECTION_CLOSE-Frame an den Peer gesendet wird, der anzeigt, dass die Anwendungsschicht die Verbindung beendet hat. Der Anwendungsfehlercode in diesem Frame zeigt dem Peer an, warum die Verbindung geschlossen wird. Siehe Abschnitt 8 für Fehlercodes, die beim Schließen einer Verbindung in HTTP/3 verwendet werden können.

Vor dem Schließen der Verbindung KANN (MAY) ein GOAWAY-Frame gesendet werden, um dem Client das Wiederholen einiger Anfragen zu ermöglichen. Das Einbeziehen des GOAWAY-Frames in dasselbe Paket wie der QUIC CONNECTION_CLOSE-Frame verbessert die Chancen, dass der Frame von Clients empfangen wird.

Wenn offene Streams vorhanden sind, die nicht explizit geschlossen wurden, werden sie implizit geschlossen, wenn die Verbindung geschlossen wird; siehe Abschnitt 10.2 von [QUIC-TRANSPORT].

5.4. Transportschluss (Transport Closure)

Aus verschiedenen Gründen könnte der QUIC-Transport der Anwendungsschicht anzeigen, dass die Verbindung beendet wurde. Dies könnte auf einen expliziten Abschluss durch den Peer, einen Fehler auf Transportebene oder eine Änderung der Netzwerktopologie zurückzuführen sein, die die Konnektivität unterbricht.

Wenn eine Verbindung ohne GOAWAY-Frame beendet wird, MÜSSEN (MUST) Clients annehmen, dass jede gesendete Anfrage, ob ganz oder teilweise, möglicherweise verarbeitet wurde.