HTTP/3 ist schnell

HTTP/3 ist da, und es ist eine große Sache für die Webleistung. Sehen Sie, wie viel schneller es Websites macht!

Warte, warte, warte, was ist mit HTTP/2 passiert? War das nicht noch vor wenigen Jahren der letzte Schrei? Es war sicher, aber es gab einige Probleme. Um sie anzusprechen, gibt es eine neue Version des ehrwürdigen Protokolls, das sich seinen Weg durch den Standards-Track bahnt.

Ok, aber macht HTTP/3 die Dinge tatsächlich schneller? Das tut es auf jeden Fall, und wir haben die Benchmarks, um es zu beweisen.

Eine schnelle Vorschau

Bevor wir zu tief in die Details gehen, werfen wir einen kurzen Blick auf die Benchmark-Ergebnisse. In den folgenden Diagrammen wurde derselbe Browser verwendet, um dieselbe Site über dasselbe Netzwerk anzufordern, wobei nur das verwendete HTTP-Protokoll variiert wurde. Jede Seite wurde 20 mal aufgerufen und die Antwortzeit über die Performance API gemessen. (Mehr Details zur Benchmark-Methodik später)

Sie können die Leistungsverbesserung deutlich sehen, wenn jede neue Version des HTTP-Protokolls verwendet wird:

Vergleich der drei Versionen des HTTP-Protokolls beim Laden von Seiten aus NY

Und die Änderungen werden noch ausgeprägter, wenn Ressourcen über größere geografische Entfernungen und weniger zuverlässige Netzwerke angefordert werden.

Aber bevor wir uns vollständig mit allen Einzelheiten des HTTP/3-Benchmarks befassen können, ist ein wenig Kontext erforderlich.

Eine kurze Geschichte von HTTP

Das erste offizielle Version von HTTP (Hypertext Transfer Protocol 1.0) wurde 1996 fertiggestellt. Es gab einige praktische Probleme und Teile des Standards, die aktualisiert werden mussten HTTP/1.1 wurde ein Jahr später im Jahr 1997 veröffentlicht. Laut den Autoren:

Allerdings berücksichtigt HTTP/1.0 die Auswirkungen von hierarchischen Proxys, Caching, die Notwendigkeit von dauerhaften Verbindungen und virtuellen Hosts nicht ausreichend. Darüber hinaus hat die Verbreitung unvollständig implementierter Anwendungen, die sich selbst „HTTP/1.0“ nennen, eine Änderung der Protokollversion erforderlich gemacht, damit zwei kommunizierende Anwendungen die wahren Fähigkeiten der anderen bestimmen können.

Es würde weitere 18 Jahre dauern, bis eine neue Version von HTTP veröffentlicht wurde. 2015 und mit viel Tamtam RFC-7540 würde HTTP/2 als nächste Hauptversion des Protokolls standardisieren.

Eine Datei nach der anderen

Wenn eine Webseite 10 Javascript-Dateien erfordert, muss der Webbrowser diese 10 Dateien abrufen, bevor die Seite vollständig geladen werden kann. Im HTTP/1.1-Land kann der Webbrowser jeweils nur eine einzelne Datei über eine TCP-Verbindung mit dem Server herunterladen. Das bedeutet, dass die Dateien nacheinander heruntergeladen werden und jede Verzögerung in einer Datei alles andere dahinter blockieren würde. Das nennt man Head-of-Line-Blockierung und es ist nicht gut für die leistung.

Um dies zu umgehen, können Browser mehrere TCP-Verbindungen zum Server öffnen, um den Datenabruf zu parallelisieren. Aber dieser Ansatz ist ressourcenintensiv. Jede neue TCP-Verbindung erfordert Client- und Server-Ressourcen, und wenn Sie TLS hinzufügen, finden auch zahlreiche SSL-Aushandlungen statt. Ein besserer Weg musste her.

Multiplexing mit HTTP/2

Das große Verkaufsargument von HTTP/2 war Multiplexing. Es behoben Anwendungsebene Head-of-Line-Blockierungsprobleme durch Umschalten auf ein binäres Over-the-Wire-Format, das Multiplex-Dateidownloads ermöglichte. Das heißt, ein Client könnte alle 10 Dateien auf einmal anfordern und sie alle parallel über eine einzige TCP-Verbindung herunterladen.

Leider leidet HTTP/2 immer noch unter einem Head-of-Line-Blocking-Problem, nur eine Ebene tiefer. TCP selbst wird zum schwachen Glied in der Kette. Jeder Datenstrom, der ein Paket verliert, muss warten, bis dieses Paket verloren geht erneut übertragen, um fortzufahren.

Da jedoch die parallele Natur des Multiplexing von HTTP/2 für die Loss Recovery-Mechanismen von TCP nicht sichtbar ist, führt ein verlorenes oder neu geordnetes Paket dazu, dass alle aktiven Transaktionen blockiert werden, unabhängig davon, ob diese Transaktion direkt von dem verlorenen Paket betroffen war.

Tatsächlich schneidet HTTP/1.1 in Umgebungen mit hohem Paketverlust besser ab, da der Browser mehrere parallele TCP-Verbindungen öffnet!

