TLS-prestaties: QUIC en HTTP/3

HTTP/2 multiplexeert meerdere streams over één TCP-verbinding en lost daarmee de blokkering aan het begin van de wachtrij per verbinding van HTTP/1.1 op. TCP zelf veroorzaakt echter blokkering aan het begin van de wachtrij op de transportlaag: als één TCP-segment verloren gaat, wacht alle data erachter in de wachtrij op hertransmissie, waardoor alle HTTP/2-streams tegelijk worden geblokkeerd. 1% pakketverlies kan de prestaties van HTTP/2 verslechteren tot onder die van HTTP/1.1 met meerdere verbindingen. QUIC (Quick UDP Internet Connections) lost dit op door gemultiplexte streams boven op UDP te implementeren, waarbij herstel van verlies op streamniveau andere streams niet blokkeert.

QUIC is een transportprotocol dat op UDP is gebaseerd, ontwikkeld door Google (2012-2015) en door IETF gestandaardiseerd als RFC 9000 (2021). QUIC integreert TLS 1.3 in de transportlaag — er is geen afzonderlijke TLS-handshake boven op QUIC; TLS is verweven met de QUIC-handshake zelf. QUIC biedt: gemultiplexte streams zonder blokkering aan het begin van de wachtrij, verbindingmigratie (de verbinding behouden wanneer je van netwerk wisselt, bijvoorbeeld van WiFi naar LTE), verbindingen in 0 RTT tot stand brengen voor herhaalde verbindingen, en ingebouwde detectie van verlies en congestiebeheer. HTTP/3 (RFC 9114) bestaat uit HTTP-semantiek boven op QUIC-streams.

De QUIC-handshake combineert het tot stand brengen van een verbinding met TLS-onderhandeling. In de eerste pakketronde (0 RTT in de QUIC-terminologie) stuurt de client Initial-pakketten met daarin ClientHello van TLS. De server antwoordt met zijn eigen Initial (ServerHello) en Handshake-pakketten (versleutelde extensies, certificaat, Finished). De client stuurt Handshake Finished en kan daarna toepassingsgegevens verzenden — dit is 1 RTT. Bij 0-RTT-verbindingen stuurt de client 0-RTT-pakketten (toepassingsgegevens) tegelijk met ClientHello, met een sleutel die is afgeleid van het hervattingsgeheim van de vorige sessie. Zo zijn er voor sessies in de cache geen extra retourrondes nodig.

QUIC gebruikt vier afzonderlijke versleutelingsniveaus die overeenkomen met fasen in de TLS-sleutelplanning: Initial (QUIC-afgeleide AEAD met een bekende constantsleutel — biedt integriteit maar geen vertrouwelijkheid tegen geavanceerde aanvallers), Handshake (afgeleid van TLS handshake_secret — biedt vertrouwelijkheid voor TLS-handshakeberichten), 0-RTT (afgeleid van early_secret van de vorige sessie — versleutelt 0-RTT-toepassingsgegevens) en 1-RTT (afgeleid van TLS master_secret — versleutelt alle toepassingsgegevens). QUIC-pakketkoppen zijn gedeeltelijk versleuteld: het pakketnummer en het gegevensgedeelte zijn versleuteld, maar sommige routeringsgegevens (Connection ID) blijven zichtbaar voor taakverdelers.

QUIC-verbindingen worden geïdentificeerd met een Connection ID (CID) in plaats van met een 4-tuple (bron-IP, bronpoort, doel-IP, doelpoort). Hierdoor kunnen verbindingen netwerkveranderingen overleven: wanneer een mobiele client overschakelt van WiFi naar LTE, verandert het IP-adres maar blijft de CID hetzelfde. De client stuurt een PATH_CHALLENGE-frame over het nieuwe pad; de server antwoordt met PATH_RESPONSE en valideert daarmee het nieuwe adres. De verbinding gaat naadloos verder zonder nieuwe onderhandeling. TCP kan dit niet ondersteunen — een TCP-verbinding is gebonden aan zijn 4-tuple en moet bij een netwerkverandering opnieuw tot stand worden gebracht, waarvoor een nieuwe TLS-handshake nodig is. QUIC-migratie verbetert de ervaren prestaties voor mobiele gebruikers aanzienlijk.

HTTP/3 vertaalt HTTP-semantiek naar QUIC-streams. Elk HTTP-verzoek-antwoordpaar gebruikt een afzonderlijke bidirectionele QUIC-stream. QUIC-streams zijn onafhankelijk: verlies op stream 3 blokkeert stream 7 niet. HTTP/3 gebruikt QPACK voor headercompressie (ter vervanging van HPACK uit HTTP/2) — QPACK is opnieuw ontworpen om zonder aflevering in de juiste volgorde te werken. Twee speciale unidirectionele besturingsstreams vervoeren instellingen en decoder-/encoderinstructies. Server push in HTTP/3 gebruikt pushstreams (unidirectioneel). Het totale effect is dat HTTP/3 vooral bij pakketverlies beter presteert dan HTTP/2, zoals op mobiele netwerken en overbelaste paden, waar blokkering aan het begin van de wachtrij door TCP de meeste schade veroorzaakt.

Metingen van de prestaties van QUIC en HTTP/3 in de praktijk laten verschillende resultaten zien, afhankelijk van de netwerkomstandigheden. Op netwerken van hoge kwaliteit (lage latentie, weinig pakketverlies) presteren HTTP/3 en HTTP/2 vergelijkbaar — de extra belasting van QUIC (grotere koppen en extra UDP-verwerking) kan HTTP/3 zelfs iets langzamer maken. Op netwerken met veel verlies (meer dan 1% pakketverlies, wat vaak voorkomt bij mobiele en satellietverbindingen) presteert HTTP/3 aanzienlijk beter dan HTTP/2. Google meldde 7-8% minder opnieuw bufferen op YouTube bij de overstap naar QUIC. Facebook (Meta) meldde via QUIC een verbetering van 7-15% in de verzoeklatentie voor Instagram-feeds. De winst is het duidelijkst in de staartlatentie (p95, p99), waar vertragingen door TCP-hertransmissies de grootste invloed hebben.

Taakverdeling van QUIC is complexer dan die van TCP, omdat QUIC op UDP is gebaseerd en stateless UDP-taakverdelers geen verbindingsaffiniteit kunnen bieden. IETF draft-ietf-quic-load-balancers definieert een aanpak waarbij servers routeringsinformatie coderen in de Connection ID, zodat taakverdelers pakketten van dezelfde verbinding naar dezelfde server kunnen sturen zonder status per verbinding bij te houden. De Connection ID bevat een versleutelde server-ID met een gedeelde sleutel tussen de taakverdeler en de servers. Cloudflare, Fastly en Nginx implementeren varianten van deze aanpak. NAT-doorkruising is een ander aandachtspunt: QUIC-verbindingen moeten NAT-herbindingen overleven, wat wordt afgehandeld door het mechanisme voor verbindingmigratie.

Grote CDN's hebben QUIC en HTTP/3 op grote schaal uitgerold. Cloudflare levert sinds 2019 HTTP/3 en meldt dat ongeveer 20% van het verkeer QUIC gebruikt wanneer zowel de client als de server dit ondersteunen. Fastly, Akamai en AWS CloudFront ondersteunen HTTP/3 aan hun randlocaties. De eigen infrastructuur van Google (Search, YouTube, Gmail) gebruikt QUIC sinds 2013 intern en stelt HTTP/3 publiek beschikbaar. CDN-implementaties profiteren van QUIC's hervatting met 0 RTT: terugkerende bezoekers brengen sneller verbindingen tot stand en verbindingmigratie verbetert de prestaties voor mobiele gebruikers die tijdens het leveren van content tussen toegangspunten bewegen.

Het op UDP gebaseerde ontwerp van QUIC brengt specifieke beveiligingsoverwegingen met zich mee. Versterkingsaanvallen: een aanvaller kan een bron-IP vervalsen en kleine Initial-pakketten versturen, waardoor de server grote Handshake-antwoorden naar het slachtoffer stuurt — QUIC beperkt dit door serverantwoorden te beperken tot driemaal de ontvangen hoeveelheid gegevens totdat de adresvalidatie is voltooid (via het RETRY-mechanisme). Bij verbindingsoverspoeling moeten QUIC-servers nieuwe verbindingspogingen vanaf hetzelfde IP-adres beperken. Aanvallen op versieonderhandeling worden voorkomen door de versie op te nemen in de cryptografisch beveiligde handshake. Door de ingebouwde versleuteling van QUIC kunnen inspectieapparaten de QUIC-gegevens niet analyseren zonder zich op het netwerkpad naar de server te bevinden en over het servercertificaat te beschikken — dit verbetert de privacy ten opzichte van inspecteerbaar TCP-verkeer.

Voor het implementeren van HTTP/3 heb je het volgende nodig: (1) Een QUIC-compatibele server (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed of implementatie op applicatieniveau via de bibliotheken quic-go, aioquic, ngtcp2). (2) UDP-poort 443 die openstaat in firewalls — veel bedrijfsfirewalls blokkeren UDP 443, waardoor QUIC terugvalt op TCP/TLS. (3) Aankondiging van HTTP/3-ondersteuning via de Alt-Svc-responsheader: Alt-Svc: h3=":443"; ma=86400, zodat HTTP/2-clients worden aangespoord om te upgraden. (4) QUIC-bewuste taakverdelers of L4-UDP-doorvoer. (5) Bewaking van QUIC-specifieke meetwaarden: gebeurtenissen rond verbindingmigratie, het acceptatiepercentage van 0-RTT en het terugvalpercentage van het protocol. Een geleidelijke uitrol met terugval naar HTTPS is transparant voor clients die QUIC niet ondersteunen.

QUIC integreert TLS 1.3 in de transportlaag boven op UDP en elimineert blokkering aan het begin van de wachtrij door TCP met onafhankelijk herstel van verlies per stream. Connection ID's maken migratie tussen netwerken mogelijk zonder nieuwe onderhandeling. HTTP/3 vertaalt HTTP naar QUIC-streams met QPACK-headercompressie. Voor het hervatten van verbindingen met 0 RTT worden TLS-sessiegeheimen opnieuw gebruikt. QUIC presteert vooral beter dan HTTP/2 bij pakketverlies, zoals op mobiele en overbelaste netwerken. Voor taakverdeling van QUIC moet routeringsinformatie van servers in Connection ID's worden gecodeerd. Voor de implementatie zijn UDP 443, QUIC-compatibele servers en Alt-Svc-headers voor de aankondiging van het protocol nodig.