Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: support HTTP/3 #32204

Open
johanbrandhorst opened this issue May 23, 2019 · 24 comments
Open

net/http: support HTTP/3 #32204

johanbrandhorst opened this issue May 23, 2019 · 24 comments

Comments

@johanbrandhorst
Copy link
Member

@johanbrandhorst johanbrandhorst commented May 23, 2019

I searched for an issue to track progress of implementing HTTP/3 in the standard library but couldn't find one, so I'm opening this new issue to track this (presumably inevitable) effort.

HTTP/3 is still an IETF draft, so there's not too much point starting work on this yet. The relevant spec is (currently) available here: https://quicwg.org/base-drafts/draft-ietf-quic-http.html.

Some questions we may want to answer before any work starts:

  1. Should work on this start in one of the x repos, like HTTP/2 did?
  2. What if any existing libraries can be used as a base for the new HTTP/3 work?

Of note is an existing attempt at implementing QUIC and HTTP/3 in pure go: https://github.com/lucas-clemente/quic-go.

@dsymonds
Copy link
Contributor

@dsymonds dsymonds commented Sep 27, 2019

Cloudflare now supports HTTP/3, and Chrome and Firefox will shortly start supporting it: https://blog.cloudflare.com/http3-the-past-present-and-future/

@rajveermalviya
Copy link

@rajveermalviya rajveermalviya commented Dec 14, 2019

Not to say we're in a race, but node has started implementing quic protocol in a draft PR.

Reference

Now, some bad opinions (if the go team is accepting them):

  • net package - dedicated raw quic protocol API, just as tcp/udp?
  • net/http package - http/3 server to be enabled explicitly from an environment variable but http/2 & lower supported implicitly using port reuse between udp (quic;http3) & tcp (http2/http1.1) sockets?

@trivikr
Copy link

@trivikr trivikr commented Dec 14, 2019

but node has started implementing quic protocol in a draft PR.

Correction: The Node.js QUIC implementation began back in Q1 2019, the draft PR is the result of all that work nodejs/node#23064

@vyrwu
Copy link

@vyrwu vyrwu commented Apr 15, 2020

Is there any progress on this? There are some existing open-source libs like quic-go that can be used for experimenting with quic, but it would be really neat to have something experimental from the std go lib.

@hekmon
Copy link

@hekmon hekmon commented Oct 9, 2020

@hherman1
Copy link

@hherman1 hherman1 commented Oct 21, 2020

Has there been any word from leadership on whether or not this will be supported?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 21, 2020

I'm not sure which leadership you are asking about.

I think it's clear that Go must support HTTP/3. This issue is a good place to record the work that needs to be done. But it is one thing to say "we must do this" and it is a very different thing to say "this is how it will be done."

@hherman1
Copy link

@hherman1 hherman1 commented Oct 22, 2020

Sorry I’m not sure how that came off, I was just wondering if there was any official word on if this will be supported. Couldn’t find any on the issue tracker. Thanks for the quick answer though!

@sylr
Copy link

@sylr sylr commented Oct 22, 2020

It seems to me that it is still a long way from now to we must do this.

I might have missed it but so far I did not see any interest shown in this subject from any of the net & net/http usual committers. Also a research about HTTP/3 or QUIC in golang-dev does not seem to yield any significant results.

It would be nice to see a discussion started amongst people actually capable of bringing it into the standard library.

@makeworld-the-better-one
Copy link

@makeworld-the-better-one makeworld-the-better-one commented Oct 24, 2020

Golang might be behind the times for this feature.

It's worth noting that HTTP/3 is not finalized by the IETF at this point. It is not enabled by default in Firefox and has experimental support. Google likes to push this protocol forward a lot and is using it already in Chrome, but it is still experimental and not finalized. I understand the Go team hesitating to start supporting a protocol that isn't even complete yet.

@mholt
Copy link

@mholt mholt commented Oct 24, 2020

Hmm, well, Go's standard library has never been one to quickly adopt new technologies -- not without a lot of scrutiny. HTTP/2 might possibly be the exception, but even it was not vendored in from an external package until well after the spec was standardized. HTTP/3 isn't finished being standardized yet.

