Zusammenfassung

  • MAX_DATA und MAX_STREAM_DATA melden absolute Offsetgrenzen, keine neuen Bytes und keinen freien Speicher.
  • Ein späterer kleinerer Wert widerruft keinen Kredit; fehlendes DATA_BLOCKED beweist keine freie Sendemöglichkeit.
  • Kapazitätsaussagen brauchen die Verknüpfung mit Offsets, Endgrößen, Anwendungsverbrauch, Speicher und Überlastungszustand.

Ein Dashboard sieht, wie der Empfänger MAX_DATA auf 16 MiB erhöht, und meldet 16 MiB Reserve. Die Rechnung verwechselt eine kumulative Grenze mit einem Zuwachs: Bereits belegte Offsets zählen weiter. Auch die Bedeutung ist falsch. Der Wert erlaubt dem Sender, sein Byte-Ledger zu erweitern; er misst weder freien RAM noch den Fortschritt der Anwendung.

RFC 9000 §4.1 setzt zwei gleichzeitige Grenzen. Die Verbindungsflusskontrolle begrenzt sämtliche STREAM-Daten, die Streamflusskontrolle schützt den Empfangspuffer vor einem einzelnen Stream. Nutzbarer Kredit hängt von der höchsten Verbindungsgrenze und ihrem Verbrauch sowie von Streamgrenze und größtem Offset ab.

Die Werte sind absolut. Ein späteres kleineres MAX_DATA oder MAX_STREAM_DATA bleibt wirkungslos; der Sender muss Frames ignorieren, die das Limit nicht erhöhen. Der „letzte Wert“ ist daher keine belastbare Kennzahl. Gespeichert werden müssen der größte akzeptierte Wert und seine Verbrauchsrechnung.

RFC 9000 §19.9 zählt alle STREAM-Daten. Die Summe der Endgrößen, auch beendeter Streams, muss innerhalb der Grenze bleiben. RFC 9000 §4.5 definiert die Endgröße als verbrauchten Kredit. Abschluss oder Reset stellt die Rechnung fest; er gibt historische Offsets nicht an das Verbindungsbudget zurück.

RFC 9000 §19.10 rechnet pro Stream mit dem größten Offset. Verlust und Umordnung können ihn über die derzeit lückenlos lieferbaren Bytes hinausschieben. Paketbytes oder momentane Pufferauslastung ersetzen dieses Offset-Ledger nicht.

Nach RFC 9000 §4.2 entscheidet die Implementierung Zeitpunkt und Umfang einer Erhöhung. Häufige kleine Updates erzeugen Steuerlast; seltenere Updates verlangen größere Schritte und Ressourcenbindungen. RTT und Verbrauchsrate der Anwendung können Autotuning leiten, machen den Wert aber nicht zu einem Sensor für freien Speicher.

Kredit verspricht auch keinen Durchsatz. RFC 9000 §4.3 warnt, dass Flusskontrolle den Empfangsdurchsatz begrenzt, wenn verfügbarer Kredit nicht oberhalb des Bandbreiten-Verzögerungs-Produkts bleibt. Er kann notwendig sein, reicht aber nicht: Überlastungsfenster, Verlust, Planung und Senderarbeit bleiben eigenständig.

DATA_BLOCKED ist ebenfalls kein vollständiger Beleg. RFC 9000 §19.12 empfiehlt den Frame, wenn der Sender schreiben will, aber am Verbindungslimit steht. Verpflichtend ist er nicht; §4.2 verbietet dem Empfänger, vor neuer Kreditvergabe darauf zu warten. Sein Fehlen beweist keine Reserve.

Ein belastbares Betriebsprotokoll umfasst Höchstgrenzen, kumulativen Verbrauch, Offsets, Endgrößen, beobachtete Blockaden, Verbrauchsfront der Anwendung, Speicherbelegung, Überlastungsfenster, RTT, Verlust und Updatezeit. MAX_DATA belegt nur die Protokollerlaubnis.