Is HTTP/3 Session Establishment really that much QUICker?
Welcome to the world, RFC9000 QUIC: A UDP-Based Multiplexed and Secure Transport”! We’re happy to have you.
QUIC is established as RFC9000, what perfect way to celebrate other than a blog post about QUIC connections? I’m going to focus on how a QUIC session is stood up, not the overall communication stream and the benefits it offers. Specifically, I’ll be writing about http Alt-Svc’s and the DNS HTTPS record type.
What you’re used to
When I think about QUIC, one of the things that comes to mind is having a quicker connection establishment time. Let’s first review how HTTPS over TCP establishes communication, so we can further compare that with what I’m going to write about today.
- Client sends DNS query for A/AAAA records of www.example.com to DNS server
- DNS server responds with A/AAAA records At this point we have spent 1 RTT for the time between client and DNS server, assuming no caching
- Client sends a TCP SYN for a src/dst port combo to the A/AAAA received from DNS server
- Server replies with TCP SYN/ACK for that port combination Once client receives SYN/ACK, we have now officially traveled 1 RTT for the time between client and server resource
- Client responds with ACK, relative seq numbers increment to 1 in wireshark from 0
So, we had a RTT between the client and the DNS server, and a RTT between the client and the returned server from our DNS query.
Oh wait, there’s more! We forgot about SSL/TLS. Let’s assume we asked for a https:// resource in our address bar, otherwise we’d have to add http->https redirection to our trace.
- Client sends a “client hello” with SSL protocol version and other information
- Server sends a “server hello” containing its version of SSL protocol, its server certificate, and other information You may now be seeing the pattern, but here’s another 1 RTT between the client and server
- Client sends its “Pre master secret” and possibly a client certificate, encrypted with the server certificate received in #7
- Server receives pre master secret from client, and now has the necessary information to start doing symmetric key encryption with the client for the session
- Client sends that it is finished (ready for encrypted comms)
- Server sends that it is finished (ready for encrypted comms) Another 1 RTT between client/server
Sure seems like a lot of steps when you put it that way. At the end of our tracing this we have: 1RTT between client and DNS server + 3RTT between client and the server holding our resources.
What’s the fuss?
Sure that’s a lot of steps in the normal HTTPS over TCP process, but what about throwing HTTP3/QUIC into the mix with RFC9000?
First, we need to establish a baseline in HTTP Alt-Svc’s. I dug up RFC7838 concerning HTTP Alternative Services. The purpose is to decouple service identifiers and locations for HTTP, meaning a server could respond with an alternative location or protocol for a service requested for by the client. If you check out the RFC, the introduction brings up a few use-cases, of which one is especially interesting to this blog post - cited here:
“An origin server might wish to offer access to its resources using a new protocol, such as HTTP/2 [RFC7540], or one using improved security, such as Transport Layer Security (TLS) [RFC5246].”
So, at the time of writing they mention HTTP/2 as the new protocol to be handled in a Alt-Svc message as a sort of redirection. Basically, the same idea is applied with HTTP3.
Above is a capture between my PC and my Github Pages blog that is served via the Cloudflare CDN. From Cloudflare servers I receive many Alt-Svc values, incuding ones that are specific to HTTP/3 (denoted by h3-draft# and h3=”:443”).
After the knowledge that HTTP/3 is available, our PC reaches out to the server using QUIC and you can see the included “client hello” within the QUIC UDP packet. At this point, what I would like you to see is that there are many, many steps included before you get to establish a HTTP/3 session in this situation.
Introducing the HTTPS DNS Record
Wouldn’t it be simpler to be informed during an earlier step whether QUIC is supported by the server instead of what we just covered with Alt-Svc? That’s exactly why I’ll talk about the SVCB/HTTPS record type.
For this, we move into RFC draft-ietf-dnsop-svcb-https-01 territory as it doesn’t seem like this has marinated quite long enough to become a full-on RFC. But, as you may know, there are implementations out there sometimes long before a draft becomes a mature RFC document.
In a nutshell, the purpose of the HTTPS record is for a DNS server to inform a querying client whether QUIC is available or not. Sounds easy, right? Let’s see it in action.
Above you see the DNS queries for next-hopself.net from my iPhone. We have an A, AAAA, and also the HTTPS record query - to which we have responses for each. Let’s take a closer look into the HTTPS record.
That’s more information than what you’re used to seeing in DNS answers, but there’s good reason for what’s in the details. ALPN stands for Application-Layer Protocol Negotiation, and the job of that parameter is to tell us the supported HTTP protocols for the queried domain. In this case, we see HTTP/3 drafts as well as HTTP/2 mentioned.
We also have IPv4 and IPv6 hints. In this specific case, the hints match what was sent in the A/AAAA. But, one could assume these hints could be completely different from the A/AAAA answers - allowing the client to choose to use the HTTPS record hints that support HTTP/3. Oh, the possibilities.
Weighing the Options
When you weigh the options, being able to get more intelligence from a DNS query lets you stand up a connection in less RTT’s. You get what you need from the DNS query as far as transport protocol and IP knowledge, and you reach out to the server host to initiate comms. The entrance of HTTP/3 allows us to leverage UDP transport for quicker connections - and now we can pair that with ultra-fast session initiations.
Thanks for reading
Further reading
Cloudflare - Speeding up HTTPS and HTTP/3 negotiation with… DNS