HTTP/3 – Ein Vergleich mit HTTP/2

HTTP ist das unverzichtbare Anwendungsprotokoll im World Wide Web. Die neueste Ausgabe dieses Protokolls wird schon seit geraumer Zeit entwickelt. Im Juni 2022 wurde es als empfohlener Standard eingestuft, was es zu einem geeigneten Zeitpunkt macht, seine Funktionsweise zu evaluieren.

Interessanterweise ist die Unterstützung für HTTP/3 bereits in den NGINX-Binärdateien ab der Version 1.25.0 integriert. Bei Kiwee verwenden wir NGINX nicht nur als Webserver, sondern auch als Reverse Proxy für diverse Projekte, einschließlich Shopware 6-basierenden Online-Shops.

Wie HTTP/3 sich von seinen Vorläufern abhebt

Frühere HTTP-Versionen setzten auf TCP als Transportprotokoll. TCP zeigt allerdings einige Mängel auf, besonders beim Umgang mit Paketverlusten, welche einen kompletten Datenstrom blockieren können (auch bekannt als Head-of-Line-Blocking), bis das verloren gegangene Paket erneut gesendet wird.

HTTP/3 hingegen nutzt QUIC, ein neues Transportprotokoll, das ursprünglich von Google entworfen wurde. QUIC, das auf UDP aufbaut, soll dieses Head-of-Line-Blockierungsproblem lösen, indem es das Scheitern einzelner Datenströme erlaubt, ohne die vollständige Verbindung zu stören.

Verbesserte Funktionen in HTTP/3

Einer der bemerkenswerten Verbesserungen in HTTP/3 ist in Bezug auf die Sicherheit. Im Vergleich zu den vorherigen HTTP-Versionen, in denen die Sicherheitsschicht separat war, bietet QUIC eine integrierte TLS-Unterstützung. Dies ermöglicht eine simultane Durchführung von Verschlüsselung und Datenübertragung, wodurch die Latenzzeit reduziert wird. Aktuell nutzt QUIC die jüngste TLS-Version: 1.3.

Ein weiterer fortschrittlicher Aspekt ist das Multiplexing. Beide, HTTP/2 und HTTP/3, bieten diese Funktion. Mit dieser Funktion können mehrere Anfragen gleichzeitig über eine einzelne Verbindung abgewickelt werden. Es sollte jedoch beachtet werden, dass bei HTTP/2 der Verlust eines Pakets aufgrund der Head-of-Line-Blockierung von TCP immer noch alle Streams beeinflusst. Im Gegensatz dazu nutzt das Stream-Multiplexing von QUIC UDP, wodurch dieses Problem umgangen wird. Dies führt zu einer verbesserten Leistung im Falle eines Paketverlusts.

HTTP/2 - Beispiel für eine anfängliche TCP-Blockierung. Im Falle eines Paketverlusts müssen alle nachfolgenden Pakete den Neusendungsprozess abwarten.

Lösung für HTTP/3 Head-of-Line-Blocking - Dank des QUIC-Protokolls werden Streams auf der Transportschicht unabhängig verwaltet. Das bedeutet, dass bei Paketverlust nur der betroffene Stream blockiert wird, bis das verlorene Paket wieder übertragen wird.

Schneller Verbindungsaufbau mit QUIC - QUIC integriert TLS direkt, wodurch ein Handshake beim Aufbau einer Verbindung möglich ist. Dies steht im Kontrast zu HTTP/2, wo TCP und TLS separat übermittelt werden müssen.

Verbindungsmigration - QUIC offeriert die Unterstützung bei Verbindungsmigrationen, was bedeutet, dass wenn ein Nutzer seine Netzwerkschnittstelle wechselt (beispielsweise von WLAN zu mobilen Daten), QUIC in der Lage ist, die bestehende Verbindung ohne Unterbrechung fortzuführen. Im Gegensatz dazu, bindet TCP Verbindungen an die spezifische IP-Adresse, sodass ein in Netzwerkwechsel oft den Beginn einer neuen Verbindung bedeutet.

Zero Round Trip Time Resumption (0-RTT) - QUIC ermöglicht es dem Client, Daten zu versenden, noch bevor eine offizielle Verbindung hergestellt wurde. Dies beschleunigt somit die erste Anfrage an den Webserver.

HTTP/3 gegen HTTP/2 Benchmark