Echtes Multiplexing mit HTTP/3 und QUIC

Geben Sie HTTP/3 ein. Der Hauptunterschied zwischen HTTP/2 und HTTP/3 besteht darin, welches Transportprotokoll sie verwenden. Anstelle von TCP verwendet HTTP/3 ein neues Protokoll namens WER. QUIC ist ein Allzweck-Transportprotokoll, das die Head-of-Line-Blocking-Probleme von HTTP/2 mit TCP beheben soll. Es ermöglicht Ihnen, eine zu erstellen Reihe von zustandsbehafteten Streams (ähnlich TCP) über UDP.

Ich habe einen UDP-Witz ... aber Sie bekommen ihn vielleicht nicht

Das QUIC-Transportprotokoll umfasst Stream-Multiplexing und Per-Stream-Flusskontrolle, ähnlich wie sie von der HTTP/2-Framing-Schicht bereitgestellt wird. Durch die Bereitstellung von Zuverlässigkeit auf Stream-Ebene und Überlastungskontrolle über die gesamte Verbindung, QUIC hat die Fähigkeit, die Leistung von HTTP im Vergleich zu einer TCP-Zuordnung zu verbessern

Und verbessern Sie die Leistung von HTTP! Springen Sie zu den Ergebnissen, wenn es Ihnen egal ist, wie der Test durchgeführt wurde

HTTP/3-Benchmarking

Um zu sehen, welche Art von Leistungsunterschied HTTP/3 ausmacht, war ein Benchmarking-Testaufbau erforderlich.

Der HTML-Code

Um der tatsächlichen Nutzung näher zu kommen, bestand der Testaufbau aus drei Szenarien – einer kleinen Website, einer inhaltsintensiven Website (viele Bilder und etwas JS) und einer Single-Page-Anwendung (viel JS). Ich habe mir mehrere reale Websites angesehen und die Anzahl der Bilder und JS-Dateien für jede gemittelt und dann einige Demo-Websites codiert, die diesen Ressourcenzahlen (und -größen) entsprachen.

  • Kleine Seite

    • 10 JS-Dateien von 2 KB bis 100 KB
    • 10 Bilder von 1kb bis 50kb
    • Gesamtnutzlastgröße 600 KB insgesamt 20 blockierende Ressourcen
  • Inhaltsseite

    • 50 JS-Dateien von 2 KB bis 1 MB
    • 55 Bilder mit einer Größe von 1 KB bis 1 MB.
    • Gesamtnutzlastgröße 10 MB 105 Ressourcen insgesamt (sehen Sie sich irgendwann cnn.com in den Entwicklungstools an und Sie werden sehen, warum das so groß ist)
  • Single-Page-Anwendung

    • 85 JS-Dateien von 2 KB bis 1 MB
    • 30 Bilder mit einer Größe von 1kb bis 50kb.
    • Gesamtnutzlastgröße 15 MB 115 Ressourcen insgesamt (sehen Sie sich JIRA irgendwann in den Entwicklungstools an)

Der Kellner

Caddie wurde verwendet, um alle Assets und HTML bereitzustellen.

  • Alle Antworten wurden mit serviert Cache-Control: "no-store" um sicherzustellen, dass der Browser jedes Mal neu heruntergeladen wird.
  • TLS 1.2 wurde für HTTP/1.1 und HTTP/2 verwendet
  • TLS 1.3 wurde für HTTP/3 verwendet.
  • 0-RTT wurde für alle HTTP/3-Verbindungen aktiviert

Die Standorte

Die Tests wurden von meinem Computer in Minnesota aus in drei separaten Rechenzentren durchgeführt, die von Digital Ocean gehostet werden:

  • New York, USA
  • London, England
  • Bangalore, Indien

Der Kunde

Ich habe den Browser so automatisiert, dass er dieselbe Seite 20 Mal hintereinander anfordert und 3 Sekunden nach dem Laden der Seite wartet, um mit der nächsten Anfrage zu beginnen. Die Internetverbindung ist mit 200 Mbit/s bewertet. Zum Zeitpunkt der Datenerfassung liefen keine anderen Anwendungen auf dem Computer.

Wie schnell ist HTTP/3 also?

New York, USA

Hier sind die Antwortzeiten von HTTP/2 im Vergleich zu HTTP/3 beim Anfordern der drei verschiedenen Sites vom Rechenzentrum in New York:

Vergleich der HTTP/2- und HTTP/3-Protokollversionen beim Laden von Seiten aus NY

HTTP/3 ist:

  • 200ms schneller für die kleine Site
  • 325ms schneller für die Content-Site
  • 300ms schneller für die Single Page Application

Die Entfernung von Minnesota nach New York beträgt 1.000 Meilen, was für Netzwerkstandards ziemlich klein ist. Es ist bezeichnend, dass HTTP/3 selbst bei einer relativ kurzen Entfernung die Leistung so stark verbessern konnte.

London, England

