Support for QUIC protocol

[neilstuartcraig]

Hi

As discussed briefly in Slack, it'd be great to get support for the QUIC transport protocol (currently an IETF draft though has a dedicated working group and very wide support so is extremely likely to be ratified before too long):

There's a potentially helpful QUIC lib for Go which is used by Caddy - quic-go (MIT license).

QUIC is UDP-based so this might cause some issues/complexity and is worth calling out in docs as folks will need to ensure they allow udp:443 from load gen(s) to server(s)/LBs.

Please let me know if you need any more info from me.

Cheers

[liclac]

Okay, some super newbie questions from someone with only a surface-level understanding of the protocol:

• How exactly does dialing QUIC work? Does the client need to know that a server supports it, or is it a TLS handshake over TCP + a next-protocol marker (similar to HTTP/2)?
• Are the semantics different from HTTP/HTTP2 over TCP, or are there any gotchas that may not be immediately obvious?

What this basically adds up to is: can we add transparent QUIC support to k6/http, or would we need a separate k6/quic module?

[neilstuartcraig]

Sorry it took so long to get back rto you @liclac. i'm not massively familiar with the internals of quic (though i know a couple of people who are if we need more info) but:

How exactly does dialing QUIC work? Does the client need to know that a server supports it, or is it a TLS handshake over TCP + a next-protocol marker (similar to HTTP/2)?

QUIC works via an alt-svc advertisement (HTTP response header). I am just tinkering with a new website for myself at the moment so you can check that out if you want to see it in action: https://caddy.thedotproduct.org You'll see the behaviour there, probably easiest to use Chrome/Canary or you can enable QUIC for all sites in Chrome/Stable or Beta via chrome://flags#enable-quic -> "enabled"

I don't think the client needs to know anything about QUIC. The application comms protocol would likely actually be h2, this would be transported over the wire via QUIC. You should see this in Chrome dev tools in the "Protocol" column, this will read "http/2+quic/35". Since it's alt-svc'd, you'll see the base page being served over h2 initially, assets via h2+quic and then subsequent pages and/or reloads should be all over h2+quic as the client caches the availability of quic for the period defined in the alt-svc header (which also contains QUIC version hints - Canary supports 37 whereas stable is 35, i presume beta may be 36).

Are the semantics different from HTTP/HTTP2 over TCP, or are there any gotchas that may not be immediately obvious?

AFAIK, QUIC is primarily designed to have h2 layered on top of it, see https://tools.ietf.org/html/draft-tsvwg-quic-protocol-01#section-3 for more info and/or let me know if you need better detail - i'm got a long car journey in a couple of days with someone on the QUIC working group so i can dig for more detail as required :-)

.So, i think all this boils down to QUIC being implementable via k6/http, this would essentially be "wrapped" in QUIC. I'm not 100% sure about this so if you need more certainty then i'll do some digging to get it.

There's also another QUIC lib which I didn't know about, it has Go bindings, see https://en.wikipedia.org/wiki/QUIC#Server_support. Not sure if that's easier or not to use.

Hope that helps, sorry it's a bit rambling, bit tired today.

Cheers

[liclac]

I think this may make an interesting issue to put up as a bounty; @robingustafsson?

We'd need an option to enable it per-domain though; if we go with alt-svc + cache like a browser, it'd mean that every request until the alt-svc entry has been cached will have different performance characteristics and skew results.

[neilstuartcraig]

@liclac - I was talking to my colleague who's on the QUIC working group yesterday and it sounds like it'll be a little while until QUIC is formalised as a standard. This might mean it's too early to integrate now, it might mean further changes down the road. I'd suggest that it might be wiser to include it on your roadmap and review the status of the RFC regularly (happy to help with that) rather than implementing support now. That is, unless the quic-go lib API is stable enough already - might be worth a word with the author of that perhaps.

[bagder]

The IETF version of QUIC (as opposed to the google version) just got the 04 drafts out which is the first interop drafts - but they still have ways to go before actual HTTP traffic can be interchanged over this protocol (the first interop tests for this is basically just going to be the initial handshake and a little more). The Google QUIC protocol, which is what all existing implementations have implemented, is quite different in virtually all details even if the general concepts still remain.

[daog1]

https://github.com/daodao2007/k6， You can use this version, http3 support, use https://github.com/lucas-clemente/quic-go/ Add the -3 parameter when running