net/http: support HTTP/3

[johanbrandhorst]

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]

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]

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]

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]

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]

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]

🚀
https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

[hherman1]

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

[ianlancetaylor]

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]

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]

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]

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]

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]

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]

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]

@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

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]

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]

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]

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]

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.