TLS-prestanda: QUIC och HTTP/3

HTTP/2 multiplexar flera strömmar över en enda TCP-anslutning och löser HTTP/1.1:s head-of-line-blockering per anslutning. TCP orsakar dock fortfarande head-of-line-blockering på transportlagret: om ett TCP-segment går förlorat måste all data bakom det i kön vänta på en återsändning, vilket blockerar alla HTTP/2-strömmar samtidigt. En paketförlust på 1 % kan försämra HTTP/2-prestandan så att den blir sämre än HTTP/1.1 med flera anslutningar. QUIC (Quick UDP Internet Connections) löser detta genom att implementera multiplexade strömmar över UDP, där återställning efter förlust på strömnivå inte blockerar andra strömmar.

QUIC är ett transportprotokoll byggt ovanpå UDP, utvecklat av Google (2012–2015) och standardiserat av IETF som RFC 9000 (2021). QUIC integrerar TLS 1.3 på transportlagret — det finns ingen separat TLS-handskakning ovanpå QUIC; TLS är i stället integrerat i själva QUIC-handskakningen. QUIC tillhandahåller multiplexade strömmar utan head-of-line-blockering, anslutningsmigrering (anslutningen bibehålls vid nätverksbyte, till exempel från WiFi till LTE), anslutningsetablering med 0-RTT för återkommande anslutningar samt inbyggd detektering av paketförlust och överbelastningskontroll. HTTP/3 (RFC 9114) är HTTP-semantik över QUIC-strömmar.

QUIC-handskakningen kombinerar anslutningsetablering med TLS-förhandling. I den första sändningen (0 RTT i QUIC-terminologi) skickar klienten Initial-paket som innehåller TLS ClientHello. Servern svarar med egna Initial-paket (ServerHello) samt Handshake-paket (krypterade tillägg, certifikat och Finished). Klienten skickar Handshake Finished och kan därefter skicka applikationsdata — detta är 1-RTT. Vid 0-RTT-anslutningar skickar klienten 0-RTT-paket (applikationsdata) tillsammans med ClientHello, med en nyckel som härletts från den föregående sessionens resumption secret, vilket ger noll extra rundresor för cachade sessioner.

QUIC använder fyra separata krypteringsnivåer som motsvarar faserna i TLS-nyckelschemat: Initial (QUIC-härledd AEAD med en känd konstantnyckel — ger integritet men inte konfidentialitet mot sofistikerade angripare), Handshake (härledd från TLS handshake_secret — ger konfidentialitet för TLS-handskakningsmeddelanden), 0-RTT (härledd från den föregående sessionens early_secret — krypterar 0-RTT-applikationsdata) och 1-RTT (härledd från TLS master_secret — krypterar all applikationsdata). QUIC-pakethuvuden krypteras delvis: paketnumret och nyttolasten är krypterade, men viss routningsinformation (Connection ID) förblir synlig för lastbalanserare.

QUIC-anslutningar identifieras med ett Connection ID (CID) i stället för en 4-tuple (src IP, src port, dst IP, dst port). Det gör att anslutningar kan överleva nätverksbyten: när en mobilklient byter från WiFi till LTE ändras IP-adressen, men CID förblir detsamma. Klienten skickar en PATH_CHALLENGE-frame över den nya sökvägen och servern svarar med PATH_RESPONSE, vilket validerar den nya adressen. Anslutningen fortsätter utan avbrott och utan omförhandling. TCP stöder inte detta — en TCP-anslutning är bunden till sin 4-tuple och måste etableras på nytt vid nätverksbyte, vilket kräver en ny TLS-handskakning. QUIC-migrering förbättrar den upplevda prestandan avsevärt för mobilanvändare.

HTTP/3 mappar HTTP-semantik till QUIC-strömmar. Varje begäran-svar-par från HTTP använder en separat dubbelriktad QUIC-ström. QUIC-strömmar är oberoende: förlust på ström 3 blockerar inte ström 7. HTTP/3 använder QPACK för headerkomprimering (i stället för HTTP/2:s HPACK) — QPACK har utformats om för att fungera utan krav på leverans i ordning. Två dedikerade enkelriktade kontrollströmmar överför inställningar samt avkodnings- och kodningsinstruktioner. Server push i HTTP/3 använder push-strömmar (enkelriktade). Den övergripande effekten är att HTTP/3 har betydligt bättre prestanda än HTTP/2 framför allt vid paketförlust (i mobilnät och på överbelastade nätverksvägar), där TCP:s head-of-line-blockering gör störst skada.

