HTTP/3

Als Webentwickler: Du musst meist nichts am Code ändern. Dein Load Balancer (Cloudflare, AWS ALB) oder Webserver (Caddy) macht das Upgrade. Der Server sendet einen Header Alt-Svc: h3=":443" an den Browser. "Hey, ich kann auch HTTP/3!". Beim nächsten Request nimmt der Browser den Turbo.

1. QPACK

HTTP/2 nutzte HPACK, um Header zu komprimieren. HPACK verlässt sich darauf, dass Pakete in der richtigen Reihenfolge ankommen (TCP Garantie). Da QUIC Pakete durcheinanderwürfeln darf (Out-of-Order), würde HPACK kaputtgehen. QPACK ist die neue Kompression, die robust gegen Out-of-Order Delivery ist.

2. Priorisierung

Der Browser sagt dem Server: "Lade das CSS vor dem Bild, und das Bild vor dem Tracking-Skript." In HTTP/2 war das kompliziert und oft kaputt. HTTP/3 macht das einfacher und flexibler direkt im Protocol Stream.

1. Connection Migration (Zero-RTT)

Das gravierendste Limit von TCP in einer mobilen Welt ist die IP-Starrheit und TLS-Handshakes. Fährst du im ICE und dein Handy wechselt vom LTE-Mobilfunk (IP $\alpha$) ins WLAN des Zuges (IP $\beta$), zerschmeißt es jede TCP Handshake-Sequence. Der Browser baut HTTP/2 Sessions schmerzhaft neu auf (3-Round-Trips Setup-Time = hunderte Millisekunden Freeze). HTTP/3 auf QUIC abstrahiert Sockets durch eine 64-Bit Connection ID im Payload, abgekoppelt von den 4-Tupel IP/Ports der NICs. Beim WLAN-Wechsel feuert das Handy QUIC sofort asymetrisch mit gleicher ID weiter. Das Backend mappt es um. Durch 0-RTT greift QUIC auf bekannte elliptische Kurven-Hashes des Vortages zurück und feuert die HTTP/3 HTTPS Payload direkt im allerersten UDP Ping mit ab. Das Web fühlt sich für Edge-Netze lag-frei an (Connection Migration).

2. Congestion Control in Userspace (BBR)

Normales Internet-Traffic shaping passiert stumpf in den Eingeweiden des Linux-OS. Der Kernel drosselt TCP, wenn Packet-Dropping droht (z.B. CUBIC Algo). Für Applikationen dauert es Ewigkeiten im Stack-Schatten neue Algos zu flushen. Da UDP für den TCP/IP-Stack ein purer, primitiver Datagram-Schrot ist, hebt QUIC die Congestion Control ins App-Level (Userspace). Der Browser oder Google's Server nutzen im C++ Flow Code neueste ML-gedopte Limits wie TCP-BBR, das Latenz und RTT-Bandbreiten misst, anstatt passiv auf warten zu verfallen. Dies garantiert radikal höhere Adaptions-Geschwindigkeiten für Ultra-HD Video-Streaming-Buffer, und Entwickler patchen Netzlogiken nun in Tagen über Browserupdates, ohne den Welt-OS Kernel upzugraden.

3. Amplification Angriffsvektoren (UDP Security)

Die Kehrseite der UDP-Münze. Eine HTTP/3 UDP Handshake Policy verlangt massiven Security Audit. DDoS Hacker fälschen ihre Absender-IP in der UDP Header Checksum (Spoofing) zu der ihres Opfers. Sie senden ein popliges 10 Byte Client Hello an einen HTTP/3 Server. Der Server, ohne die Leitung validiert zu haben, schluckt es, und bläst das Server Certificate/Key Exchange-Reply (oft 4000 Bytes) direkt ungefiltert an das wehrlose Spoofed-Opfer runter. Das nennt sich UDP-Amplification-Attacks (Faktor X400). HTTP/3 bekämpft dies rigoros: Die TLS Specs forcieren in QUIC die Regel, dass ein Server niemals mehr Bytes generieren darf, als $\text{Size}(Req) \times 3$, bis er kryptographische Bestätigung hat, dass der Absender keine Phantom-IP ist. Padding im Client-Hello ist zwingend.