Zusammenfassung

  • QUIC verwendet den kleineren angekündigten Wert ungleich null und setzt anschließend eine Untergrenze von drei aktuellen PTO-Perioden an.
  • Der Timer startet nur bei genau definierten Empfangs- und Sendeereignissen neu; wiederholtes lokales Senden verlängert ihn nicht unbegrenzt.
  • Ein langer QUIC-Wert reserviert weder UDP-Mapping noch Backend-Affinität, Anwendungszustand oder geschäftliche Sitzungsdauer.

Beide Endpunkte kündigen dreißig Minuten an, und die Produktanzeige behauptet deshalb, eine stille Sitzung überlebe eine halbe Stunde. Neunzig Sekunden nach dem letzten Austausch entfernt eine Firewall ihr UDP-Mapping. Das nächste Clientpaket erreicht den Backend-Server nicht mehr, obwohl dieser den Verbindungszustand noch hält. Der Transportparameter hat nichts anderes zugesagt, denn er hat diesen Pfad nie reserviert.

RFC 9000 Abschnitt 10.1 definiert eine Grenze des Protokollzustands. Kündigt mindestens ein Endpunkt einen max_idle_timeout ungleich null an, ist der wirksame Wert das Minimum beider Ankündigungen oder der einzige Wert ungleich null. Bleibt die Verbindung länger als diese Frist inaktiv, schließt der Endpunkt sie ohne weitere Mitteilung und verwirft ihren Zustand.

Entscheidend ist das Wort „Maximum“. Der Wert begrenzt geduldete Stille; er ist keine Mindestmietdauer für eine funktionierende Verbindung. Ein Endpunkt, der einen Wert ankündigt, verpflichtet sich zu einem sofort eingeleiteten Schließen, falls er die Verbindung aus eigenem Entschluss früher aufgibt. Eine Anwendungsfrist, ein ausdrückliches Schließen, ein Stateless Reset, abgelaufene Berechtigungen, ein verlorener Pfad oder ein ausgefallener Vermittler können die Sitzung dennoch früher unbrauchbar machen.

Die Neustartregeln sind genauer als ein Zähler für das letzte Paket. Ein Endpunkt startet seinen Idle-Timer neu, wenn er ein Paket des Peers empfängt und erfolgreich verarbeitet. Er startet ihn auch beim Senden eines bestätigungsanfordernden Pakets neu, aber nur, wenn seit dem zuletzt empfangenen und verarbeiteten Peer-Paket noch kein anderes solches Paket gesendet wurde. Wiederholte lokale Übertragungen ohne Fortschritt des Peers erzeugen keine endlose Verlängerung. Ein Dashboard mit nur „zuletzt gesendet“ kann den tatsächlichen Timerzustand nicht rekonstruieren.

Auch die konfigurierte Zahl ist nicht immer die operative Ablaufgrenze. RFC 9000 verlangt, die Idle-Periode auf mindestens das Dreifache des aktuellen Probe Timeout, kurz PTO, anzuheben. RFC 9002 Abschnitt 6.2 gibt dem PTO eine andere Bedeutung: Er löst ein oder zwei Probe-Datagramme aus, wenn eine erwartete Bestätigung ausbleibt oder die Adressvalidierung unvollständig ist. Der Ablauf eines PTO erklärt vorherige unbestätigte Pakete nicht automatisch für verloren.

RFC 9002 Abschnitt 6.2.1 berechnet den PTO aus geglätteter RTT, RTT-Varianz, Timergranularität und, sofern anwendbar, maximaler Bestätigungsverzögerung. Bei aufeinanderfolgenden Abläufen vergrößert exponentielles Backoff jeweils die PTO-Dauer. Die Untergrenze von drei PTO ist deshalb dynamisch. Wer nur die ausgehandelten Millisekunden behält, verwirft den Wiederherstellungszustand, der die tatsächliche Ablaufgrenze erklären könnte.

Liveness-Verkehr liefert zusätzliche Evidenz, aber keinen Universalbeweis. RFC 9000 Abschnitt 10.1.1 warnt, dass ein kurz vor Ablauf gesendetes Paket eintreffen kann, nachdem der Peer seinen Zustand bereits verworfen hat. Ein PING oder ein anderer bestätigungsanfordernder Frame kann die Erreichbarkeit auf Transportebene testen. Ein zurückkommendes ACK beweist diesen Austausch, nicht die Gesundheit der Anwendung, die Gültigkeit einer Anmeldung oder die sichere Wiederaufnahme einer Transaktion.

RFC 9000 Abschnitt 10.1.2 erlaubt einer Implementierung, der Anwendung ein Aufschieben des Idle-Ablaufs anzubieten, etwa durch regelmäßige PINGs. Das kann Endpunktzustand während erwarteter Ruhephasen erhalten; das Anwendungsprotokoll sollte jedoch entscheiden, wann dies angemessen ist. Unnötige Probe-Pakete beanspruchen Verarbeitung und Netzkapazität und können die Leistung beeinträchtigen. Keepalive-Politik ist eine Betriebsentscheidung und macht aus dem Timeout keine Verfügbarkeitsgarantie.

Derselbe Abschnitt benennt die Pfadgrenze ausdrücklich: Zustand in Middleboxes kann vor dem ausgehandelten QUIC-Timer ablaufen. NAT, Firewall und Load Balancer besitzen eigene Uhren. Selbst wenn beide Endpunkte Zustand behalten, kann das nächste Paket auf ein fehlendes Mapping treffen oder beim falschen Backend landen. Eine Endpunktkonfiguration reserviert keine Infrastruktur außerhalb ihrer Kontrolle.

RFC 9000 Abschnitt 18.2 deaktiviert diesen Mechanismus, wenn beide Endpunkte den Parameter auslassen oder null angeben. Deaktiviert wird nur dieser QUIC-Idle-Mechanismus, nicht Anwendungsfristen, Sicherheitsablauf, sofortiges Schließen, Netzfehler oder Middlebox-Bereinigung. Unendliche Geduld am Endpunkt hält weder ein externes Mapping noch eine Berechtigung am Leben.

Ein belastbares Betriebsregister verbindet beide Ankündigungen, ihr Minimum, den aktuellen PTO und seine Eingaben, das letzte erfolgreich verarbeitete Peer-Paket, das letzte qualifizierende lokal gesendete Paket, PING- und ACK-Ergebnisse, Pfadbeobachtungen, Backend-Affinität, Ablauf der Anwendungssitzung und den endgültigen Beendigungsmechanismus. Ein Timer belegt nur eine Grenze.