fix: limit excessive amount of small DATA frames - #935
Merged
Conversation
HTTP/2 flow control limits DATA payload bytes, but it does not limit the number of frames carrying those bytes. A peer could fragment data into many tiny frames, causing disproportionate memory usage from queued events and slab entries while remaining within the flow-control windows. Track a connection-level budget for DATA framing overhead. Small frames consume budget according to the difference between their payload length and the approximate cost of a buffered event. Larger frames replenish the budget, up to its original limit. When the application consumes a queued small frame, its buffering charge is also returned. Non-final DATA frames with an empty decoded payload are discarded after their flow-control accounting is handled. Because they are never exposed to the application, their budget is not returned. Exhausting the budget closes the connection with ENHANCE_YOUR_CALM. This bounds excessive fragmentation retained within h2 while allowing long-lived connections carrying promptly consumed small messages.
1 task
Sruhvx-jpg
added a commit
to Sruhvx-jpg/h2
that referenced
this pull request
Aug 23, 2026
Problem HTTP/2 flow control limits DATA payload bytes, but not the framing overhead from excessive numbers of small frames. A peer could fragment data into many tiny frames, causing disproportionate memory usage from queued events while remaining within flow-control windows. Solution Backport the framing overhead budget and empty frame handling from master (hyperium#935, hyperium#940, hyperium#942, hyperium#945, hyperium#946) to the 0.3.x maintenance branch. Validation Ran the full test suite and added regression integration tests in stream_states.rs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HTTP/2 flow control limits DATA payload bytes, but it does not limit the number of frames carrying those bytes. A peer could fragment data into many tiny frames, causing disproportionate memory usage from queued events and slab entries while remaining within the flow-control windows.
To fix it, this adds a connection-level budget for DATA framing overhead. Small frames consume budget according to the difference between their payload length and the approximate cost of a buffered event. Larger frames replenish the budget, up to its original limit. When the application consumes a queued small frame, its buffering charge is also returned.
Non-final DATA frames with an empty decoded payload are discarded after their flow-control accounting is handled. Because they are never exposed to the application, their budget is not returned. Exhausting the budget closes the connection with ENHANCE_YOUR_CALM.