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 · 20 comments
Open

net/http: support HTTP/3 #32204

johanbrandhorst opened this issue May 23, 2019 · 20 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.

@bradfitz bradfitz added this to the Unplanned milestone May 23, 2019
@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

@LOVELiberty6699
Copy link

@LOVELiberty6699 LOVELiberty6699 commented Feb 4, 2020

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.

As far as I know,there are some different between HTTP/3 and IETF QUIC. HTTP/3 is an Application Layer Protocol, but IETF QUIC is a Transport Protocol. TCP, UDP and iQUIC are in the same layer. IETF QUIC can replace TCP, so one day every Protocol based on TCP be able to work based on IETF QUIC, such as SSH. HTTP/3 is based on IETF QUIC. So I think that the support of HTTP/3 is not root. We should add the support of IETF QUIC firstly, and then add the support of HTTP/3.
HTTP/2 and HTTP/3 work in a similar way, but HTTP/2 uses TCP,
while HTTP/3 uses IETF QUIC as the transport protocol. HTTP/3 support is optional. When enabled, HTTP/3 can fall back to HTTP/2 or HTTPS if not available.
So should we need to make some modification on this issue or reopening a new issue to track IETF QUIC?

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

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

@ShivanshVij
Copy link

@ShivanshVij ShivanshVij commented Oct 24, 2020

NodeJS v15 was released earlier today, and it already includes experimental support for the Quic protocol.

Looking at providers like Cloudflare now, I’d say that Golang might be behind the times for this feature.

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

@LOVELiberty6699
Copy link

@LOVELiberty6699 LOVELiberty6699 commented Oct 31, 2020

QUIC is a new networking transport protocol that combines the features of TCP, TLS, and more. HTTP/3 is the latest version of HTTP, the protocol that carries the vast majority of Web traffic. HTTP/3 only runs over QUIC.
So I think the support of QUIC is also important in th future. Http3 and QUIC are work in different network layers. HTTP/3 only runs over QUIC. It's obvious that we need support QUIC.

It would be nice to see a discussion started amongst people actually capable of bringing it into the standard library.
https://link.zhihu.com/?target=https%3A//blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

@jimist
Copy link

@jimist jimist commented Dec 29, 2020

It kind of annoys me that nobody is touching to implement it in net package.
Has the work started by somebody? If not is it welcomed?!!

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

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