HTTP/3 Support

[uvd]

add HTTP/3 Support

[shenshouer]

Any plan for this?

[quentusrex]

Since I followed the rabbit hole from Tokio and Tonic to here, the latest work appears to be over here currently:
quinn-rs/quinn#734

Any best ways to support the latest efforts on http/3 support?

[djc]

I have a branch going on here: https://github.com/djc/hyper/tree/quinn-h3. This adds (completely untested) support for HTTP/3 to the hyper server, but doesn't yet add any API to set it up. I have some ideas on how to do that. That branch also more or less depends on #2182 and #2188 (which are currently included in that branch) and on further tweaks to quinn-rs/quinn#734 that I'll have to rebase on the final version of that PR once it's ready.

[quentusrex]

@djc Looks like all of the tickets but #2182 were merged. Does this mean that https://github.com/djc/hyper/tree/quinn-h3 is getting close?

[djc]

I've been discussing it with @seanmonstar, as far as I can tell he's still figuring out how he wants to go about it.

[seanmonstar]

We've put together a proposal here: hyperium/h3#1

[quentusrex]

With the proposal merged, what is the best way to see current status towards first MVP of the functionality? and with status, ways to support the effort?

[djc]

To the best of my knowledge, work is ongoing in the h3 repo. There is a h3 channel in the Tokio Discord which you might join, as well.

(If by support the effort you mean financially, I might be available to accelerate the efforts on a consulting basis. If that is of interest, shoot me an email.)

[seanmonstar]

Good point, I'll see about setting up a milestone with all the issues needed to get the design working. If by support the effort you mean to contribute code, as mentioned, there's an h3 Discord channel to discuss next features, and I'll get a milestone going. There is the general issue tracker, which already has some work split up.

[quentusrex]

Congrats on the recent h3 progress(client side request fetching from cloudflare)!

Given the recent activity in h3, and the closing of several of the functionality related issues, what would the hyper next steps look like? I assume there'd be some kind of an h3 release(which would include the minimal public api docs, etc).

Any easier coding work in view?

[seanmonstar]

Yes, an h3 0.1 release would be a necessary step. I've add a few more issues, labels, and a milestone, that should have some "easier" and some more involved work to get there.

Another step to figure out is how to actually provide the support in the hyper crate. That's something I haven't thought too much about. I think some of the requirements though, considering the goal of stabilizing hyper into a 1.0 release, would require:

• Not exposing the h3 library directly, so we can iterate on h3 without it being breaking changes for hyper.
• Making it optional, like http1 and http2 are.
• Probably not bundle any particular TLS library with hyper directly.

We can try to figure out both of these things in parallel, so thoughts are welcome!

[quentusrex]

Looks like the only issue still attached to the v0.1 milestone is docs related. Is that accurate? https://github.com/hyperium/h3/milestone/1

[molysgaard]

IETF has published RFC 9114

[seanmonstar]

I've filed an issue in reqwest to explore using the h3 crate, which would help inform what APIs to expose directly in hyper: seanmonstar/reqwest#1558

[kckeiks]

Are you accepting PRs for this, perhaps a draft?

[Noah-Kennedy]

@schizobeyond-tech H3 is still fairly immature as a web technology, and things like congestion control, flow control, IO model, and the standards themselves around QUIC are all evolving still quite rapidly. To compound this, the IO model of H3 is very different than H2 or H1, creating new performance challenges. Not having a dedicated listener socket like with TCP poses a lot of questions and creates a number of challenges. Furthermore, the surface area of HTTP/3 is rapidly evolving in a manner that makes QUIC and H3 support a bit of a moving target (see the introduction of capsules and WebTransport, for example). One of the goals of hyper's H3 support has been support for multiple H3 backends, and this gets much harder because of these challenges.

H3 support in hyper is a work in progress, with much of the work still very much being around answering the question of "how should this be implemented, and what kinds of tradeoffs do we want to make".

Also, as someone with a lot of experience in this area, H3 performance in the real world is a lot more complicated than you make it out to me. In many cases, even on mobile, H2 can be faster, and we're seeing things like congestion and flow control evolve rapidly to improve the performance of H3 (and even normal TCP as well. Also, zero-RTT doesn't have necessarily the impact you might think all too often. It's very common for real-world performance to be more impacted by bandwidth than the number of RTTs required.

[QuentinPerez]

Thank you @Noah-Kennedy for the update. Implementing the client part of HTTP/3 first, could be a viable approach ? Especially considering that many load balancers already support translation between HTTP/3 and HTTP/2.

┌────────────┐      ┌──────────┐     ┌──────────┐
│            │      │          │     │          │
│    App     │      │    LB    │     │ Backend  │
│ H3-Client  │─────▶│ H3 -> H2 │────▶│    H2    │
│            │      │          │     │          │
└────────────┘      └──────────┘     └──────────┘

We have multiple applications running on the AppStore/PlayStore with a networking stack in Rust (Tonic), having a client-side support for HTTP/3 would be a significant advantage.

[seanmonstar]

@QuentinPerez I've so far suggested building out the client implementation in reqwest, where it can be an internal detail, and flesh how it works, before making some public API in hyper. There is a working (but unstable) feature in reqwest. There's likely a few more things to try out, I could put together an issue over there if interested.

[NobodyXu]

There is a working (but unstable) feature in reqwest.

Can we make it available without having to pass --cfg reqwest_unstable?
Since reqwest hasn't reached 1.0 yet, it's ok to have new breaking release.

Putting the feature behind --cfg reqwest_unstable only make it harder to adopt, I really want to enable http3 support in cargo-binstall, however due to the cfg I didn't enable it.

[QuentinPerez]

@QuentinPerez I've so far suggested building out the client implementation in reqwest, where it can be an internal detail, and flesh how it works, before making some public API in hyper. There is a working (but unstable) feature in reqwest. There's likely a few more things to try out, I could put together an issue over there if interested.

I've been using the unstable feature since its release, such as handling media uploads or downloads on GCS. Thus far, it works as expected 🙏 (GCP LB).

Since we use GRPC, I would like to test it with Tonic. If you could provide a straightforward example of an H3 client, integrated into Hyper, it would be awesome. Then I could try integrate it in Tonic and test it out with our users and to report the issues if any.

[djc]

@seanmonstar why not also allow an unstable (guarded by --cfg) implementation in hyper?