> we refer to QUIC and HTTP/3 together as QUIC
My understand is that HTTP/3 always means QUIC is used according to the standard. But that QUIC can be used for other protocols as well. FB's terminology seems to be backwards.
My understand is that HTTP/3 always means QUIC is used according to the standard. But that QUIC can be used for other protocols as well. FB's terminology seems to be backwards.
The output from the experiments was new standardization efforts at the IETF. Google's SPDY, which was a binary HTTP protocol over TLS, eventually resulted in HTTP/2 which there's a fair chance you use today.
The other idea, QUIC, is a much bigger lift. It replaces not just the HTTP protocol and TLS but the whole stack, even TCP. At the IETF this work was split into two pieces, the IETF's QUIC is just the TCP replacement, an encrypted connection-oriented reliable protocol. So the HTTP part of the problem is being standardised as HTTP/3
Google's QUIC "gQUiC" will be obsolete once the standardized protocol is finished. Right now a Chrome talking to e.g. GMail uses gQUIC, once the standards work is firmed up it'll speak HTTP/3 and then maybe a year later Google's sites will discontinue gQUIC because it's just maintenance effort with no residual value.
Of course an all new IP would be great, but the issue is it would take very long for all the soft and hardware to support it and UDP is simply there.
I would prefer for a new HTTP to go an all new way, leaving behind UDP and TCP and build something new. Then support fallback over HTTP1/2 until everything else caught up.
At least not one that works over the general Internet - controlled intra-organisation networks might possibly be able to do so, but very rarely.
There are too many broken machines on the Internet that assume all IP traffic is one of TCP, UDP and ICMP. And far too many are configured to screw up ICMP too.
So new protocols MUST use TCP or UDP as their base layer instead of raw IP.
So yes, QUIC uses UDP, but that should be considered an implementation detail. A hack for the lack of IP support on the Internet.
HTTP/3 uses QUIC like HTTP/1 and HTTP/2 use TCP + TLS, but QUIC is not limited to use by HTTP/3.
QUIC's development has been, basically, paused while HTTP/3 is finalised and then the IETF will pick up where it left off and work out how other higher-layer protocols will work using QUIC as the transport layer.
Having said that, I wish we could replace the "port" concept. With the size of address space IPV6 allows, 16 bits for ports is looking a bit small.
And for fancier protocols it doesn't matter anyway because they have their own concept of a connection identifier. WireGuard for example doesn't care at all, packets arrive and either they're authenticated or they aren't, it silently discards all packets that aren't authenticated, QUIC optionally has a connection ID that can survive changing the 4-tuple as far as I remember.
If you wish you did have more ports, the IPv6 address space makes it pretty cheap to just acquire more addresses on your network and use those, but I do not sense much appetite because people don't feel like they're short of ports.
You do see people spinning up more addresses to not need SNI or similar. If you have sixty virtual machines on one hardware box, having sixty IPv6 addresses, one per VM, means now the packets for VM #4 and VM #18 are separated on the wire, which might be convenient but that doesn't feel like it's due to running out of ports, it's just more convenient.
HTTP/3 implies IETF QUIC. IETF QUIC itself can be used for non-HTTP protocols, though, just like TCP can be used for protocols that aren't HTTP/2.
Maybe I can publish the virtual “WebSocketTransport” thing once I'm satisfied with it.