Mätningar av QUIC- och HTTP/3-prestanda i verkliga miljöer visar blandade resultat beroende på nätverksförhållandena. I nätverk av hög kvalitet (låg latens och låg paketförlust) presterar HTTP/3 och HTTP/2 ungefär lika bra — QUIC-overheaden (större headers och overhead för UDP-bearbetning) kan till och med göra HTTP/3 något långsammare. I nätverk med paketförlust (> 1 %, vilket är vanligt i mobil- och satellitnät) presterar HTTP/3 betydligt bättre än HTTP/2. Google rapporterade en minskning av ombuffring i YouTube med 7–8 % vid övergången till QUIC. Facebook (Meta) rapporterade 7–15 % lägre latens för begäranden i Instagram-flöden via QUIC. Vinsterna syns tydligast i tail latency (p95 och p99), där stopp på grund av TCP-återsändningar påverkar mest.

Lastbalansering av QUIC är mer komplext än för TCP eftersom QUIC är UDP-baserat och tillståndslösa UDP-lastbalanserare inte kan upprätthålla anslutningsaffinitet. IETF-dokumentet draft-ietf-quic-load-balancers definierar en metod där servrar kodar routningsinformation i Connection ID, så att lastbalanserare kan dirigera paket från samma anslutning till samma server utan att hålla tillstånd per anslutning. Connection ID innehåller ett krypterat server-ID som använder en delad nyckel mellan lastbalanseraren och servrarna. Cloudflare, Fastly och Nginx implementerar varianter av denna metod. NAT-traversering är en annan utmaning: QUIC-anslutningar måste överleva NAT-ombindning, vilket hanteras av anslutningsmigreringsmekanismen.

Större CDN:er har driftsatt QUIC och HTTP/3 i stor skala. Cloudflare har levererat HTTP/3 sedan 2019 och uppger att cirka 20 % av trafiken använder QUIC där både klient och server stöder det. Fastly, Akamai och AWS CloudFront stöder HTTP/3 vid sina edge-noder. Googles egen infrastruktur (Search, YouTube och Gmail) har använt QUIC internt sedan 2013 och erbjuder HTTP/3 offentligt. CDN-distributioner drar nytta av QUIC:s 0-RTT-återupptagning: återkommande besökare etablerar anslutningar snabbare och anslutningsmigrering förbättrar prestandan för mobilanvändare som rör sig mellan accesspunkter under innehållsleveransen.

QUIC:s UDP-baserade design medför särskilda säkerhetsaspekter. Förstärkningsattacker: en angripare kan förfalska en käll-IP-adress och skicka små Initial-paket, vilket får servern att skicka stora Handshake-svar till offret — QUIC begränsar detta genom att begränsa serversvar till tre gånger mängden mottagen data tills adressvalideringen är klar (via RETRY-mekanismen). Anslutningsöversvämning: QUIC-servrar måste begränsa frekvensen av nya anslutningsförsök från samma IP-adress. Attacker mot versionsförhandling förhindras genom att versionen inkluderas i den kryptografiskt skyddade handskakningen. QUIC:s inbyggda kryptering innebär att inspektionsenheter inte kan analysera QUIC-nyttolasten utan att befinna sig på vägen och ha servercertifikatet — vilket förbättrar integriteten jämfört med TCP-trafik som kan inspekteras.

För att driftsätta HTTP/3 krävs: (1) En QUIC-kompatibel server (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed eller stöd på applikationsnivå via biblioteken quic-go, aioquic och ngtcp2). (2) UDP-port 443 öppen i brandväggarna — många företagsbrandväggar blockerar UDP 443, vilket får QUIC att falla tillbaka till TCP/TLS. (3) Att HTTP/3-stöd annonseras via svarshuvudet Alt-Svc: h3=":443"; ma=86400, så att HTTP/2-klienter uppmanas att uppgradera. (4) QUIC-medvetna lastbalanserare eller L4 UDP-genomsläpp. (5) Övervakning av QUIC-specifika mätvärden: händelser för anslutningsmigrering, accepteringsfrekvens för 0-RTT och frekvens för protokollfallback. En gradvis utrullning med återgång till HTTPS är transparent för klienter som inte stöder QUIC.

QUIC integrerar TLS 1.3 på transportlagret över UDP och eliminerar TCP:s head-of-line-blockering genom oberoende återställning efter förlust för varje ström. Connection ID möjliggör migrering vid nätverksbyten utan omförhandling. HTTP/3 mappar HTTP till QUIC-strömmar med QPACK-headerkomprimering. Anslutningsåterupptagning med 0-RTT återanvänder TLS-sessionshemligheter. QUIC har betydligt bättre prestanda än HTTP/2 framför allt vid paketförlust (i mobilnät och överbelastade nätverk). Lastbalansering av QUIC kräver att serverns routning kodas i Connection ID. Driftsättning kräver UDP 443, QUIC-kompatibla servrar och Alt-Svc-headers för att annonsera protokollet.