Zusammenfassung

  • STREAM ordnet mithilfe von stream ID, Offset und Codierungsfeldern einen Bytebereich einem geordneten Stream zu.
  • Übertragung, Verlustbehandlung und Übergabe an die Anwendung bewahren die ursprüngliche Grenze eines STREAM-Frames nicht.
  • Für Aussagen über Nachrichten oder Transaktionen braucht es Anwendungs-Framing, Parsergebnis und Verarbeitungsnachweis.

Die Fehlinterpretation beginnt mit einem scheinbar eindeutigen Bild. Ein Exporter zeigt einen vollständigen STREAM-Frame, und daraus wird eine abgeschlossene Anfrage. Tatsächlich belegt der Frame zunächst nur einen für einen bestimmten Stream codierten Bytebereich an einer bestimmten Position. Der Transportbehälter ist keine Aussage über die Struktur der Anwendung.

RFC 9000 beschreibt Streams als geordnete Bytefolgen, die Anwendungen zur Verfügung stehen. Der Empfänger platziert die Daten mithilfe von stream ID und Offset. Diese Ordnung gilt innerhalb eines einzelnen Streams. Bytes verschiedener stream IDs erhalten keine globale Ausführungsreihenfolge, nur weil ein Mitschnitt sie nacheinander auflistet. Die Reihenfolge im Trace ist kein Anwendungsablauf.

OFF, LEN und FIN gehören zur Transportkodierung. OFF zeigt an, ob ein Offset-Feld vorhanden ist; ohne dieses Feld beginnen die Daten bei Offset null. LEN zeigt an, ob Length vorhanden ist; ohne dieses Feld reichen die Daten bis zum Ende des Paketbereichs. FIN setzt die letzte Bytegrenze des Streams, wobei sich die endgültige Größe aus Offset und Datenlänge ergibt. Keines dieser Felder definiert Anwendungssyntax, Nachrichtengrenzen oder geschäftlichen Erfolg.

Bei Verlust wird weder das verlorene Paket als Ganzes erneut gesendet noch seine frühere Frame-Aufteilung rekonstruiert. Stream-Informationen werden in neu aufgebauten STREAM-Frames erneut übertragen. Ein späterer Frame kann einen anderen Bereich abdecken und dennoch dieselben logischen Bytes transportieren. Die sichtbare Gestalt des ersten Frames ist daher keine dauerhafte Nachrichtenidentität. Doppelte Bereiche dürfen eintreffen und verworfen werden; Bytes an einem bestimmten Offset dürfen sich nicht ändern. Unterschiedliche Bytes an derselben Stelle wären ein Protokollverstoß.

Der Endpunkt MUSS fähig sein, außerhalb der Reihenfolge eingegangene Stream-Daten bis zum angekündigten Flow-Control-Limit zu puffern, damit der geordnete Stream wiederhergestellt und ausgeliefert werden kann. Eine Implementierung darf unabhängig davon Informationen über die Übergabe außerhalb der Reihenfolge an die Anwendung weitergeben; diese Weitergabe ist keine QUIC-Anforderung. QUIC schreibt jedoch kein einheitliches Nachrichtenmodell vor. Ein höheres Protokoll kann eine Nachricht über mehrere Frames verteilen, mehrere Strukturen in einem transportierten Bereich enthalten oder nur einen Teil einer größeren Struktur übertragen.

FIN kann die Senderichtung schließen, ohne Gültigkeit, Analyse, Verarbeitung, Commit oder Erfolg zu beweisen.

Das Betriebsprotokoll sollte Beobachtungs-ID und Zeit, Richtung der Endpunkte, packet number space und packet number, stream ID und Richtung, Offset, codierte Länge oder Regel für den Paketrest, Fingerabdruck des Bytebereichs, FIN und bekannte Endgröße, Behandlung doppelter Bereiche, Nachverfolgung der erneuten Übertragung, Bestätigungsnachweis, Abschluss des Reassembly, Anwendungs-Frame oder Datensatz-ID, Parsergebnis, Verarbeitungsbeleg und dauerhaftes Geschäftsergebnis getrennt führen. Wo Rohdaten nicht nötig sind, genügen datenschutzschonende Fingerabdrücke. Dieses Protokoll ist eine Betriebsempfehlung, keine QUIC-Anforderung.

Die Beweisgrenze bleibt eng. STREAM belegt einen codierten Bytebereich in einem Stream; authentifizierte Paketverarbeitung kann zusätzlich zum Nachweis des Eingangs am Transportendpunkt beitragen. Der Frame beweist jedoch keine Nachricht, Anfrage, Antwort, Ausführung, dauerhafte Speicherung oder Erfolg und auch keine Reihenfolge zwischen Streams. Nachrichtengrenzen, Endgröße, kryptografische Datenbereiche und ACK-Nachweise bleiben getrennte Beweisfragen.