Zusammenfassung

  • RFC 9218 behandelt HTTP-Priorität als Vorschlag und einen Eingang des Schedulers; sie garantiert weder Verarbeitung, Übertragung noch Abschlussreihenfolge.
  • Ein belastbarer Nachweis verbindet das Signal jedes Hops mit Zusammenführungsregel, Schedulerzustand, Bytezuteilung, Zeitmessung und sichtbarem Ergebnis.

Man stelle sich einen gemeinsam genutzten Edge vor, der eine Seite, ein kritisches Stylesheet und mehrere Bilder ausliefert. Der Browser markiert das Stylesheet mit u=0. Ein Dashboard sieht das Feld und erklärt die kritische Ressource für geschützt. Der Edge verbindet jedoch ein Antwortsignal des Ursprungs mit lokalen Regeln für Fairness und Kapazität. Ein kleines Bild endet zuerst, während das Stylesheet auf Arbeit im Ursprung wartet. Das Feld blieb erhalten; die behauptete Reihenfolge nicht.

Das ist ein hypothetischer Betriebsfall, kein Bericht über einen benannten Anbieter. Er trennt den Wunsch des Clients, die Verarbeitung durch einen Vermittler, die Sicht des Ursprungs und die Entscheidung des Schedulers. Diese Tatsachen hängen zusammen, sind aber nicht austauschbar.

RFC 9218 definiert ein erweiterbares Schema für die Priorisierung von HTTP-Antworten. Das Feld Priority ist ein Ende-zu-Ende-Signal. PRIORITY_UPDATE-Frames in HTTP/2 und HTTP/3 tragen anfängliche oder geänderte Werte auf jeweils einem Hop. Eine Browseraufzeichnung beweist daher nicht, welcher Wert den letzten Scheduler erreichte.

Die Grundparameter sind bewusst knapp. Dringlichkeit u reicht von 0 bis 7; kleinere Werte bedeuten höheren Vorrang, Standard ist 3. Das inkrementelle Merkmal i zeigt, ob Teilstücke bereits nützlich sind, und ist standardmäßig falsch. Die Werte beschreiben die Sicht eines Endpunkts, keinen universellen Warteschlangen-, Bandbreiten- oder Abschlussalgorithmus.

Die Norm zieht die Grenze ausdrücklich: Signale sind Vorschläge und garantieren keine bestimmte Verarbeitung oder Übertragungsfolge. Scheduling verbindet Implementierung, Umgebung, Größe, Cache, Bereitschaft des Ursprungs, Überlastung und Multiplexing. Selbst wenn Dringlichkeit beachtet wird, kann eine kleine weniger dringliche Antwort vor einer großen dringlichen Antwort fertig sein.

Deshalb täuscht die Abschlussreihenfolge allein. Eine große bevorzugte Antwort kann mehr Bandbreite erhalten und dennoch später enden. Eine inkrementelle Antwort kann Kapazität teilen, weil frühe Abschnitte bereits wertvoll sind. Erstes Byte, erstes nützliches Byte, Abschluss und Darstellung sind vier verschiedene Ergebnisse und dürfen nicht in einer grünen Anzeige verschwinden.

Priorität kann sich nach der Anfrage ändern. Ein Hintergrund-Prefetch kann bei einer Navigation dringend werden. Ein PRIORITY_UPDATE trägt den vollständigen aktuellen Parametersatz und kann mit dem Öffnen des Zielstreams konkurrieren. Die Evidenz braucht daher die Reihenfolge von Anfrage- und Antwortfeld, Update-Frames, Empfangszeiten und den Schedulerzustand, der sie verarbeitete.

Vermittler schaffen eine weitere Grenze. Sie können die Anfragepriorität des Clients mit der Antwortpriorität des Ursprungs verbinden; RFC 9218 überlässt die Regel der Implementierung. Wenn mehrere Clients über eine Backendverbindung zusammengeführt werden, kann absolutes Befolgen jedes selbst gesetzten u=0 andere Nutzer verdrängen. Eine lokale Fairnessregel darf den Vorteil begrenzen und trotzdem sachgerecht sein, auch wenn sie der einfachen Dashboardprognose widerspricht.

RFC 9113 hält fest, dass das frühere Schema aus RFC 7540 uneinheitlich umgesetzt wurde und im heutigen HTTP/2 veraltet ist. Wo Signalisierung wichtig ist, wird eine Alternative wie RFC 9218 empfohlen. Eine Spur mit der Bezeichnung „HTTP/2-Priorität“ muss daher Schema, ausgehandelte Einstellungen und Implementierungsverhalten benennen.

Ein Betriebsnachweis zur Prioritätswirkung sollte Anfrage- und Antwortidentität, genaue Priority-Werte, jeden PRIORITY_UPDATE mit Hop und Reihenfolge, das Zusammenführungsergebnis, Schedulerpolitik und Konkurrenz, zugeteilte Bytes sowie Zeiten für das erste Byte, das erste für die Verarbeitung nutzbare Byte, den Abschluss und die Darstellung verbinden. Cache, Größe, Ursprungsbereitschaft und Verbindungsteilung gehören daneben. Der Nachweis ist eine redaktionelle Betriebssynthese, kein IETF-Protokollobjekt.

Damit bleibt R066 von benachbarten Themen getrennt. BGP Add-Path fragt nach unabhängigen Ausfalldomänen mehrerer Routen. RFC 8097 behandelt die Herkunft eines Ursprungsvalidierungszustands. R065 behandelte zertifikatsgestützte Autorität auf einer Verbindung. Hier lautet die engere Frage: Erzeugte ein HTTP-Schedulingwunsch tatsächlich das ihm zugeschriebene Auslieferungsverhalten?

Quellen