Zusammenfassung

  • Ein gültiges CONNECTION_CLOSE beendet die QUIC-Verbindung sofort und schließt offene Streams implizit.
  • Der Sender wechselt in closing, der Empfänger in draining; die Antwortpflichten unterscheiden sich.
  • Code und Begründungstext belegen Transportzustand, nicht Geschäftsabschluss, dauerhafte Festschreibung oder Ursache.

Ein geschütztes CONNECTION_CLOSE ist ein authentifiziertes Transportsignal des Peers. Es belegt, dass der empfangende Endpunkt einen gültigen Frame beobachtet hat und die Verbindung in den vorgesehenen Beendigungspfad eingetreten ist. Es ist jedoch keine Empfangsquittung der Anwendung. Besonders riskant ist eine Betriebsbuchhaltung, die NO_ERROR sieht und deshalb alle noch laufenden Workflows als erfolgreich markiert.

QUIC beendet den Transport unmittelbar. Offene Streams werden sofort geschlossen und können als implizit zurückgesetzt behandelt werden. Der sendende Endpunkt geht in closing, der empfangende in draining. Damit ist der Verbindungszustand beschrieben, nicht aber eine ausgehandelte anwendungsseitige geordnete Beendigung, der Empfang und die Verarbeitung jeder Nachricht, eine dauerhafte Festschreibung, eine Kompensation oder der Abschluss eines Geschäftsprozesses.

Die Frame-Variante muss im Nachweis erhalten bleiben. Typ 0x1c trägt QUIC-Fehler, darunter NO_ERROR, und enthält das Feld für den auslösenden Frame-Typ; bei Unkenntnis ist sein Wert null. Typ 0x1d trägt Fehlercodes des Anwendungsprotokolls und hat dieses Feld nicht. Ein Transportcode ist keine Empfangsbestätigung der Anwendung. NO_ERROR bedeutet lediglich, dass der fehlerfreie Transportcode verwendet wurde. Der Begründungstext ist ein optionaler, vom Peer gelieferter Diagnosetext; er darf leer sein und hat kein Sprachkennzeichen. Er ist keine vollständige Ursachenanalyse.

Closing und draining dienen dazu, verzögerte oder umsortierte Pakete sauber zu verwerfen. Normalerweise sollten sie mindestens drei aktuelle PTO-Intervalle bestehen bleiben. Eine dokumentierte alternative Kontrolle, die verhindert, dass späte Pakete Antworten auslösen, kann eine frühere Freigabe erlauben. Nach dem Ende eines Zustands wird der Verbindungszustand verworfen; ein späteres Paket kann dann einen Stateless Reset erhalten. Der Zeitpunkt der Zustandsfreigabe gehört deshalb getrennt vom Anwendungsabschluss in den Nachweis.

Die Zustände sind nicht symmetrisch. In closing hält der Endpunkt nur genug Information, um Verbindungspakete zu erkennen und CONNECTION_CLOSE-Antworten zu erzeugen. Er muss empfangene Frames nicht verarbeiten, soll Antworten begrenzen und muss bei nicht validierbaren Eingangspaketen die Verstärkungsgrenzen einhalten. In draining dürfen keine Pakete gesendet werden. Vor dem Eintritt darf höchstens ein Close-Paket gesendet werden; danach bleibt der Endpunkt still. Diese Stille ist eine Transportregel und kein Geschäftserfolg.

Auch die Schutzstufe entscheidet, ob der Peer den Close verarbeiten kann. Nach der Handshake-Bestätigung muss CONNECTION_CLOSE in einem 1-RTT-Paket gesendet werden. Vorher können mehrere verfügbare Schutzstufen nötig sein, damit der Peer wenigstens eine Kopie verarbeitet. Ein Client darf nicht annehmen, dass ein Server einen ausschließlich in 0-RTT gesendeten Close akzeptiert hat. Ein nicht sichtbarer Close beweist daher nicht automatisch, dass der Peer ihn ignoriert hat.

Anwendungsnachweise bleiben getrennt: Verhandlung einer geordneten Anwendungsbeendigung, Annahme je Operation, dauerhafte Festschreibung, Kompensation und Abschluss. Die Ursachenanalyse braucht Belege unabhängig vom Close-Frame. Der Begründungstext kann die Untersuchung lenken, ersetzt diese Nachweise aber nicht.