HTTP/2 im Vergleich zu HTTP/3 Was tatsächlich geändert wurde (und ob Ihre API es beachtet)

Kurze Antwort: Wenn Sie hinter einem CDN sind, wird HTTP/3 wahrscheinlich bereits für Sie verwaltet und es gibt nichts zu konfigurieren. Wenn Sie Ihren eigenen Server betreiben, deckt HTTP/2 den Fall 95% ab und HTTP/3 ist eine lohnende, aber nicht dringende Verbesserung.

Hier ist die längere Version, weil das technische Fundament der Unterschiede tatsächlich interessant ist – und das Wissen hilft Ihnen, bessere Entscheidungen über die Stelle zu treffen, an der die Protokollversion überhaupt relevant ist.

Was HTTP/2 tatsächlich behoben hat

HTTP/1.1 hatte zwei Probleme, die HTTP/2 richtig gelöst hat.

Zu viele TCP-Verbindungen, um eine Seite zu laden. Browsers öffneten 6–8 TCP-Verbindungen pro Ursprung, um Assets parallel abzurufen. Jede Verbindung hat eine Setup-Überhead (TCP-Handshake, TLS-Verhandlung), und dieser Ansatz war bei Skalierung verschwendet. HTTP/2 ersetzt dies durch Multiplexing: eine TCP-Verbindung, mehrere Anfragen/Response-Streams, die parallel laufen. Keine mehr Verbindungskonflikte.

Überflüssige Header bei jeder Anfrage. Bei HTTP/1.1 sendet jede Anfrage ihre vollständigen Header – User-Agent, Accept-Encoding, Authorization, alle davon – selbst wenn nichts von der vorherigen Anfrage geändert wurde. HTTP/2s HPACK-Compressions dedupliziert die Header durch einen gemeinsamen Lookup-Tabellen zwischen Client und Server. Bei einer API, bei der Sie denselben Authorization: Bearer ... Token bei jeder Anfrage senden, wird diese Überhead signifikant reduziert, wenn es um hohe Verkehrsmengen geht.

Server Push war ursprünglich ein dritter Gewinn (voraussichtliche Versendung von Ressourcen, die der Client benötigt, bevor er sie fragt), aber es funktionierte in der Praxis nicht wirklich. Chrome hat 2022 die Unterstützung abgeschaltet. Behandeln Sie es als veraltet und bauen Sie nichts darauf auf.

Das Problem, das HTTP/2 nicht beheben konnte

Hier ist der Teil, der oft übersprungen wird: Multiplexing über TCP hat eine harte Grenze. Wenn ein TCP-Paket während der Übertragung verloren geht, pausiert TCP die gesamte Verbindung, bis das Paket erneut übertragen und bestätigt wird. Alle parallelen HTTP/2-Streams – unabhängig davon, welcher Stream das verlorene Paket tatsächlich gehörte – stehen still und warten. Dies ist TCP-Ebene Head-of-Line (HOL)-Blockierung, und es ist kein Bug in HTTP/2 – es ist, wie TCP funktioniert.

Bei einer zuverlässigen festgelegten Verbindung sind die Paketverlustraten so niedrig, dass dies selten schädlich ist. Bei Mobilfunknetzen, Satellitenverbindungen oder jedem Weg mit signifikanten Paketverlusten jedoch wird der Vorteil der Multiplexierung von HTTP/2 aufgehoben. Sie können 20 Streams über eine Verbindung multiplexen, und ein verlorenes Paket blockiert alle 20. 😬

Dies ist keine behebbare Beschränkung. Es ist strukturell, wenn ein Anforderungs-Multiplexprotokoll auf einem Byte-Stream-Transport gebaut wird, der nicht weiß, was ein „Stream“ ist.

Was HTTP/3 tatsächlich geändert hat

HTTP/3 ändert nicht nur das Rahmenformat oder fügt eine neue Feature-Flag hinzu. Es ersetzt TCP durch QUIC – ein Transportprotokoll, das über UDP läuft.

QUIC behandelt das Multiplexing auf der Transportebene, sodass ein verlorenes Paket nur den Stream, zu dem es gehört, blockiert, nicht alle anderen Streams auf der Verbindung. Das HOL-Blockierungsproblem wird auf der richtigen Ebene der Stack gelöst. Das ist der Kern davon.

Ein paar andere Dinge, die QUIC mitbringt:

• Verbindungsmigration. QUIC identifiziert Verbindungen durch eine Verbindungs-ID, nicht durch eine 4-Tupel aus Quell-IP, Quellport, Ziel-IP, Zielport. Wechseln Sie von Wi-Fi zu Mobilfunk während der Übertragung, und die Verbindung überlebt. Das ist für Mobilapps wichtig; für Server-zu-Server-API-Aufrufe ist es meistens irrelevant.
• 0-RTT-Handshakes. Für Verbindungen zu bekannten Servern kann QUIC die Rundum-TLS-Verhandlung überspringen und Daten sofort senden. Echte Latenzvorteil bei Wiederherstellung. Hinweis: 0-RTT hat eine Replay-Attacke-Abwägung – verwenden Sie es nicht für nicht-idempotente Endpunkte ohne das Verständnis der Abwägungen.
• Pflicht-TLS 1.3. QUIC unterstützt keine unverschlüsselten Verbindungen. Kein HTTP/3 ohne TLS, vollständig ausgeschlossen.

