Reduce memory footprint of HTTP/2 connections

[MihaZupan]

Since the logic is shared, this applies to both SocketsHttpHandler and Kestrel.
Possibly addresses dotnet/aspnetcore#60313
cc: @AlgorithmsAreCool, @halter73, @JamesNK for the server side

HPackDecoder allocates 4 buffers:

• 4 KB _stringOctets, 4 KB _headerNameOctets, 4 KB _headerValueOctets
• 3 KB DynamicTable

IMO these are oversized for initial sizes:

• names are way smaller in practice
• 4 KB is quite large for a single value, except maybe for large cookies
• if a peer doesn't use dynamic header indexing (e.g. HttpClient), the 3 KB buffer will be unused

I changed these to start very small, letting them grow as needed.
We already have resizing logic, I only modified DynamicTable to also support starting with a non-max-size buffer (it already could resize afterwards).

Looking at HttpClient talking to Kestrel, I expect this should save around

• 4-11 KB for HttpClient (at least the name buffer, likely a chunk of the value)
  • For cases with few requests (e.g. single long-lived stream) this could be ~14 KB since DynamicTable will stay small
• 7-14 KB for Kestrel (at least the name and dynamic table, likely a chunk of the value)

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[Copilot]

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

[Copilot]

The reduced default string octets size of 32 may lead to more frequent buffer resizes if header values typically exceed this length; please ensure that the change is backed by performance benchmarks for realistic workloads.

[MihaZupan]

You could see more intermediate smaller allocations, but that is offset by the fact we're allocating less overall on average.
E.g. we may allocate more for value buffers in the worst case, but we'll allocate less for names. In either case these are temporary per-connection costs.

[stephentoub]

Do we have data on expected string sizes?

[MihaZupan]

This calculation was technically wrong before, but 52 vs 58 both end up with at least 64.

[stephentoub]

Nit: consider adding parens around the multiplication. I realize it's not necessary, but it took me a moment to visually parse what was being done.

[JamesNK]

cc @BrennanConroy @adityamandaleeka

[AlgorithmsAreCool]

This would go a long way towards addressing dotnet/aspnetcore#60313. Probably reducing about 25% of memory footprint per connection.

[stephentoub]

Consider putting _maxSize / HeaderField.RfcOverhead into a local (maxCount or whatever) so that it's clear we're validating _count against the same expression that's used in resizing.

[stephentoub]

Would this be faster and equivalent as:

if (++_insertIndex == _buffer.Length)
{
    _insertIndex = 0;
}

or does it not matter?

[stephentoub]

If someone is using the dynamic table feature, is it likely they'll only have 4 items in the table? Maybe I misunderstand typical use, but that seems small.

[MihaZupan]

It'll heavily depend on the use case, but you're right, 4 is likely to be exceeded, it should likely start larger.
E.g. if you sent a single request, this might be the number of response headers for that request.
If you're hitting an API where response headers look the same, it might never grow after that.
If you were to use HttpClient as a crawler, then you're practically guaranteed to either use 0 if the server doesn't use it, or maxSize if it does.