Jede HTTP-Anfrage, die Ihre API bedient, läuft über eine Transportschicht, über die sich die meisten Entwickler nie Gedanken machen. 25 Jahre lang war TCP die Antwort. Dann wurde Google es leid, auf Verbesserungen bei TCP zu warten, entwickelte das QUIC-Protokoll auf UDP-Basis, und die IETF machte es zum Standard. HTTP/3 ist die Version von HTTP, die dafür entwickelt wurde, darauf zu laufen.
Das klingt nach einer grundlegenden Infrastruktur. Das ist es größtenteils auch. Aber diese Infrastruktur verändert, wie schnell Ihre API Verbindungen aufbaut, wie sie sich in instabilen mobilen Netzwerken verhält und wie parallele Anfragen eine Verbindung teilen. Wenn Sie APIs entwerfen oder betreiben, sollten Sie wissen, was sich geändert hat, was nicht und wie Sie überprüfen können, welche Protokolle Ihre eigenen Endpunkte heute unterstützen.
Eine Sache bleibt bei all dem konstant: Ihre Anfragen, Antworten, Statuscodes und JSON-Payloads sehen auf HTTP/1.1, HTTP/2 und HTTP/3 identisch aus. Tools wie Apidog testen und debuggen auf der API-Schicht, sodass alles, was Sie über das Verhalten eines Endpunkts validieren, gültig bleibt, unabhängig davon, welche Transportversion Ihre Infrastruktur darunter aushandelt. Wenn Sie bereits unseren ausführlichen Artikel über was HTTP/2 ist und wie man HTTP/2 APIs testet gelesen haben, knüpft dieser Artikel dort an, wo jener aufhört.
Was ist das QUIC-Protokoll?
QUIC ist ein Transportprotokoll, das in RFC 9000 standardisiert ist. Es läuft über UDP anstelle von TCP und bildet die von TCP bereitgestellten Funktionen (Zuverlässigkeit, Reihenfolge, Überlastungskontrolle) im Benutzerbereich, pro Stream, mit integrierter Verschlüsselung ab dem ersten Paket, neu ab.
Vier Designentscheidungen definieren es:
Es läuft auf UDP. TCP ist in Betriebssystemkernen und Middleboxes im gesamten Internet implementiert, was seine Weiterentwicklung nahezu unmöglich macht. UDP ist ein dünner Umschlag ohne Liefergarantien, daher baut QUIC seine eigene Zuverlässigkeitsschicht darauf auf und kann Verbesserungen als Bibliotheksupdates anstelle von Betriebssystem-Upgrades liefern.
TLS 1.3 ist integriert, nicht aufgesetzt. Bei TCP absolvieren Sie einen TCP-Handshake und danach einen separaten TLS-Handshake. QUIC fasst diese zusammen. Die kryptografische Einrichtung erfolgt innerhalb des Transport-Handshakes selbst, sodass eine neue sichere Verbindung nach einem einzigen Roundtrip bereit ist. Unverschlüsseltes QUIC gibt es nicht.
Streams sind unabhängig. Eine QUIC-Verbindung transportiert viele Streams, und jeder wird unabhängig voneinander ausgeliefert. Ein verlorenes Paket blockiert nur den Stream, zu dem es gehört. Dies ist die Lösung für das Head-of-Line-Blocking von TCP, auf das wir gleich noch eingehen werden.
Verbindungen überleben Netzwerkänderungen. TCP identifiziert eine Verbindung über IP-Adresse und Port. Ändern Sie eines davon (gehen Sie aus der WLAN-Reichweite, wechseln Sie zu 5G) und die Verbindung bricht ab. QUIC identifiziert Verbindungen stattdessen über eine Verbindungs-ID, sodass ein Client zu einem neuen Netzwerk wechseln und dieselbe logische Verbindung aufrechterhalten kann. Keine Neuverbindung, kein neuer Handshake.
HTTP/3, definiert in RFC 9114, ist die Abbildung von HTTP-Semantik auf QUIC-Streams. Gleiche Methoden, gleiche Header, gleiche Statuscodes. Anderes Übertragungsformat, anderer Transport.
HTTP/3 vs. HTTP/2: Was sich in der Praxis geändert hat
HTTP/2 war ein großer Fortschritt gegenüber HTTP/1.1. Es führte Multiplexing ein, sodass viele Anfragen eine TCP-Verbindung teilen konnten, anstatt in der Warteschlange zu stehen oder sechs parallele Sockets zu öffnen. Aber es behielt TCP als Basis bei, und das schuf ein Problem, das HTTP/2 alleine nicht lösen konnte.
TCP garantiert die geordnete Zustellung eines einzelnen Bytestroms. Wenn ein Paket verloren geht, hält TCP jedes nachfolgende Byte zurück, bis die Neuübertragung eintrifft, selbst Bytes, die zu völlig unabhängigen HTTP/2-Streams gehören. Ein verlorenes Paket friert alle 20 auf der Verbindung gemultiplexten Anfragen ein. Das ist Head-of-Line-Blocking auf Transportebene, und in einem verlustbehafteten Netzwerk kann es HTTP/2 langsamer machen als HTTP/1.1 mit seinen mehreren Verbindungen.
HTTP/3 eliminiert den gemeinsamen Bytestrom. Jede Anfrage wird einem eigenen QUIC-Stream mit eigener Zustellungsreihenfolge zugeordnet. Geht ein Paket mit Stream 5 verloren, fließen die Streams 6 bis 24 weiter. Multiplexing funktioniert endlich so, wie es die HTTP/2-Diagramme immer behauptet haben.
Auch die Handshake-Berechnung hat sich geändert:
| HTTP/2 über TCP+TLS 1.3 | HTTP/3 über QUIC | |
|---|---|---|
| Einrichtung neuer Verbindungen | 2 Roundtrips (TCP + TLS) | 1 Roundtrip |
| Wiederaufgenommene Verbindung | 1 Roundtrip | 0 Roundtrips (0-RTT) |
| Auswirkungen verlorener Pakete | Blockiert alle Streams | Blockiert einen Stream |
| Netzwerkwechsel (WLAN zu 5G) | Verbindung bricht ab, vollständige Neuverbindung | Verbindung migriert, bleibt bestehen |
| Verschlüsselung | Theoretisch optional, separate Schicht | Obligatorisch, integriertes TLS 1.3 |
Die Zeile 0-RTT verdient einen Hinweis. Wenn ein Client sich erneut mit einem Server verbindet, den er zuvor gesehen hat, erlaubt QUIC ihm, Anwendungsdaten bereits im ersten Paket zu senden, bevor der Handshake abgeschlossen ist. Großartig für die Latenz. Aber 0-RTT-Daten können von einem Angreifer abgefangen und wiedergegeben werden, daher dürfen Server im 0-RTT nur idempotente Anfragen akzeptieren. Ein wiederholter GET-Request ist harmlos. Ein wiederholter POST-Request, der eine Kreditkarte belastet, ist es nicht. Wenn Sie 0-RTT an Ihrem Edge aktivieren, stellen Sie sicher, dass nicht-idempotente API-Aufrufe ausgeschlossen sind, oder bestätigen Sie, dass Ihr CDN dies für Sie übernimmt.
Was HTTP/3 für Ihre APIs bedeutet
Protokoll-Upgrades sind nur dann relevant, wenn sie etwas messbares ändern. Hier erfahren Sie, wo HTTP/3 den API-Verkehr beeinflusst und wo nicht.
Verbindungsaufbau wird günstiger
Ein typischer mobiler Client in einer Verbindung mit 60 ms RTT verbringt etwa 120 ms mit der TCP+TLS-Einrichtung, bevor die erste API-Anfrage das Gerät überhaupt verlässt. HTTP/3 reduziert dies auf etwa 60 ms und bei Wiederaufnahme nahezu auf null. Für eine API, die von einer mobilen App aufgerufen wird und häufig neue Verbindungen öffnet (Kaltstarts, Hintergrundaktivierungen, kurzlebige Sitzungen), wirkt sich die Ersparnis bei jeder dieser ersten Anfragen aus. Für eine Server-zu-Server-Integration mit einem warmen Verbindungspool wird der Handshake so weit amortisiert, dass er irrelevant wird, und Sie werden nichts bemerken.
Mobile Clients verlieren keine Verbindungen mehr
Die Verbindungsmigration ist das verborgene Highlight für API-Teams. Ein Benutzer startet eine Anfrage im Büro-WLAN, geht zum Aufzug, und das Telefon wechselt ins Mobilfunknetz. Über TCP schlägt diese laufende Anfrage fehl und Ihre clientseitige Wiederholungslogik (Sie haben doch eine, oder?) setzt mit einer vollständigen Neuverbindung ein. Über QUIC folgt die Verbindung dem Gerät in das neue Netzwerk. Weniger Timeout-Fehler in Ihren Client-Logs, weniger halb abgeschlossene Schreibvorgänge, über die man nachdenken muss.
Multiplexing ohne Fehlermodus
Für REST-APIs ist die HOL-Blocking-Behebung am wichtigsten, wenn ein Client viele Anfragen parallel abfeuert: ein Dashboard, das 15 Widgets aktualisiert, eine Synchronisations-Engine, die eine Reihe von Updates pusht. In einem sauberen Netzwerk leisten HTTP/2 und HTTP/3 ungefähr das Gleiche. Fügen Sie 1-2 % Paketverlust hinzu (überfülltes Konferenz-WLAN, Mobilfunk in der U-Bahn), und HTTP/3 hält parallele Anfragen unabhängig, während HTTP/2 sie synchron blockiert.
gRPC bleibt vorerst größtenteils bei HTTP/2
gRPC ist designbedingt an HTTP/2 gebunden; sein Wire-Vertrag hängt von HTTP/2-Framing und Trailern ab. Das gRPC-Ökosystem hat noch keine HTTP/3-Zuordnung standardisiert, und die gängigen Implementierungen (Go, Java, Python, Node) liefern sie nicht aus. Der Kestrel-Server von .NET kann gRPC über HTTP/3 als experimentelle Funktion bereitstellen, aber betrachten Sie das als Ausnahme. Wenn Ihre Architektur auf gRPC und HTTP/2 für die interne API-Leistung setzt, ist eine HTTP/3-Migration nichts, was Sie dieses Jahr planen müssen.
Streaming- und Echtzeit-Verkehr
Server-Sent Events funktionieren über HTTP/3 unverändert, da SSE eine gewöhnliche, langlebige HTTP-Antwort ist. WebSockets sind komplizierter: Das WebSocket-Upgrade wurde für TCP konzipiert, und sein HTTP/3-Äquivalent (RFC 9220, plus die aufkommende WebTransport API) hat nur lückenhafte Unterstützung. Wenn Sie WebSockets gegen einfaches HTTP für eine Echtzeitfunktion abwägen, sollte die Verfügbarkeit von HTTP/3 die Entscheidung noch nicht beeinflussen.
Der ehrliche Teil: Wann HTTP/3 nicht hilft
Die meisten API-Latenzprobleme haben nichts mit dem Transportprotokoll zu tun. Wenn Ihr Endpunkt 400 ms aufgrund einer unindexierten Datenbankabfrage benötigt, liefert HTTP/3 diese langsame Antwort 60 ms früher. Caching, Payload-Design, N+1-Abfragen und Verbindungswiederverwendung dominieren die reale API-Performance, und Sie sollten diese Optimierungen ausschöpfen, bevor Sie über den Transport nachdenken. Ein strukturierter API-Performance-Testdurchlauf wird in der Regel zehnmal größere Verbesserungen aufzeigen als ein Protokoll-Upgrade.
HTTP/3 glänzt unter bestimmten Bedingungen:
- Verbindungen mit hoher Latenz, bei denen das Einsparen von Roundtrips einen festen prozentualen Gewinn darstellt
- Verlustbehaftete Netzwerke, bei denen die HOL-Blocking-Eliminierung sich summiert
- Mobile Clients, die mitten in der Sitzung das Netzwerk wechseln
- Viele kurze statt wenige lange Verbindungen
Für eine typische JSON-API, die von Servern in derselben Region über zuverlässige Netzwerke genutzt wird, ist der Unterschied in Benchmarks messbar, aber für Benutzer unsichtbar. Zwei weitere praktische Hinweise: UDP-Port 443 ist in einigen Unternehmensnetzwerken blockiert (Clients fallen automatisch auf HTTP/2 zurück, sodass nichts kaputtgeht), und QUICs User-Space-Kryptographie kostet derzeit mehr Server-CPU pro Verbindung als optimiertes Kernel-TCP.
Aktueller Support: Wer spricht heute HTTP/3
Die Akzeptanz ist weiter fortgeschritten, als die meisten Backend-Entwickler annehmen:
- Browser: Chrome, Edge, Firefox und Safari liefern alle HTTP/3 standardmäßig aktiviert aus.
- CDNs und Edges: Cloudflare, Fastly, Akamai und CloudFront unterstützen es; bei Cloudflare ist es eine Umschaltfunktion. Für die meisten Teams ist dies der praktische Weg: HTTP/3 am Edge beenden, HTTP/1.1 oder HTTP/2 vom Edge zum Ursprung beibehalten.
- Server: Nginx hat experimentelle HTTP/3-Unterstützung in Version 1.25 mit
listen 443 quic;hinzugefügt. Caddy aktiviert es standardmäßig. LiteSpeed und HAProxy unterstützen es. Apache httpd nicht. - Runtimes: Node.js hat keine stabile integrierte HTTP/3-Serverunterstützung, was ein weiterer Grund ist, warum Edge-Terminierung die übliche Bereitstellung ist.
- curl: unterstützt es mit dem Flag
--http3, wenn es gegen einen HTTP/3-fähigen TLS-Stack gebaut wurde; siehe die curl HTTP/3-Dokumentation, welche Builds es enthalten.
Wie Sie überprüfen, ob Ihre API HTTP/3 bereitstellt
Die Erkennung erfolgt über den Alt-Svc-Antwortheader. Ein Server, der HTTP/3 bewirbt, antwortet auf Ihre erste (HTTP/2) Anfrage mit etwas Ähnlichem wie:
alt-svc: h3=":443"; ma=86400
Das teilt dem Client mit: Dieser Dienst ist für die nächsten 24 Stunden über HTTP/3 auf UDP-Port 443 verfügbar. Überprüfen Sie dies mit curl:
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400
Um die Anfrage direkt über HTTP/3 zu stellen (erfordert einen HTTP/3-fähigen curl-Build):
curl --http3 -I https://cloudflare-quic.com
# HTTP/3 200
Die Statuszeile meldet HTTP/3 anstelle von HTTP/2. Öffnen Sie in den Chrome DevTools den Reiter „Netzwerk“, klicken Sie mit der rechten Maustaste auf die Spaltenüberschrift, aktivieren Sie die Spalte „Protokoll“ und suchen Sie nach h3 neben Ihren API-Aufrufen. Fügen Sie in der Produktion das ausgehandelte Protokoll Ihren Zugriffs-Logs hinzu; die Aufteilung zwischen h2- und h3-Verkehr zeigt Ihnen, wie viele Ihrer Clients den Vorteil nutzen.
Während Sie den Transport überprüfen, überprüfen Sie auch das Verhalten. Richten Sie Apidog auf dieselben Endpunkte und überprüfen Sie Statuscodes, Antwortschemata und Latenzbudgets. Gewinne auf Transportebene sind wertlos, wenn der zugrunde liegende API-Vertrag defekt ist, und Vertragskontrollen sind genau die Ebene, auf der eine Protokolländerung Sie nicht retten kann. Laden Sie Apidog kostenlos herunter und führen Sie dieselbe Testsuite aus, bevor und nachdem Sie HTTP/3 an Ihrem Edge aktivieren; der Unterschied in den Antwortzeiten in mobilen Netzwerken ist Ihre reale Antwort, nicht die Benchmark-Schlagzeilen.
FAQ
Ist HTTP/3 schneller als HTTP/2?
In sauberen Netzwerken mit geringer Latenz: kaum. In verlustbehafteten oder latenzreichen Netzwerken: ja, oft merklich, da HTTP/3 einen Handshake-Roundtrip einspart und ein einzelnes verlorenes Paket nicht mehr jede gemultiplexte Anfrage blockiert. Messen Sie mit Ihrem eigenen Verkehrsprofil, bevor Sie den Gewinn beanspruchen. Und denken Sie daran, HTTP/2 bleibt exzellent; wenn Sie dort Verbindungsfehler feststellen, handelt es sich meist um Probleme auf TLS-Ebene, wie das SSLV3_ALERT_HANDSHAKE_FAILURE-Problem, und nicht um Protokollgrenzen.
Verwendet HTTP/3 TCP?
Nein. HTTP/3 läuft auf QUIC, das auf UDP läuft, typischerweise Port 443. QUIC implementiert die Zuverlässigkeit, Reihenfolge und Überlastungskontrolle, die TCP bereitstellte, aber pro Stream und im Benutzerbereich, neu. Wenn UDP 443 in einem Netzwerk blockiert ist, fallen Clients automatisch auf HTTP/2 über TCP zurück.
Muss ich meinen API-Code für HTTP/3 ändern?
Fast nie. Die HTTP-Semantik bleibt unverändert: gleiche Methoden, Header, Statuscodes und Bodies. Die Arbeit liegt in der Infrastruktur (Aktivierung bei Ihrem CDN, Load Balancer oder Server) plus einer Designüberprüfung: Stellen Sie sicher, dass 0-RTT-Frühdaten auf idempotente Anfragen beschränkt sind.
Kann ich gRPC über HTTP/3 verwenden?
Vorerst größtenteils nein. Das Wire-Format von gRPC ist an HTTP/2 gebunden, und gängige gRPC-Bibliotheken liefern keine HTTP/3-Transporte aus. .NET bietet experimentelle Unterstützung. Belassen Sie gRPC-Dienste bei HTTP/2 und übernehmen Sie HTTP/3 dort, wo es sich zuerst auszahlt: bei öffentlichen, Browser- und Mobilgeräten zugewandten REST-Endpunkten.