Zusammenfassung

  • PADDING ist ein Frame aus genau einem Byte ohne Inhalt und semantische Bedeutung; er fügt Bytes hinzu, transportiert aber keine Anwendungs-, STREAM- oder CRYPTO-Daten.
  • Ein Paket nur mit PADDING ist unterwegs und verbraucht Kapazität des Überlastfensters, ohne die nötigen ACKs auszulösen; RFC 9000 sagt, der Sender SHOULD regelmäßig weitere ack-eliciting Frames hinzufügen.
  • Der Client MUST jedes UDP-Datagramm mit Initial auf mindestens 1200 Byte erweitern; der Server MUST dies nur für ein Datagramm mit einem ack-eliciting Initial-Paket tun. Keine dieser Regeln beweist Fortschritt.

Ein Betreiber sieht ein UDP-Datagramm mit 1200 Byte und markiert ein nützliches Initial. Danach steigen die unterwegs befindlichen Bytes, und das System meldet Fortschritt. Diese Schlussfolgerung vermischt getrennte Nachweise: UDP-Datagrammlänge; QUIC-Paketgrenzen und -typ; PADDING-Bytezahl; Vorhandensein eines Frames, der ACK auslösen kann; unterwegs befindliche Bytes; Änderungen des Überlastfensters; ACK; Handshake-Zustand; und Anwendungsergebnis.

Ein QUIC-PADDING-Frame hat den Typ 0x00 und besteht nur aus seinem Kennzeichnungsbyte. Er enthält nichts und hat keine semantische Bedeutung. Er kann ein Paket vergrößern, ein Initial auf die erforderliche Größe bringen und bestimmte Informationen der Verkehrsanalyse verringern. PADDING transportiert jedoch keine Anwendungs-, STREAM- oder CRYPTO-Daten, keine Quittung, kein Ergebnis und kein Abschlusszeichen. Seine Bytes beweisen daher weder nützliche Verarbeitung durch die Gegenstelle noch Handshake- oder Anwendungsfortschritt.

Ein Datagramm kann ein Initial mit PADDING und weiteren Frames enthalten oder mehrere durch Paketkoaleszenz zusammengeführte QUIC-Pakete tragen. Aus der Länge allein lässt sich nicht erkennen, welche Bytes den Handshake vorangebracht haben. Dafür braucht es eine autorisierte Auswertung von Paketgrenzen und geschützten Frames. Ein Paket mit PADDING kann zusätzlich einen ack-eliciting Frame enthalten und bestätigt werden. Der ACK belegt dann nur Paketverarbeitung im Rahmen der QUIC-Semantik; er macht PADDING nicht zu Handshake- oder Anwendungsinhalt.

Ein ack-eliciting Packet enthält einen Frame, der nicht ACK, PADDING oder CONNECTION_CLOSE ist. PADDING allein veranlasst die Gegenstelle daher nicht, einen ACK zu senden. Ein Paket mit PADDING gilt für die Überlaststeuerung trotzdem als unterwegs. Ein reines PADDING-Paket verbraucht Kapazität des Überlastfensters, erzeugt aber nicht die ACKs, die das Fenster öffnen. Deshalb sagt RFC 9000, dass der Sender SHOULD regelmäßig andere ack-eliciting Frames ergänzen soll. Mehr unterwegs befindliche Bytes sind kein Beweis für nützlichen Fortschritt.

Die 1200-Byte-Regel ist begrenzt. Der Client MUST jedes UDP-Datagramm mit einem Initial-Paket auf mindestens 1200 Byte erweitern, entweder durch PADDING oder durch Paketkoaleszenz. Der Server MUST dasselbe für ein Datagramm mit einem ack-eliciting Initial-Paket tun. Die Regel prüft die Unterstützung einer vernünftigen Pfad-MTU; die Erweiterung des Clients verringert außerdem die verfügbare Verstärkung des Servers vor der Adressvalidierung. Sie verlangt keine 1200 Byte Handshake-Inhalt und bedeutet nicht, dass jedes Initial PADDING verwendet.

Vor der Adressvalidierung zählt der Server alle der Verbindung eindeutig zuordenbaren UDP-Nutzlastbytes in sein Drei-fach-Limit gegen Verstärkung ein, einschließlich PADDING. Semantische Leere macht Bytes nicht kostenlos. PADDING kann sichtbare Größen verändern und einige Informationen der Verkehrsanalyse reduzieren, garantiert aber weder Privatsphäre noch das Verbergen von Zeit, Richtung, Paketanzahl oder allen Längen. Datenschutzgerechte Beweisaufbewahrung und das getrennte Register sind redaktionelle Empfehlungen, keine QUIC-Anforderungen.