QUIC

Das Internet lief 40 Jahre lang auf TCP. TCP ist zuverlässig, aber langsam beim Start ("Handshake") und hat Probleme bei schlechtem Netz (Head-of-Line Blocking). Google hat gesagt: "Wir bauen was Besseres." QUIC basiert auf UDP (dem "unzuverlässigen" Bruder von TCP), baut aber Zuverlässigkeit, Sicherheit (TLS 1.3) und Flow Control selbst neu ein. Der Clou: Es ist viel schneller. Wenn du mit dem Handy von WLAN zu LTE wechselst, bricht eine TCP-Verbindung ab. QUIC überlebt den Wechsel reibungslos ("Connection Migration"). Es ist die Basis für das neue HTTP/3.

Merksatz: Ein modernes, auf UDP basierendes Transportprotokoll, das die Zuverlässigkeit von TCP mit der Geschwindigkeit und Sicherheit von TLS 1.3 kombiniert und Probleme wie Head-of-Line Blocking löst.

Browser: Chrome, Firefox, Safari nutzen es automatisch für Google, YouTube, Facebook. (Schau mal in die DevTools -> Protocol: "h3").
Server: Caddy, Nginx (neuere Versionen), Cloudflare unterstützen es out-of-the-box.
Firewalls: Manche Firmen-Firewalls blockieren UDP auf Port 443. Dann fällt der Browser auf TCP (HTTP/2) zurück.

1. Head-of-Line Blocking (HOL)

Bei TCP/HTTP2: Du lädst 3 Bilder (Stream A, B, C) über eine Verbindung. Ein Paket von Bild A geht verloren. TCP stoppt alles (auch B und C), bis A repariert ist. QUIC: Bild A muss warten. Bild B und C laden munter weiter. Die Streams sind unabhängig. Das ist der massive Vorteil bei schlechtem Netz (Packet Loss).

2. User Space Implementation

TCP ist im Kernel. Ein Update dauert Jahre (bis alle ihr OS updaten). QUIC läuft im User Space (in der App/Browser). Google kann Chrome updaten und BAM – alle haben das neue Protokoll. Viel schnellere Innovation.

1. 0-RTT Security & Replay Attacks

QUIC erlaubt das Senden von Daten im allerersten Paket (0-Round Trip Time), falls man den Server schon kennt. Das macht Websiten-Aufrufe instantan. Die Gefahr: Ein Angreifer kann dieses erste Paket abfangen und später erneut senden (Replay Attack), z.B. um eine Bestellung doppelt auszulösen. In der Produktion müssen Server daher "Idempotenz" sicherstellen: Das 0-RTT-Paket darf nur Operationen enthalten, die beim zweiten Mal nichts Schlimmes tun (z.B. GET-Requests). POST-Requests werden oft erst im 1nd-RTT erlaubt.

2. Congestion Control: BBR in QUIC

TCP nutzt meist "Loss-Based" Algorithmen (CUBIC): "Sende schneller, bis ein Paket verloren geht, dann bremse hart." QUIC nutzt oft BBR (Bottleneck Bandwidth and Round-trip propagation time - von Google). BBR schaut auf die Latenz, nicht auf den Verlust. Es versucht, die Leitung genau so voll zu machen, dass die Warteschlangen im Router nicht überlaufen. Dank der Implementierung im User Space können Firmen wie Cloudflare ihre Congestion-Algorithmen wöchentlich updaten, ohne auf Kernel-Updates zu warten. Das führt zu 20-30% besserem Durchsatz bei Video-Streaming.

3. Packet Header Protection & Privacy

Im Gegensatz zu TCP sind bei QUIC fast alle Header verschlüsselt. Selbst die Sequence Numbers sind für einen Lauscher im Netz unsichtbar. Nur ein winziges "Spin Bit" ist oft sichtbar, damit Router die Latenz messen können. Das hat weitreichende Folgen für die Netzwerkanalyse (Deep Packet Inspection): ISPs können nicht mehr einfach sehen, welcher Stream zu welcher App gehört. Das erhöht die Privacy massiv, macht aber das Debugging für Netzwerk-Admins (Wireshark-Helden) deutlich schwerer, da man ohne den Session-Schlüssel gar nichts mehr sieht.