Zusammenfassung

  • Jede QUIC-Stream-Richtung ist eine geordnete Bytefolge; STREAM-Frame-Grenzen bleiben keine Grenzen von Anwendungsmeldungen.
  • FIN und RESET_STREAM übermitteln eine unveränderliche Final Size zur Abstimmung des verbrauchten Flusskontrollguthabens.
  • Final Size beweist nicht, dass die Anwendung Bytes gelesen, verarbeitet, dauerhaft gespeichert oder einen Geschäftsvorgang abgeschlossen hat.

Ein Betriebsdashboard kann den Transport korrekt beschreiben und dennoch eine falsche Geschäftsaussage erzeugen. Sobald es eine bekannte Final Size sieht, kann es eine Anfrage als abgeschlossen markieren. Tatsächlich ist nur das Ende der Bytefolge festgelegt. Eine Richtung kann sauber mit einem STREAM-Frame samt FIN enden oder abrupt mit RESET_STREAM. Beide Wege können eine Rechnungsgrenze herstellen, keiner beweist allein die Tätigkeit der Anwendung.

QUIC stellt jede Stream-Richtung als geordnete Bytefolge dar. Die Grenzen einzelner STREAM-Frames werden bei Übertragung, Wiederholung und Übergabe nicht bewahrt. Die Anwendung muss daher selbst festlegen, wie Nachrichten gerahmt werden. Eine Frame-Grenze ist nicht automatisch das Ende einer Anfrage, eines Datensatzes oder einer Transaktion.

Bei einem STREAM-Frame mit FIN ergibt sich Final Size aus Offset plus Datenlänge. RESET_STREAM enthält ein ausdrückliches Final-Size-Feld. Der Wert ist eins größer als der größte gesendete Byte-Offset oder null, wenn keine Bytes gesendet wurden. Er beschreibt das von dieser Richtung verbrauchte Flusskontrollguthaben. Auf Verbindungsebene werden die Final Size aller Streams addiert, auch die terminaler Streams. Das ist Ressourcenbuchhaltung, kein Erfolgsnachweis.

Sobald Final Size bekannt ist, darf sie sich nicht ändern. Daten an oder nach dieser Grenze oder eine spätere abweichende Angabe können FINAL_SIZE_ERROR auslösen. Auch nach dem Ende kann Zustand nötig sein, um einen späteren Konflikt zu erkennen. Die Unveränderlichkeit schützt die Buchhaltung, macht sie aber nicht zu einer Zustellbestätigung.

Der Empfang besitzt mehrere getrennte Zustände. Eine bekannte Final Size bedeutet nicht, dass alle vorherigen Bytes angekommen sind. Vollständiger Empfang bedeutet nicht Übergabe an die Anwendung. Übergabe bedeutet nicht Lesen, korrekte Analyse, dauerhaften Commit, Kompensation, Rollback oder Geschäftserfolg. RESET_STREAM kann die Übergabe unterbrechen und das Verwerfen ungelesener Bytes erlauben. Es beweist aber keine vollständige Nichtzustellung: Alle Daten können bereits gepuffert sein, und die Reset-Anzeige kann unterdrückt werden.

Eine Paketbestätigung liegt auf einer niedrigeren Beweisebene. Die Verarbeitung eines STREAM-Frames verlangt, seine Bytes für die Anwendung einzureihen, beweist aber nicht, dass sie gelesen oder genutzt wurden. Ebenso sagt Final Size nichts über den Erfolg der Gegenrichtung oder der gesamten Verbindung.

Das Beweisregister sollte Stream-ID und Richtung, FIN oder RESET_STREAM, den Anwendungscode bei Reset, Quelle und Zahlenwert von Final Size, höchsten beobachteten Offset, zusammenhängende Abdeckung, Eingang aller Bytes beim Empfänger, Übergabe oder Lesen durch die Anwendung, Nachrichtenrahmung, dauerhaften Commit, Kompensation, Rollback und Geschäftsergebnis sowie zur Erkennung von FINAL_SIZE_ERROR behaltenen Zustand getrennt erfassen.

Auch fünf Nachbarfragen bleiben getrennt. TR-046 betrifft die Sendeberechtigung vor höheren Offsets, nicht den abschließenden Buchhaltungsgesamtwert. TR-052 betrifft DATAGRAM-Nachrichtengrenzen, während der geordnete Byte-Stream STREAM-Grenzen nicht bewahrt. TR-053 betrifft das Ende des Verbindungszustands. TR-054 betrifft STOP_SENDING und Abbruchsignale. TR-045 begrenzt, was ACK über Paketverarbeitung beweist. Keine dieser Ebenen ersetzt eine andere.