Caddy: update quic-go to v0.10.0

[marten-seemann]

Hello @mholt, I just released quic-go v0.10.0 yesterday: https://github.com/lucas-clemente/quic-go/releases/tag/v0.10.0.
v0.10.0 supports QUIC 43, which is currently used by Chrome Stable, as well as QUIC 44, which is currently being rolled out in Chrome Canary. It also still support QUIC 39, which is still supported by many older Chromes out there.
This would be a good time to update the quite outdated QUIC that Caddy is currently vendoring.

[mholt]

Nice! I will try to update the quic branch of the repo today with the updated vendoring.

[marten-seemann]

Could you update it in the main branch as well? There's no point in having support for outdated QUIC versions in the master branch.
quic-go should be quite mature now, and I don't expect any major bugs in the Google QUIC versions we're supporting. I'd be very happy if more Caddy users could benefit from QUIC, and a separate branch makes this more complicated.

Almost all of the commits for quic-go are moving the code towards IETF QUIC, which is currently being specified, and scheduled to be finished later this year.

[mholt]

I want to, but I feel really hesitant to add ~80K more LoC for a testing framework into our vanilla production builds -- I'm trying to avoid bloating the core Caddy binary as much as possible. Even if that isn't a huge concern, I _am_ concerned about committing that much to source control -- every MB bogs down the build server.

However, the latter may be alleviated somewhat once we use Go modules. I'm not sure when that will happen, though.

[marten-seemann]

The testing framework is not 80k LoC, it's around 25k. While it definitely is annoying that the go vendoring approach doesn't allow us to exclude those, I don't think this will be a real issue, especially since it won't have any effect on the binary, since the compiler will eliminate dead code anyway.

The main difference in LoC here comes the fact that we're now vendoring all our dependencies (which we should have done right away), including the TLS 1.3 library quic-go is using.
QUIC is a quite complex protocol, even more so for IETF QUIC. Of course it takes quite some code to make it work. For that code, you get some real world performance benefits on lossy connections, as Google's measurements show.
Supporting gQUIC and IETF QUIC at the same time (which we will need to do, since there will be a transition period where some browsers / browser versions will support IETF QUIC, while Chrome still support gQUIC) is a lot of work, and adds a quite bit of complexity. I've been making this effort because I assumed that Caddy and Caddy's users would appreciate being one of the first web servers in the market that offers QUIC support.

[marten-seemann]

Hello @mholt,

I decided to have a closer look at the Go vendoring, and I think I found a solution that will work for all of us. Since the testing framework is only needed for our integration tests, but the Go vendoring tools provide no way to exclude a certain dependency, an easy (although a bit hacky) fix is to create a new quic-go release without the integration tests. I did that here: https://github.com/lucas-clemente/quic-go/releases/tag/v0.10.0-no-integrationtests. I'll make sure to create such a release for every quic-go version that is intented to be included in Caddy.

Using this release, and cleaning up Caddy's vendor folder a bit (quic-go now vendors all of its dependencies, so Caddy doesn't need to vendor them), I managed to vendor the current quic-go version while at the same time reducing the code size by more than 4000 LoC (see #2288).

[Henrocker]

PR #2288 works like a charm. 👍