Die hauptsächlich genutzte Test-Webseite war eine statische CMS-Seite. Eine statische Seite minimiert zusätzliche Latenzen, die entstehen könnten durch die Ausführung einer Applikation, die Herstellung einer Verbindung zu einer Datenbank oder die Nutzung anderer externer Dienste.

Überprüfungswerkzeug

Das HTTP-Testskript beinhaltet Puppeteer - eine Bibliothek für Node.js, die es uns erlaubt, Chrome im Headless-Modus zu betreiben und dabei Zugang zu den Metriken der Entwicklertools zu erhalten, insbesondere jene des Netzwerkbereichs.

Methodik für die Durchführung der Untersuchung

Wir haben die gesamte Downloadzeit der geprüften Webseite erfasst, welche alle verlinkten Elemente wie Schriftarten, Bilder, CSS- und JS-Dateien einbezogen hat, jedoch nicht die durch den JavaScript-Code ausgelösten Anfragen.

Die ausgewählte Webseite wurde in jeweils 50 Durchläufen im erzwungenen HTTP/3-Modus getestet (um zu gewährleisten, dass bereits die erste Anfrage HTTP/3 nutzte) und 50 Durchläufen mit ausgeschalteter QUIC-Unterstützung.

Um maximale Konsistenz in allen Testläufen zu gewährleisten, wurde für jede Iteration ein neuer Container eingesetzt.

Test-Standorte

Die untersuchte Webseite wurde in einem Rechenzentrum im nördlichen Deutschland gehostet. Die Durchführung der Tests erfolgte an folgenden Standorten:

• An drei unterschiedlichen Hetzner Cloud-Rechenzentren (lokalisert in Nürnberg, Deutschland; Helsinki, Finnland und Ashburn, Virginia, USA);

• Mithilfe eines Laptops, der über eine glasfaserbasierte Internetverbindung mit einer Bandbreite von 1 Gbit/s über Wi-Fi angeschlossen ist (Standort: Breslau, Polen);

• Über einen Laptop, der mit dem Internet über einen mobilen 4G/LTE-Hotspot per Wi-Fi verbunden ist (Standort: Breslau, Polen);

• Und schlussendlich mithilfe eines weiteren Laptops, der mittels eines mobilen 4G/LTE-Hotspots über Wi-Fi (Breslau, Polen) verbunden war, wobei gleichzeitig suboptimale Netzwerkbedingungen simuliert wurden. Hierbei wurde eine zusätzliche Latenzzeit von 100 Millisekunden eingeführt, sowie ein Paketverlust von rund 15% erzeugt (unter Zuhilfenahme des Linux-Dienstprogramms "Traffic Control").

Darstellung der Testergebnisse

Die angegebenen Werte sind in Sekunden und werden mittels eines Geigen-Diagramms illustriert. Diese spezielle Darstellung legt die tatsächliche Verteilung der Download-Zeiten offen.

Wenn wir vom 90. Perzentil sprechen, bedeutet dies, dass 10% der Download-Zeiten langsamer ausfielen als der genannte Wert.

Beim 99. Perzentil wiederum waren 1% der Download-Zeiten langsamer als der eingetragene Wert.

Ladezeit der Webseite aus Nürnberg, Deutschland - Hetzner Cloud

Nürnberg, DE	HTTP/3	HTTP/2
Median	0,6350	0,5490
Durchschnitt	0,6472	0,8623
90. Perzentil	0,7550	1,7660
99. Perzentil	0,8750	2,0610
Minimum	0,4820	0,4200
Maximum	1,2630	2,1990

Ladezeit der Webseite aus Helsinki, Finnland - Einsatz der Hetzner Cloud

Helsinki, FI	HTTP/3	HTTP/2
Median	0,6465	0,6950
Durchschnitt	0,6702	0,9317
90. Perzentil	0,8040	1,7960
99. Perzentil	0,9090	2,5000
Minimum	0,5360	0,5550
Maximum	0,9210	2,8420

Ladezeit der Seite aus Virginia, USA - Hetzner Cloud

Viginia, US	HTTP/3	HTTP/2
Median	1,2800	1,6740
Durchschnitt	1,3491	1,7942
90. Perzentil	1,5220	2,1910
99. Perzentil	1,9210	2,9370
Minimum	1,1430	1,2840
Maximum	2,1730	4,8710

Ladezeiten von Seiten in Breslau, Polen - 1Gbps Glasfaseranschluss

PL (Wrocław, Fiber)	HTTP/3	HTTP/2
Median	0,8390	0,8155
Durchschnitt	0,8856	1,0117
90. Perzentil	1,0130	1,3150
99. Perzentil	1,0140	1,3230
Minimum	0,7530	0,7270
Maximum	1,4280	2,9040

