HTTP/3: Http3Stream pooling (builds on top of QUIC stream pooling)

[JamesNK]

Note, this PR is built on top of #34075

Making them separate for now to make these changes easier to review.

This PR stashes Http3Stream and friends on transport stream content with a feature. It isn't complete, currently types like the framewriter, output producer and header decoder are recreated each time. A bit more work is required to reuse them as well.

---

Proposed API

Add PersistentState property to connection context in ASP.NET Core's connection abstraction layer:

public abstract class ConnectionContext : BaseConnectionContext
{
    /// <summary>
    /// Gets or sets a key/value collection that can be used to persist state between connections.
    /// Whether a transport supports persisting state depends on the implementation. The transport must
    /// support pooling and reusing <see cref="ConnectionContext"/> instances for state to be persisted.
    /// <para>
    /// Because values added to persistent state can live in memory until a <see cref="ConnectionContext"/>
    /// is no longer pooled, use caution with this collection to avoid excessive memory use.
    /// </para>
    /// </summary>
    public virtual IDictionary<object, object?> PersistentState { get; set; }
}

This collection is different from the existing Items dictionary because it is not cleared when a ConnectionContext is pooled and reused for a new request.

Usage Examples

This collection is used to persist a Http3Stream on a connection's QUIC streams (represented by ConnectionContext) so they are shared between requests:

Http3Stream<TContext> stream;

if (!streamContext.PersistentState.TryGetValue(StreamPersistentStateKey, out var s))
{
    // New QUIC stream. Create a new Http3Stream and add to persistent state.
    stream = new Http3Stream<TContext>(application, CreateHttpStreamContext(streamContext));
    streamContext.PersistentState.Add(StreamPersistentStateKey, stream);
}
else
{
    // Reused QUIC stream. Get existing Http3Stream and re-initialize it.
    stream = (Http3Stream<TContext>)s!;
    stream.InitializeWithExistingContext(streamContext.Transport);
}

The goal is to reduce per-request allocations with HTTP/3. I haven't measured the difference yet (will measure before merging) but allocations saved per request will be significant (multiple KBs).

Alternative Designs

• ConnectionContext has existing property bags: Items and Features. These are both reset when a connection is reused and can't be used to persist state between connection instance reuses.
• Considered adding a generic parameter TContext to ConnectionContext for preserving state (like hosting's IHostContextContainer). Generic spreads everywhere.

[JamesNK]

TestStreamContext is now reused to simulate how QUIC stream contexts are reused.

It is a bit of extra complexity to our tests, but I want to be able to test pooling Http3Streams without having to use Quic transport.

[JamesNK]

Copy and paste from QUIC transport. Will move into shared code files.

[Tratcher]

The feature collection doesn't make sense as a caching mechanism since the collection itself shouldn't preserve state between uses. You'd want the lower layer to provide an explicate caching feature.

[JamesNK]

Do you have a suggestion about how that might work? Would it be a new feature with a dictionary that gets preserved between requests like:

public interface IStateFeature
{
   IDictionary<string, object> State { get; }
}

Or a new explicit dictionary on transport context? Note that BaseConnectionContext already has Features and Items properties - https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Connections.Abstractions/src/BaseConnectionContext.cs

I created an issue a while back about using features to preserve the state between requests - #6895. There is a lot of crossover between that and this, just at a different layer.

I don't want to turn this into a big thing so another option is to have a hack in .NET 6 where the stream is added to the transport context's Items with a specific key and that specific key isn't cleared between calls by the QUIC transport. We could then improve it in .NET 7.

[Tratcher]

The state feature and the dictionary on the transport context accomplish the same end, I don't have a preference between them.

I don't want to turn this into a big thing so another option is to have a hack in .NET 6 where the stream is added to the transport context's Items with a specific key and that specific key isn't cleared between calls by the QUIC transport. We could then improve it in .NET 7.

That is hackier than I want to go. Given our http/3 goals for 6.0 emphasize functionality over perf, I'd rather not cache if we can't come up with a clear mechanic for it.

[davidfowl]

Maybe put it directly on the ConnectionContext

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[pranavkm]

The suggestion is to have add this to Microsoft.Extensions.Features as a new feature type. The connection pooling would be aware of this feature type and re-set it. (not reset it, that's the opposite).

+ namespace Microsoft.AspNetCore.Http.Features
+ {
+     public interface IPersistentStateFeature { } 
+ }

[pranavkm]

+ namespace Microsoft.AspNetCore.Http.Features
+ {
+     public interface IPersistentStateFeature 
+     { 
+         IDictionary<object, object?> State { get; }
+     } 
+ }

[JamesNK]

Replaced by #34576