HTTP/3: Cache and reusing streams

[JamesNK]

In HTTP/2 a connection responsible for creating and stream and all resources related to it. Http2Stream creation and reuse are all handled by Http2Connection.

In HTTP/3 a stream extends into the QUIC transport layer. Http3Connection creates Http3Stream and QuicConnection creates QuicStreamContext. For high performance, both these need to be cached and reused.

tldr; cache should move into the transport layer

Detail:

1. A concurrent queue is added to QuicConnection. It acts as a cache for completed QuicStreamContext instances.
2. When accepting a stream on a connection, the queue is checked for existing QuicStreamContext instances. An instance is reused if available. Otherwise, a new QuicStreamContext is created. The stream has a reference to its connection.
3. There isn't an API to "return" a stream to the connection on MultiplexedConnectionContext. Instead, returning will be implicit with disposing of QuicStreamContext. When a cleanly completed (i.e. neither side of the stream was aborted) stream is disposed it will add itself to its QuicConnection concurrent queue cache so it can be reused.
4. We're now reusing the QuicStreamContext 🥳 We also want to reuse the Http3Stream. Rather than having a separate cache, the feature collection on the stream transport - QuicStreamContext.FeatureCollection - is used to stash Http3Stream. A reused QuicStreamContext will have a Http3Stream on it to reuse.

Caching and reusing streams should only be necessary for request streams (i.e. bidirectional streams) on an HTTP/3 connection. There isn't value in caching and reusing unidirectional streams. Only a handful are created for a connection and they will live for the lifetime of the connection.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.