Die Headerkompression wurde auch geändert: HTTP/3 verwendet QPACK anstatt HPACK. Der Unterschied ist technisch – QPACK vermeidet ein Blockierungsproblem in HPACK, wenn Header über Streams komprimiert werden. In der Praxis wird kein Unterschied beobachtet; es ist eine Infrastrukturverbesserung.

Feature-Vergleich

Besonderheit	HTTP/1.1	HTTP/2	HTTP/3
Transportprotokoll	TCP	TCP	QUIC (UDP)
Anfragen-Multiplexing	Nein (mehrere Verbindungen)	Ja	Ja
HOL-Blockierung	Anfragen-Ebene	TCP-Ebene (immer noch vorhanden)	Keiner
Headerkompression	Keiner	HPACK	QPACK
TLS erforderlich	NEIN	Nein (Spezifikation), ja (Browser)	Ja (pflicht)
0-RTT-Handshake	NEIN	NEIN	Ja
Verbindungsmigration	NEIN	NEIN	Ja
Server Push	NEIN	Ja (veraltet)	Nein (entfernt)

Was dies für API-Latenz bedeutet

HTTP/3 hilft besonders in bestimmten Bedingungen. Es verbessert nicht alles universal.

Verlustempfindliche Netzwerke. Mobile Clients, die Ihre API über instabile LTE oder 5G mit suboptimaler Abdeckung aufrufen, sehen messbare Verbesserungen. Datenzentrum-zu-datenzentrum API-Aufrufe über eine zuverlässige private Netzwerk mit praktisch null Paketverlust? Der Unterschied ist vernachlässigbar.

Kalte Verbindungen und Wiederherstellung. Wenn Ihre API-Kunden häufig wiedereinloggen – kurze Serverless-Funktionen, Mobilapp-Starts, ephemere Container – reduziert 0-RTT die Einrichtungskosten. Langwirksame Verbindungen, die für Minuten offen bleiben, erhalten keinen Vorteil daraus.

Anfragenmenge spielt eine Rolle. HTTP/2 und HTTP/3 zeigen sich besonders, wenn ein Client viele parallele Anfragen stellt. Ein Browser, der 80 Assets parallel lädt, sieht große Vorteile durch Multiplexing. Ein REST-API, die 3 sequentielle Anfragen stellt, sieht viel kleinere Vorteile. Je mehr parallele Anfragen Ihr Client stellt, desto mehr zählt die Verbesserung der Transportprotokolle.

Wie CDNs dies behandeln

Cloudflare hat HTTP/3 seit 2019 unterstützt und aktiviert es standardmäßig. AWS CloudFront hat es 2022 eingeführt. Fastly, Akamai, BunnyCDN – alle unterstützen es.

Die Architektur spielt hier eine Rolle: Ihr CDN beendet die Clientverbindung an seiner Grenze. Selbst wenn ein Client über HTTP/3 mit QUIC an Ihr CDN angeschlossen ist, ist der CDN-zu-Quelle-Teil fast sicherlich HTTP/1.1 oder HTTP/2 über TCP. Daher erfordert „HTTP/3 aktivieren“ auf Ihrem CDN keine Änderungen an Ihrem Ursprungsserver.

Wenn Sie bei Cloudflare sind, prüfen Sie Ihre Geschwindigkeit → Optimierung-Einstellungen – HTTP/3 (mit QUIC) ist ein Schalter, der für die meisten Zonen standardmäßig eingeschaltet ist. Andere CDNs variieren. Dies ist die höchste Leistung, die die meisten Teams machen können: keine Änderungen am Ursprung, sofortiger Vorteil für Clients auf Mobilgeräten oder auf hohen Latenzwegen.

Sollten Sie tatsächlich etwas tun?

Hinter einem CDN: Prüfen Sie, ob HTTP/3 aktiviert ist und beenden Sie. Dauert 30 Sekunden.

Ihr eigener nginx: HTTP/3 erfordert nginx 1.25+ (die mainline-Branch – stable ist hinter auf QUIC). Sie benötigen das --with-http_v3_module Kompile-Flag und eine listen 443 quic reuseport Direktive neben Ihrem bestehenden TCP-Listener. Stellen Sie sicher, dass der UDP-Port 443 auf Ihrer Firewall offen ist – einige Netzwerke blockieren ihn. Wertvoll, wenn Sie Endbenutzer auf Mobilgeräten bedienen; nicht wertvoll, wenn Sie nur Server-zu-Server-Verkehr verarbeiten.

Mit Caddy: HTTP/3 ist standardmäßig aktiviert, ohne Konfiguration. Nichts zu tun.

Ein Client, der dritte Parteien-APIs aufruft: Ob Sie HTTP/3 erhalten, hängt von der Server ab, auf die Sie aufrufen, nicht von Ihrem Code. curl unterstützt HTTP/3 ab Version 7.86.0 mit einem kompatiblen Backend (nghttp3 oder quiche). Die meisten HTTP-Clients in Python und Node unterstützen HTTP/3 noch nicht standardmäßig. Go’s Standard net/http unterstützt es nicht; es gibt eine separate quic-go Bibliothek, wenn Sie es benötigen.

Ein praktischer Hinweis: Wenn Sie testen, welche HTTP-Version ein Server tatsächlich verhandelt, oder wenn Sie curl-Befehle mit --http3 Flags erstellen, cURL Befehlsersteller auf iotools.cloud ist nützlich, um den richtigen Befehl ohne das Suchen der genauen Flag-Syntax jedes Mal zu konstruieren.

Das könnte Ihnen auch gefallen