HTTP/3 Support

[uvd]

Current status

HTTP/3 support is on the roadmap. There is a working h3 crate, and reqwest has unstable HTTP/3 support.

Much work is still needed, and volunteers are welcome.

Besides the issue tracker (which should store durable decisions and their context), there's this h3 Discord channel to coordinate work.

Here's some of the main steps:

• [ ] Harden the h3 crate itself, such as fixing any straggling interop issues, and filling out the spec conformance tags we use for accountability.
• [ ] Proposal for (initially unstable) hyper::rt::quic integration, allowing people to bring their own QUIC.
• [ ] Write the hyper::proto::http3 glue that translates hyper's connection patterns with the h3 crate.

[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: https://github.com/djc/quinn/pull/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 djc/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 https://github.com/hyperium/hyper/pull/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: https://github.com/hyperium/h3/pull/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: https://github.com/seanmonstar/reqwest/issues/1558

[ShabbirHasan1]

Will HTTP/3 Support be there by 31 December 2022. Please let us know. TIA

[humbinal]

Hi, everyone, Is he ready for experimental use now? It is best to use it directly in downstream projects, such as axum, warp... thanks a lot~

[mmhdi]

Hi, Can you use https://github.com/cloudflare/quiche to support http/3?

[alikor]

So any updates on QUIC support?

[kckeiks]

Are you accepting PRs for this, perhaps a draft?

[schizobeyond-tech]

dont understand how one of most important if not most important features of modern web technologies is still not implemented in most popular Rust server framework especially when For every second delay in mobile page load, conversions can fall by up to 20% and HTTP/3 helps with load times and 0RTT a lot..

[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.

[schizobeyond-tech]

@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.

this is just a skill issue on your end, i'll continue using .NET Core wit HTTP3 instead of hyper. Will check back in 2-5 years @Noah-Kennedy as for everything else you wrote, not everyone is incompetent web dev NPC that produces bloated unoptimized pages/websites. If you or anyone else at your NSA Prism v2 front company (Cloudflare) require any further explaining from me, let me know. In general its beyond pathethic to pull authority card when you offer free tier services for PHP and wordpress hosted on $1 a month 1 vCore VPS and then use those statistics to justify something because you are too weak to figure out how to implement things properly.

[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?

[iMonZ]

Any news here?

[ONLYA]

It's been nearly 4 or 5 years on this. Any updates? Perhaps we can have the h3 repo as a dependency of one of the branches for hyper http3 development. Or use the Quiche's h3 module for testing, which seems more mature: https://github.com/cloudflare/quiche

---

Moderator note: please don't just ask if anything has happened. We update the issues when there is something to say.

[agavrel]

Hi,

Any news on this issue?

Love hyper and love quic...

edit: Ok it seems things are evolving "peacefully": https://seanmonstar.com/