Ladezeit von Seiten in Breslau, Polen - mittels LTE auf Mobilgeräten

PL (Wrocław, LTE)	HTTP/3	HTTP/2
Median	1,6020	1,2035
Durchschnitt	1,7172	1,3895
90. Perzentil	1,8740	1,5470
99. Perzentil	2,5690	1,8190
Minimum	1,2350	0,8960
Maximum	2,7230	3,4310

Ladezeit der Webseite aus Breslau, Polen - Mangelhafte mobile Qualität

PL (Wrocław, mobile ~15% Paketverlust)	HTTP/3	HTTP/2
Median	6,0280	8,9400
Durchschnitt	6,6856	12,8554
90. Perzentil	9,3170	27,6380
99. Perzentil	9,3490	28,4410
Minimum	4,0230	5,9210
Maximum	9,7740	36,7130

Im Bereich der interkontinentalen Verbindungen (US-Ostküste-Deutschland) zeichnet sich HTTP/3 zweifellos durch eine um 25% schnellere Download-Geschwindigkeit (Durchschnitt) aus. Darüber hinaus schneidet HTTP/3 auch dann besser ab, wenn Benutzer in instabilen Mobilfunknetzen mit hohen Latenzen und Paketverlusten navigieren, wobei es Download-Geschwindigkeiten erreicht, die um 52% schneller sind (Durchschnitt).

Selbst bei kurzen Entfernungen zwischen Client und Server und stabilen Netzwerkbedingungen weist HTTP/3 einen leichten Vorteil in Bezug auf die durchschnittliche Zeit auf. Es ist jedoch zu beachten, dass die Mediane bei HTTP/2 niedriger sind.

Die durchgeführten Tests zeigen ebenfalls, dass HTTP/3 belastbarer und verlässlicher ist. Betrachten wir das 90. und 99. Perzentil, so sind selbst die langsamsten Download-Zeiten bei HTTP/3 immer noch weit besser als die langsamsten bei HTTP/2 (mit nur einer Ausnahme bei den Tests).

Ein auf GitHub veröffentlichtes Jupyter Notebook, das alle
Testergebnisse zusammenfasst, steht zur
Verfügung.

Wie HTTP/3 für Ihre Webanwendung aktiviert werden kann

Je nach den spezifischen Einschränkungen und Bedürfnissen Ihrer Infrastruktur gibt es verschiedene Lösungsansätze.

Sollten Sie eine Infrastruktur haben, bei der es nicht möglich ist, den vorderen HTTP-Server zu ersetzen oder zu aktualisieren, stellt die einfachste Lösung die Einbindung eines von Drittanbietern bereitgestellten CDN-Dienstes dar, der HTTP/3 unterstützt. Viele der großen Anbieter bieten dies bereits an, darunter Cloudflare, Fastly, AWS Cloudfront und Google Cloud CDN.

Eine Alternative wäre, einen Server, der HTTP/3 unterstützt, als HTTP-Server für Ihre Anwendung oder einen Reverse-Proxy einzusetzen. Bedenken Sie bitte, dass QUIC ohne TLS nicht funktionsfähig ist. Daraus folgt, dass ein gültiges TLS-Zertifikat notwendig ist. Im Folgenden sind Server gelistet, die bereits HTTP/3 unterstützen:

• NGINX
• Caddy
• LiteSpeed
• H2O.

HAProxy Load Balancer bietet momentan nur in der Enterprise-Version HTTP/3 an, jedoch kann HAProxy mit aktiviertem QUIC aus dem Quellcode kompiliert werden.

Zum Zeitpunkt der Veröffentlichung dieses Artikels hat der Apache HTTP Server QUIC noch nicht auf seiner Roadmap. Es gibt jedoch eine bestehende Funktionsanforderung.

Einrichtung von HTTP/3 in NGINX in einem Docker-Container

Die offiziellen NGINX-Images und auch die zum Download bereitgestellten Binärdateien bieten seit Version 1.25.0 integrierte QUIC-Unterstützung. Um HTTP/3 zu aktivieren, führen Sie bitte folgende Schritte durch:

1. Aktivieren Sie TLS 1.3. QUIC kann nur mit der neusten Version 1.3 arbeiten. Hinzufügen von TLSv1.3 in die ssl_protocol Direktive, wie folgt:

   ssl_protocols TLSv1.2 TLSv1.3;

