caddy
caddy copied to clipboard
caddyserver
consider enabling QUIC by default
Chrome has enabled QUIC for a large fraction of Chrome Stable. quic-go has been supporting draft-29 for a while now, and will add support for draft-32 in the next release (in case Chrome adds support for that version, which, as far as I know, they don't plan at this point). quic-go has been the default transport in IPFS and Filecoin for a few months already.
We might want to find a solution for #3055 first (or disable Retry entirely), so users will actually enjoy the reduced handshake latency (1 round-trip instead of 2 in the case of TLS 1.3 over TCP).
@Y-A-K-E Why would that be? If so, that would be a bug. Can you share some more details?
Overall I'm open to this. Maybe later, once HTTP/3 is finalized and has broad client support.
As a data point, here's one case study where not binding to UDP by default is preferred: https://twitter.com/itstelesphoreo/status/1333457155324846085
We'll definitely want to add a disable_http3 option, to flip it from opt-in (currently) to opt-out.
Overall I'm open to this. Maybe later, once HTTP/3 is finalized and has broad client support.
@mholt HTTP/3 is (basically) finalized. The QUIC transport documents have completed IETF Last Call a while back. The documents are now in the RFC editor queue, so it will still take a few months until the final RFCs are published. However, nobody expects any protocol changes at this point. Chrome has enabled IETF QUIC by default, see https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html.
As a data point, here's one case study where not binding to UDP by default is preferred: https://twitter.com/itstelesphoreo/status/1333457155324846085
This boils down to how to configure the address:port in the Caddyfile. Currently, saying domain:443 means listen on TCP port 443, and with HTTP/3 enabled to also listen on port 443 for QUIC. Do we need a way to specify an alternative UDP port?
As QUIC support is advertised via Alt-Svc, any port would be discoverable by browsers after the first visit to the site. Of course, in the future, browsers might race a TCP and QUIC connection to the respective 443 ports, so having QUIC default to 443 definitely makes sense.
We'll definitely want to add a disable_http3 option, to flip it from opt-in (currently) to opt-out.
@francislavoie +1
Do we need a way to specify an alternative UDP port?
That might be useful sooner or later. Does the quic-go API have that ability? If so, we can find a way to expose it in Caddy.
so having QUIC default to 443 definitely makes sense.
I agree; am just noting that there are cases where it will need to be configurable.
Thanks!
Does the quic-go API have that ability? If so, we can find a way to expose it in Caddy.
quic-go doesn't really care about the port. You pass a net.PacketConn to quic-go, so this entirely in the caller's responsibility.
We still need to solve https://github.com/caddyserver/caddy/issues/3055, https://github.com/caddyserver/caddy/issues/4348, and https://github.com/caddyserver/caddy/issues/4372 first, I think.
Yeah, probably no way this is going to happen until the feature is no longer experimental. But, sometime in the future, I do think it can happen.
Looks like there is only a single showstopper left: #3055
As the final HTTP/3 core specs are very very very close, it would be cool if caddy would be one of the first to officially support it :wink:
@bt90 I agree. @marten-seemann can you please review #4707? It's not done yet, but I want to make sure I'm on the right track with AcceptToken().
Can people also please test that branch (http3-default). It'd be good to know how many things this will break before we release it sometime after v2.5.0.
There's also https://github.com/caddyserver/caddy/issues/4294 btw, i.e. strict_sni_host and client authentication not working with HTTP3. My understanding is that tls.ConnectionState doesn't get filled because 0-RTT means the handshake gets completed asynchronously.
Good point; we probably won't be able to enable HTTP/3 if client auth is configured.
With #4819 being fixed in the latest release, these are the missing bits:
- [x] #4294
- [x] #3055
- [ ] #4849
@otbutz Yep! #4294 might be more of an edge case, and apparently depends on something upstream in Go that we don't have (yet?) -- it only affects connections that use strict_sni_host, which I rarely see outside of TLS Mutual Auth scenarios (which are also rare).
As for #3055, I'm nearly done with that in https://github.com/caddyserver/caddy/pull/4707. I am just waiting for some thoughts/feedback from @marten-seemann about how to verify tokens.
But yeah, I'd be ready to get this into a prerelease as soon as it's ready.