HTTP/3 is more complex than HTTP/2, and there's a lot of code necessary to make it work. I've been using and deploying lucas-clemente/quic-go for a couple years now (in Caddy, so we're already seeing a lot of experimental production deployments) -- frankly it's a beast. What's the benefit of having it in the standard library right now?

It's OK if it's not in the standard library right away. I'd rather the standard implementation be correct, elegant, and stable, true to the reputation of the Go standard library.

@ShivanshVij
Copy link

@ShivanshVij ShivanshVij commented Oct 24, 2020

I understand what you’re saying, but the issue is that the NodeJS team had been experimenting with Quic support for months before this release.

Now that companies like Cloudflare and Google are beginning support, it’s unlikely that the IETF standard will change drastically.

There’s no reason not to begin implementation or at least experimentation and make whatever small tweaks are necessary for the general availability release once the standard is completed by IETF.

@ShivanshVij
Copy link

@ShivanshVij ShivanshVij commented Oct 24, 2020

@mholt is completely correct in saying that whatever finalized HTTP/3 library is released should be elegant and stable. However, what I am saying is that I believe that we should at least begin an in-depth discussion on the topic instead of just saying we will wait for the standard to be completed by IETF.

If we leave it until later, then I can see an issue where people will want to use the vast benefits of HTTP/3 but be unable to do so with Golang. (This is the main reason I have to write my server code in NodeJS right now, HTTP/3 is a requirement for us)

@makeworld-the-better-one

Google has been using and pushing HTTP/3 since before it was even called that, they deployed their super-experimental non-standardized original version of the protocol in Chrome as early as 2012. It is not surprising they are still using and pushing it now, while it is still not standardized. I would argue Cloudflare is also supporting it prematurely, likely to test their implementation at scale.

No browser currently supports HTTP/3 by default. See https://caniuse.com/http3

image

However, what I am saying is that I believe that we should at least begin an in-depth discussion on the topic instead of just saying we will wait for the standard to be completed by IETF.

I agree that beginning discussion would be helpful. I'm just saying I understand why it hasn't happened yet, and I think there is still plenty of time. The current usage and demand for HTTP/3 seems to be effectively zero.

This is the main reason I have to write my server code in NodeJS right now, HTTP/3 is a requirement for us

Why not use quic-go?

@pofl
Copy link

@pofl pofl commented Oct 25, 2020

As I see it, QUIC and HTTP/3 are so far into the IETF process that they are hardly bound to change anymore, definitely not substantially. Let me argue that if somebody would start implementing now they will not have to throw away any part of the implementation due to changes to the standard. By lying in wait for the finalization Go is only perpetuating the chicken-and-egg problem.

Not that any of this is a problem. Just my two cents.

@FireMasterK
Copy link

@FireMasterK FireMasterK commented Dec 29, 2020

Has there been any progress on bringing an official implementation? Is there any issue that is blocking this?

I can't seem to understand what's blocking this, there seems to be a lot of interest too. Sure, quic-go does the job, but I'm sure it's nice to have official support for quic.

@awnumar
Copy link
Contributor

@awnumar awnumar commented Apr 2, 2021

Overview of HTTP/3 support amongst clients and servers: https://daniel.haxx.se/blog/2021/04/02/where-is-http-3-right-now/

tldr: the level of HTTP/3 support in servers are surprisingly high considering very few clients enable it by default yet.

I assume that the rest of the browsers will also enable HTTP/3 by default soon, and the specs will be released not too long into the future. That will make HTTP/3 traffic on the web increase significantly.

The TLS library situation will continue to hamper wider adoption among non-browsers and smaller players.

@awnumar
Copy link
Contributor

@awnumar awnumar commented Apr 12, 2021

A few more browsers support it now: https://caniuse.com/http3

image

@nirui
Copy link

@nirui nirui commented Apr 13, 2021

@schoenenberg
Copy link

@schoenenberg schoenenberg commented May 28, 2021

QUIC has been published by the IETF as RFC 9000!

See this post: QUIC is now RFC 9000

HN Discussion: https://news.ycombinator.com/item?id=27310349

@DeedleFake
Copy link

@DeedleFake DeedleFake commented May 28, 2021

Note that that does not include HTTP/3. That'll be a separate RFC later on. I do think that this shows that it's about time to get an official QUIC implementation, though, either directly in net or in something like net/quic. If it starts in golang.org/x/net/quic first, that's fine, too.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented May 28, 2021

Quic is #44886

@aojea
Copy link

@aojea aojea commented Jun 2, 2021

I think it's clear that Go must support HTTP/3

@ianlancetaylor is it fair to assume that in a future if I do:

resp, err := http.Get("https://example.com/")

can I be using UDP underneath?

The context is about code that use the golang net/http library to implement HTTP/s probes, my understanding is that golang will probably end defaulting to http3, as it happened with http2, so, it will not be safe to assume http == TCP using net/http

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 2, 2021

@aojea I don't know anything about the code you mention, so I don't know whether it matters, but, yes, I agree that in the future it will not be safe to assume that the net/http package uses TCP underneath.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet