TLS-ytelse: QUIC og HTTP/3

HTTP/2 multiplekser flere strømmer over én enkelt TCP-tilkobling, og løser head-of-line-blokkeringen per tilkobling i HTTP/1.1. TCP i seg selv forårsaker imidlertid head-of-line-blokkering på transportlaget: Hvis ett TCP-segment går tapt, må alle dataene bak det i køen vente på retransmisjon, slik at alle HTTP/2-strømmene blokkeres samtidig. Et pakketap på 1 % kan redusere ytelsen til HTTP/2 til under ytelsen til HTTP/1.1 med flere tilkoblinger. QUIC (Quick UDP Internet Connections) løser dette ved å implementere multipleksede strømmer over UDP, der tapsgjenoppretting på strømnivå ikke blokkerer andre strømmer.

QUIC er en transportprotokoll bygget på UDP, utviklet av Google (2012–2015) og standardisert av IETF som RFC 9000 (2021). QUIC integrerer TLS 1.3 i transportlaget – det finnes ikke et separat TLS-håndtrykk oppå QUIC; TLS er vevd inn i selve QUIC-håndtrykket. QUIC tilbyr: multipleksede strømmer uten head-of-line-blokkering, tilkoblingsmigrering (opprettholdelse av tilkoblingen ved nettverksbytte, for eksempel fra WiFi til LTE), 0-RTT-etablering ved gjentatte tilkoblinger samt innebygd tapsdeteksjon og overbelastningskontroll. HTTP/3 (RFC 9114) er HTTP-semantikk over QUIC-strømmer.

QUIC-håndtrykket kombinerer etablering av tilkoblingen med TLS-forhandling. I den første flight-en (0 RTT i QUIC-terminologi) sender klienten Initial-pakker som inneholder TLS ClientHello. Serveren svarer med egne Initial-pakker (ServerHello) samt Handshake-pakker (krypterte utvidelser, sertifikat og Finished). Klienten sender Handshake Finished og er deretter klar til å sende applikasjonsdata – dette er 1-RTT. For 0-RTT-tilkoblinger sender klienten 0-RTT-pakker (applikasjonsdata) sammen med ClientHello ved hjelp av en nøkkel som er avledet fra forrige sesjons resumption secret. Dermed oppnås ingen ekstra rundeturer for hurtigbufrede sesjoner.

QUIC bruker fire separate krypteringsnivåer som tilsvarer fasene i TLS-nøkkelplanen: Initial (QUIC-avledet AEAD med en kjent konstant nøkkel – gir integritet, men ikke konfidensialitet mot sofistikerte angripere), Handshake (avledet fra TLS handshake_secret – gir konfidensialitet for TLS-håndtrykksmeldinger), 0-RTT (avledet fra forrige sesjons early_secret – krypterer applikasjonsdata i 0-RTT) og 1-RTT (avledet fra TLS master_secret – krypterer alle applikasjonsdata). QUIC-pakkehoder er delvis kryptert: pakkenummeret og nyttelasten er kryptert, men noe ruteinformasjon (Connection ID) forblir synlig for lastbalansere.

QUIC-tilkoblinger identifiseres med en Connection ID (CID) i stedet for en 4-tuppel (src IP, src port, dst IP, dst port). Dette gjør at tilkoblinger kan overleve nettverksendringer: Når en mobilklient bytter fra WiFi til LTE, endres IP-adressen, men CID-en forblir den samme. Klienten sender en PATH_CHALLENGE-frame over den nye banen; serveren svarer med PATH_RESPONSE og validerer den nye adressen. Tilkoblingen fortsetter sømløst uten ny forhandling. TCP støtter ikke dette – en TCP-tilkobling er bundet til sin 4-tuppel og må etableres på nytt ved nettverksbytte, noe som krever et nytt TLS-håndtrykk. QUIC-migrering forbedrer den opplevde ytelsen betydelig for mobilbrukere.

HTTP/3 tilordner HTTP-semantikk til QUIC-strømmer. Hvert HTTP-forespørsel-svar-par opptar en separat toveis QUIC-strøm. QUIC-strømmer er uavhengige: Tap på strøm 3 blokkerer ikke strøm 7. HTTP/3 bruker QPACK til komprimering av hoder (og erstatter HTTP/2s HPACK) – QPACK ble redesignet for å fungere uten å kreve levering i riktig rekkefølge. To dedikerte enveis kontrollstrømmer frakter innstillinger og instruksjoner for dekoder og enkoder. Server push i HTTP/3 bruker push-strømmer (enveis). Den samlede effekten er at HTTP/3 yter bedre enn HTTP/2, særlig under forhold med pakketap (mobilnettverk og overbelastede forbindelser), der TCPs head-of-line-blokkering er mest skadelig.

Praktiske målinger av ytelsen til QUIC og HTTP/3 viser blandede resultater avhengig av nettverksforholdene. På nettverk av høy kvalitet (lav latenstid og lite pakketap) yter HTTP/3 og HTTP/2 omtrent likt – QUIC-overheaden (større hoder og prosesseringskostnader for UDP) kan til og med gjøre HTTP/3 litt tregere. På nettverk med pakketap (> 1 % pakketap, noe som er vanlig i mobil- og satellittnettverk) yter HTTP/3 betydelig bedre enn HTTP/2. Google rapporterte en reduksjon i rebuffering på 7–8 % på YouTube ved overgang til QUIC. Facebook (Meta) rapporterte 7–15 % bedre forespørselslatenstid for Instagram-feeder over QUIC. Gevinstene er mest synlige i hale-latenstiden (p95, p99), der TCP-stans på grunn av retransmisjoner har størst innvirkning.

Lastbalansering av QUIC er mer komplisert enn for TCP fordi QUIC er UDP-basert, og tilstandsfrie UDP-lastbalansere ikke kan opprettholde tilkoblingsaffinitet. IETF-dokumentet draft-ietf-quic-load-balancers definerer en tilnærming der serverne koder ruteinformasjon inn i Connection ID, slik at lastbalansere kan rute pakker fra samme tilkobling til samme server uten å spore tilstand per tilkobling. Connection ID inneholder en kryptert server-ID som bruker en delt nøkkel mellom lastbalanseren og serverne. Cloudflare, Fastly og Nginx implementerer varianter av denne tilnærmingen. NAT-gjennomgang er en annen utfordring: QUIC-tilkoblinger må overleve NAT-rebinding, noe som håndteres av tilkoblingsmigreringsmekanismen.

Store CDN-er har tatt i bruk QUIC og HTTP/3 i stor skala. Cloudflare har levert HTTP/3 siden 2019 og rapporterer at omtrent 20 % av trafikken bruker QUIC der både klienten og serveren støtter det. Fastly, Akamai og AWS CloudFront støtter HTTP/3 ved edge-lagene sine. Googles egen infrastruktur (Search, YouTube og Gmail) har brukt QUIC internt siden 2013 og gjør HTTP/3 tilgjengelig offentlig. CDN-distribusjoner drar nytte av QUICs 0-RTT-gjenopptakelse: Gjentatte besøkende etablerer tilkoblinger raskere, og tilkoblingsmigrering forbedrer ytelsen for mobilbrukere som beveger seg mellom aksesspunkter under innholdslevering.

QUICs UDP-baserte utforming medfører spesifikke sikkerhetshensyn. Forsterkningsangrep: En angriper kan forfalske en kilde-IP-adresse og sende små Initial-pakker, slik at serveren sender store Handshake-svar til offeret. QUIC reduserer dette ved å begrense serversvarene til 3x mengden mottatte data frem til adressevalideringen er fullført, via RETRY-mekanismen. Tilkoblingsflom: QUIC-servere må begrense hastigheten på nye tilkoblingsforsøk fra samme IP-adresse. Angrep på versjonsforhandlingen forhindres ved at versjonen inkluderes i det kryptografisk beskyttede håndtrykket. QUICs innebygde kryptering innebærer at inspeksjonsutstyr ikke kan analysere QUIC-nyttelasten uten å være på nettverksbanen og ha serversertifikatet, noe som gir bedre personvern enn inspiserbar TCP-trafikk.

Distribusjon av HTTP/3 krever: (1) En QUIC-kompatibel server (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed eller på applikasjonsnivå via bibliotekene quic-go, aioquic og ngtcp2). (2) At UDP-port 443 er åpen i brannmurene – mange bedriftsbrannmurer blokkerer UDP 443, slik at QUIC faller tilbake til TCP/TLS. (3) At støtte for HTTP/3 annonseres via svarhodet Alt-Svc: Alt-Svc: h3=":443"; ma=86400, slik at HTTP/2-klienter får beskjed om å oppgradere. (4) QUIC-bevisste lastbalansere eller L4-gjennomkobling av UDP. (5) Overvåking av QUIC-spesifikke måledata: hendelser for tilkoblingsmigrering, akseptgrad for 0-RTT og grad av protokolltilbakefall. Gradvis utrulling med tilbakefall til HTTPS er transparent for klienter som ikke støtter QUIC.

QUIC integrerer TLS 1.3 i transportlaget over UDP og eliminerer TCPs head-of-line-blokkering ved hjelp av uavhengig tapsgjenoppretting per strøm. Connection ID-er muliggjør migrering på tvers av nettverksendringer uten ny forhandling. HTTP/3 tilordner HTTP til QUIC-strømmer ved hjelp av QPACK-komprimering av hoder. 0-RTT-gjenopptakelse av tilkoblinger gjenbruker TLS-sesjonshemmeligheter. QUIC yter betydelig bedre enn HTTP/2, særlig ved pakketap (mobilnettverk og overbelastede nettverk). Lastbalansering av QUIC krever at serverruting kodes inn i Connection ID-er. Distribusjon krever UDP 443, QUIC-kompatible servere og Alt-Svc-hoder for å annonsere protokollen.