2. Nutzen Sie Port 443 erneut für das QUIC-Protokoll:

   listen 443 quic reuseport;

   Denken Sie daran, dass reuseport nicht mehr als einmal pro Host verwendet werden kann. Wenn also mehrere virtuelle Hosts auf dieselbe IP-Adresse zugreifen, kann nur einer die Klausel reuseport verwenden.

3. Fügen Sie einen Alt-Svc-Header hinzu, um dem Browser mitzuteilen, dass HTTP/3 verfügbar ist. Die allererste Anfrage wird immer HTTP/2 verwenden. Sobald die erste Antwort mit dem Alt-Svc erhalten wird, werden alle nachfolgenden Anfragen bereits HTTP/3 verwenden.

   add_header Alt-Svc 'h3=":443"; ma=86400';

4. NGINX's Implementierung von HTTP/3 übermittelt weder Host- noch Proxy-bezogene Header wie x-forwarded-for, x-forwarded-host, x-forwarded-proto, x-forwarded-port und x-forwarded-prefix. Wenn Ihre Applikation diese benötigt, müssen sie explizit eingestellt werden.

5. Stellen Sie sicher, dass sowohl der TCP- als auch der UDP-Port 443 vom NGINX-Container zugänglich sind. Dies kann mithilfe von Docker wie folgt ausgeführt werden:

   docker run -p 80:80 -p 443:443/tcp -p 443:443/udp nginx

   Alternativ können Sie dies in der Docker-Datei folgendermaßen festlegen:

   ...
   EXPOSE 80 # without explicit protocol name the default is TCP
   EXPOSE 443/tcp
   EXPOSE 443/udp

   In der Datei docker-compose.yml sieht dies so aus:

   ...
   ports:
   - "80:80"
   - "443:443/tcp"
   - "443:443/udp"

6. Überprüfen Sie Ihre Firewall-Einstellungen. Eingehender UDP-Verkehr über Port 443 muss erlaubt sein.

Wie kann man den Browser effizient über die Verfügbarkeit von HTTP/3 in Kenntnis setzen? Im Allgemeinen stellt der Browser die erste Verbindung über HTTP/2 her und erkennt, dass HTTP/3 verfügbar ist, wenn er die Alt-Svc-Antwort-Header-Information mit der passenden Musterübereinstimmung erhält:

Alt-Svc h3=":<port>"; ma=<timeout_seconds>

Es gibt jedoch auch eine Methode, den Browser schon vorab durch einen DNS SVCB/HTTPS-Eintrag darauf aufmerksam zu machen.

beispiel.de 3600 IN HTTPS 1 . alpn="h3,h2"

Diese Funktion ist laut dem Entwicklungsstatus von Chrome eine Unterstützung für Chrome und Safari in der Entwicklung.

Zusammenfassung

Im Vergleich zu dem Quantensprung von HTTP/1.1 zu HTTP/2 hinsichtlich der Leistungssteigerung, bringt HTTP/3 eher evolutionäre Verbesserungen, insbesondere bei hoher Netzwerklatenz und Paketverlusten. Unter solchen Bedingungen weist HTTP/2 ein erhöhtes Risiko für Head-of-Line-Blockierungen auf. Tests haben jedoch gezeigt, dass HTTP/3 sich unter diesen Bedingungen deutlich besser verhält.

Ist HTTP/3 bereit zur Einführung? Ich glaube fest daran, dass es so ist. Große Technologieunternehmen wie Google, Cloudflare und Shopify setzen es bereits in der operativen Produktionsumgebung ein. Zudem bieten die führenden Internetbrowser bereits entsprechende Unterstützung. Insbesondere für mobile Nutzer kann HTTP/3 einen erheblichen Vorteil liefern. Vor allem in ländlichen Gegenden, wo die Mobilfunknetze oft unzuverlässig sind, kann sich diese Technologie als segensreich erweisen, indem sie beispielsweise die Konversionsraten und Gesamtverkäufe für Online-Shops steigert.

Postskript

Ein Tierbild oben zeigt einen Gabelbock. Hier möchte ich die Gelegenheit nutzen, das Bewusstsein zu schärfen: Diese Antilope, das am schnellsten laufende Tier Nordamerikas mit einer Höchstgeschwindigkeit von etwa 95 km/h / 55 mph, ist vom Aussterben bedroht. Erfahren Sie mehr über dieses faszinierende Tier.

• DevOps
• Effizienz
• HTTP
• Test