Zusammenfassung

  • QUIC erlaubt je Streamtyp eine kumulative Zahl von Öffnungen über die Lebensdauer einer Verbindung.
  • Das Schließen eines Streams gibt keine Öffnung zurück und schafft keinen wiederverwendbaren Slot.
  • Transportberechtigung, Live-Zustand, Anwendungskonkurrenz, verfügbare Worker und nachgelagerte Ressourcen müssen getrennt erfasst werden.

Der typische Irrtum entsteht, wenn ein Betriebsdashboard initial_max_streams_bidi, initial_max_streams_uni oder MAX_STREAMS als aktuelle Parallelität bezeichnet. Es zieht geschlossene Streams ab und zeigt den Rest als freie Kapazität. Damit wird die Protokollbedeutung verändert. Die Parameter erlauben dem Peer, eine kumulative Zahl von Streams eines bestimmten Typs während der Verbindung zu öffnen. Sie sagen nicht, wie viele Streams im Moment offen sind.

Stream-IDs codieren Initiator und Richtung. Bidirektionale und unidirektionale Streams besitzen getrennte Nummernräume und getrennte Limits. Die Berechtigung für einen Typ darf nicht auf den anderen übertragen werden; ebenso wenig darf die Berechtigung eines Initiators dem anderen zugerechnet werden. Jede belastbare Auswertung muss diese Felder behalten.

Fehlt ein Anfangsparameter oder ist er null, darf der Peer diesen Typ erst nach einem passenden MAX_STREAMS öffnen. Spätere Werte können die kumulative Grenze erhöhen, aber nicht verringern. Ein nicht steigender Wert hat keine Wirkung und wird ignoriert. Maßgeblich sind daher kumulative Berechtigung und höchste geöffnete Streamnummer, nicht die Zahl der lebenden Streams.

Der Nachweis sollte die kumulative Berechtigung, die höchste Streamnummer, offene und geschlossene Zustände, die von der Anwendung angeforderte Parallelität, Warteschlangen, verfügbare Worker, Speicher, CPU, nachgelagerte Ressourcen, erreichbaren Durchsatz, Latenz, Abschluss und operatives oder geschäftliches Ergebnis getrennt führen. Das Schließen verändert den Live-Zustand, nicht die Öffnungsbilanz. Eine geschlossene Streamnummer wird nicht recycelt.

Wer mehr als die erlaubte kumulative Zahl öffnet, löst STREAM_LIMIT_ERROR aus. Werte über 2^60 sind wegen der Stream-ID-Kodierung ebenfalls unzulässig und führen zu einem Verbindungsfehler. Das sind Regeln für Gültigkeit und Zustandsrisiko, keine Zusage deploybarer Kapazität, erreichbaren Durchsatzes oder tatsächlicher Betriebskapazität. Ein enges Limit kann Anwendungen behindern; ein weites Limit kann die dem Endpunkt aufgezwungene Zustandsmenge vergrößern.

STREAMS_BLOCKED belegt nur, dass der Sender einen neuen Stream erzeugen wollte und durch das aktuelle Transportlimit verhindert wurde. Der Frame verleiht keine Berechtigung. Er beweist weder den Grund der Anwendung, vorhandene Arbeit, freie Worker, nachgelagerte Ressourcen, Durchsatz, Erfolg noch operative Kapazität. Er ist ein Signal blockierter Nachfrage an der Transportgrenze.

Die fünf Dimensionen bleiben getrennt: TR-046 betrifft Byte-Flusskontrollberechtigung, TR-057 die Abrechnung der endgültigen Größe, TR-054 STOP_SENDING und die Beendigung einer Richtung, TR-053 den Verbindungsabbau und TR-040 Verbindungs-IDs für Routing. Keine dieser Aussagen ersetzt die kumulative Öffnungsbilanz.