HTTP/3 & QUIC
HTTP over QUIC (UDP): sneller opzetten, geen HOL-blocking, connection migration
1HTTP/1.1, HTTP/2 en HTTP/3 vergeleken
- HTTP/2
- TLS 1.2+
- TCP
- IP
- HTTP/3
- QUIC (met TLS 1.3 erin)
- UDP
- IP
- HTTP/1.1: elke afbeelding = aparte TCP-connectie; browsers openen ~6 per url
- HTTP/2: multiplexing van parallelle streams over 1 connectie + header-compressie. Probleem: TCP head-of-line blocking
- HTTP/3: zelfde HTTP-semantiek, maar over QUIC (geen afkorting, gewoon een naam; gestart in 2015 als Google QUIC)
2Hoe HTTP/3 HTTP/2 versnelt
SYN, SYN-ACK, ACK (1 RTT).
Resultaat (Google): traagste 1 % van de verbindingen wint ~1 s; 18 % minder bufferen voor YouTube; 75 % van de connecties profiteert van 0-RTT; zoekpagina 3 % sneller.
3TCP head-of-line blocking en connection migration
- TCP ziet 1 bytestroom en weet niets van streams
- Verloren segment: TCP houdt alle later aangekomen data vast tot herverzonden
- Rode stream blokkeert, dus groen en blauw ook
- Streams zijn onafhankelijk binnen 1 verbinding
- Verlies in stream A: alleen A wacht
- Blauw blokkeert, geel niet
Connection migration: TCP identificeert een verbinding met 4-tuple (IP + poort bron/doel). Wissel je van 5G naar WiFi, dan verandert je IP: de TCP-verbinding breekt. QUIC geeft elke verbinding een Connection ID, uniek voor de sessie. Je verandert van netwerk met dezelfde Connection ID, dus de verbinding blijft bestaan (download of videocall wordt niet onderbroken).
4QUIC: UDP, user space en beveiliging
- QUIC = nieuw transportprotocol: betrouwbaar, secure, sneller, bovenop UDP
- UDP zelf = connectionless, geen hersturen, geen flow control. QUIC voegt dat toe: connecties, streams (meerdere logische flows), hersturen, flow control, congestion control
- Draait in user space (niet in de OS-kernel): snel te updaten, maar CPU-intensiever
- Altijd versleuteld: geen clear-text versie, minimaal TLS 1.3. Enkel moderne cipher suites (AES-GCM, ChaCha20-Poly1305), geen RSA-key-exchange/oude rommel
- HTTP/3 URL is dezelfde als HTTP/2, poort 443 (UDP voor QUIC, TCP voor HTTP/2)
50-RTT en replay-aanvallen
0-RTT hergebruikt een vorige sessie (zelfs een dag later) zodat de client meteen data kan sturen zonder wachten op de handshake. Nadeel: replay-aanval. Een aanvaller kan het versleutelde 0-RTT-pakket opnieuw sturen en de server voert het nogmaals uit.
6Ossification: probleem met een nieuw transportprotocol
- Middleboxes/firewalls/NAT: filteren en wijzigen op protocol-nummer of poort; onbekend transport = geblokkeerd of niet vertaald
- Zelfs aanpassen van TCP is moeilijk: middleboxes verwerpen onbekende opties (bv. TCP Fast Open)
- Kernel-updates: TCP zit in het besturingssysteem, uitrol duurt jaren. QUIC zit in user space (apps/browsers updaten snel)
- Oplossing QUIC: bouwen bovenop UDP (gaat overal door) en alles versleutelen, zodat middleboxes het niet kunnen lezen of verknoeien. Ook de upgrade naar QUIC v2 gebeurt binnen de encryptie.
7Spin bit: operators kunnen bijna niets zien
Omdat alles versleuteld is, kunnen netwerkoperators connecties niet analyseren. De spin bit is één bewust zichtbare bit in de header: client en server spiegelen hem om en om (0, dan 1, dan 0, ...) in beide richtingen. Een observer ziet zo dat pakketten bij dezelfde connectie/conversatie horen en kan de RTT (en dus latency/verlies) grof meten, zonder inhoud te zien.
- Operators zien verder bijna niets, tenzij ze een eigen CA hebben en als MITM optreden (gebeurt in China)
- Tegenhanger: Connection ID verbergt de sessie ook bij wisselend IP
8Hoe schakelt een browser over naar QUIC?
Browser maakt gewone HTTPS-verbinding (HTTP/2 over TCP/TLS) op poort 443.
HTTP/2 200 OK
content-type: text/html
alt-svc: h3=":443"; ma=86400Nog niet klaar? Je kan altijd terugkomen.