Ich habe auch den HTTP/1.1-Benchmark-Lauf für London in die Ergebnisse aufgenommen. Um zu zeigen, wie viel schneller HTTP/2 und HTTP/3 sind, habe ich die Diagramme im gleichen Maßstab gehalten. Sie können sehen, dass die Timings für die Content-Site so langsam sind, dass sie nicht einmal vollständig in das Diagramm passen!

Vergleich der drei Versionen des HTTP-Protokolls beim Laden von Seiten aus London

Wie Sie sehen können, ist die Geschwindigkeitssteigerung noch ausgeprägter, wenn größere Entfernungen über das Netzwerk im Spiel sind. HTTP/3 ist:

  • 600ms schneller für die kleine Site ( 3x die Beschleunigung im Vergleich zu New York)
  • 1200ms schneller für die Inhaltsseite (über 3,5x die Beschleunigung im Vergleich zu New York)
  • 1000ms schneller für die Single Page Application (over 3x die Beschleunigung im Vergleich zu New York)

Bangalore, Indien

Die Leistungssteigerung mit HTTP/3 ist beim Laden von Seiten vom Server in Indien extrem ausgeprägt. Ich habe nicht einmal einen HTTP/1.1-Test durchgeführt, weil er so langsam war. Hier sind die Ergebnisse von HTTP/2 vs. HTTP/3:

Vergleich der drei Versionen des HTTP-Protokolls beim Laden von Seiten aus Indien

HTTP/3 setzt sich weiterhin durch, wenn größere Regionen und mehr Netzwerk-Hops beteiligt sind. Was vielleicht noch auffälliger ist, ist, wie eng gruppiert die Antwortzeiten für HTTP/3 sind. QUIC hat einen großen Einfluss, wenn Pakete Tausende von Kilometern zurücklegen.

In jedem Fall war HTTP/3 schneller als sein Vorgänger!

Warum ist HTTP/3 so viel schneller?

Echtes Multiplexing

Die wahre Multiplex-Natur von HTTP/3 bedeutet, dass nirgendwo auf dem Stack eine Head-of-Line-Blockierung stattfindet. Beim Anfordern von Ressourcen von weiter entfernt, geografisch, besteht eine viel höhere Wahrscheinlichkeit von Paketverlusten und die Notwendigkeit, dass TCP diese Pakete erneut überträgt.

0-RTT ist ein Game Changer

Zusätzlich wird HTTP/3 unterstützt O-RTT QUIC-Verbindungen, wodurch die Anzahl der Roundtrips verringert wird, die zum Herstellen einer sicheren TLS-Verbindung mit dem Server erforderlich sind.

Die 0-RTT-Funktion in QUIC ermöglicht es einem Client, Anwendungsdaten zu senden, bevor der Handshake abgeschlossen ist. Möglich wird dies durch die Wiederverwendung ausgehandelter Parameter einer vorherigen Verbindung. Um dies zu ermöglichen, hängt 0-RTT davon ab, dass sich der Client kritische Parameter merkt und dem Server ein TLS-Sitzungsticket zur Verfügung stellt, das es dem Server ermöglicht, dieselben Informationen wiederherzustellen.

0-RTT sollte jedoch nicht blind aktiviert werden. Dort sind einige möglich Sicherheitsbedenken abhängig von Ihrem Bedrohungsmodell.

Die Sicherheitseigenschaften für 0-RTT-Daten sind schwächer als die für andere Arten von TLS-Daten. Speziell:

  1. Diese Daten sind kein Forward Secret, da sie ausschließlich mit Schlüsseln verschlüsselt werden, die unter Verwendung des angebotenen PSK abgeleitet werden.
  2. Es gibt keine Garantie für Nicht-Wiedergabe zwischen Verbindungen.

Kann ich heute HTTP/3 verwenden?

Vielleicht! Während das Protokoll derzeit drin ist Internet-Entwurf Status, es gibt viele vorhandene Implementierungen.

Ich habe gezielt gewählt Caddie für diese Benchmarks, da HTTP/3 mit a aktiviert werden kann einfacher Konfigurationswert in dem Caddyfile

NGINX hat auch experimentelle Unterstützung und ist es Arbeit an einem offiziellen HTTP/3 Veröffentlichung in naher Zukunft.

Die großen Tech-Player wie Google und Facebook bedienen ihren Traffic bereits über HTTP/3. Google.com wird für moderne Browser vollständig über HTTP/3 bereitgestellt.

Für diejenigen, die im Windows-Ökosystem feststecken, wird Windows Server 2022 angeblich HTTP/3 unterstützen, bei einigen eher esoterische Schritte erforderlich um es zu ermöglichen.

Fazit

HTTP/3 kann einen großen Unterschied darin machen, wie Benutzer Ihre Website erleben. Im Allgemeinen gilt: Je mehr Ressourcen Ihre Website benötigt, desto größer ist die Leistungsverbesserung, die Sie mit HTTP/3 und QUIC sehen werden. Da der Standard immer näher an die Fertigstellung heranrückt, ist es möglicherweise an der Zeit, ihn für Ihre Websites zu aktivieren.

Similar Posts

Leave a Reply

Your email address will not be published.