search

hyperium / hyper

An HTTP library for Rust
https://hyper.rs
MIT License
14.44k stars 1.59k forks source link

HTTP/3 Support #1818

Open uvd opened 5 years ago

uvd commented 5 years ago

add HTTP/3 Support

shenshouer commented 4 years ago

Any plan for this?

quentusrex commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

We've put together a proposal here: https://github.com/hyperium/h3/pull/1

quentusrex commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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

quentusrex commented 2 years ago

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 commented 2 years ago

IETF has published RFC 9114

seanmonstar commented 2 years ago

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 commented 1 year ago

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

humbinal commented 1 year ago

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 commented 1 year ago

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

alikor commented 1 year ago

So any updates on QUIC support?

kckeiks commented 1 year ago

Are you accepting PRs for this, perhaps a draft?

schizobeyond-tech commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

iMonZ commented 11 months ago

Any news here?

ONLYA commented 10 months ago

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 commented 8 months ago

Hi,

Any news on this issue?

Love hyper and love quic...

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