Leistungsvergleich von HTTP / 3 und HTTP / 2

Wir von Cloudflare haben im vergangenen September HTTP / 3-Unterstützung angekündigt, als wir unseren neunten Geburtstag feierten . Unser Ziel war es immer, das Internet zu verbessern. Die Zusammenarbeit im Bereich der Standards ist ein wichtiger Teil des Prozesses, und wir sind froh, an der Entwicklung von HTTP / 3 beteiligt zu sein.

Obwohl sich HTTP / 3 noch im Entwurfsstadium befindet, haben wir bei unseren Benutzern ein großes Interesse an dem neuen Protokoll festgestellt (die Cloudflare-Infrastruktur bedient mehr als 10% der Internetseiten - ca. Per.). Bisher haben mehr als 113.000 Zonen die HTTP / 3-Unterstützung aktiviert. Wenn Sie einen experimentellen Browser haben, können Sie jetzt mit dem neuen Protokoll auf diese Zonen zugreifen! Es ist großartig, dass so viele Leute es aufgenommen haben: Wenn Sie an HTTP / 3 einer großen Anzahl realer Websites arbeiten, können Sie verschiedene Eigenschaften in Browsern testen.

Wir haben HTTP / 3 zunächst in Zusammenarbeit mit Google gestartet , was auch experimentelle Unterstützung für Chrome Canary beinhaltete. Seitdem haben immer mehr Browser experimentelle Unterstützung hinzugefügt: Sie wurde in Firefox Nightly-Builds , in verschiedenen Chromium-basierten Browsern wie Opera und Edge (über die Chromium-Basis-Engine) und in vorläufigen Safari- Builds veröffentlicht . Wir beobachten diese Entwicklungen genau und helfen, wo immer wir können. Ein großes Netzwerk von Sites, die HTTP / 3 aktiviert haben, bietet Browser-Entwicklern ein hervorragendes Testfeld für die Validierung des Codes.

Wie ist der aktuelle Status?

Der IETF-Standardisierungsprozess umfasst eine Reihe von Entwürfen zur Erstellung eines „endgültigen Entwurfs“, der zur Kennzeichnung als RFC-Standard bereit ist. Die Mitglieder des QUIC-Teams arbeiten gemeinsam an Analyse, Implementierung und Interoperabilität, um potenzielle Probleme zu identifizieren. Wir haben die Protokollunterstützung bereits in der Phase des 23. Entwurfs gestartet und dann alle Änderungen verfolgt. Zum Zeitpunkt des Schreibens (14. April 2020) war der letzte die 27. Version. Mit jedem Entwurf verbessert sich die Qualität der QUIC-Definitionen und es entsteht ein „grober Konsens“ darüber, wie sich das Protokoll verhalten soll. Um eine fortwährende Analyse mit endlos idealen Dopilivaniya-Einstellungen zu vermeiden, erhöht sich mit jeder neuen Version des Entwurfs die Leiste für Änderungen an der Spezifikation. Dies bedeutet, dass mit jeder Version weniger Änderungen vorgenommen werden und der endgültige RFC eng mit dem Protokoll übereinstimmt, das wir bereits in der Produktion gestartet haben.

Leistungen

Einer der Hauptvorteile von HTTP / 3 war die Leistungssteigerung, insbesondere wenn mehrere Objekte gleichzeitig angefordert wurden. In HTTP / 2 blockiert jede Störung (Paketverlust) in einer TCP-Verbindung alle Flüsse gleichzeitig (Blockieren des Zeilenanfangs). Da HTTP / 3 auf UDP basiert, wird nur ein Stream unterbrochen, wenn ein Paket verloren geht, aber nicht alle.

Darüber hinaus unterstützt HTTP / 3 0-RTT (Null-Empfangs- / Sendezeit ), dh nachfolgende Verbindungen können viel schneller als die erste gestartet werden, sodass TLS beim Herstellen einer Verbindung nicht mehr vom Server bestätigt werden muss. Dies bedeutet, dass der Client Daten viel früher anfordert als bei vollständiger TLS-Aushandlung, dh die Website wird früher in den Browser geladen.

Die folgenden Animationen zeigen den Effekt des Paketverlusts. Im ersten Beispiel werden Anforderungen vom Client über HTTP / 2 an den Server empfangen, um zwei Ressourcen zu empfangen. Anfragen und zugehörige Antworten sind grün und gelb gefärbt. Die Antworten sind in mehrere Pakete unterteilt. Leider geht ein Paket verloren - infolgedessen verzögert sich die Übertragung beider Ressourcen.



Im zweiten Beispiel werden Anforderungen für zwei Ressourcen über HTTP / 3 empfangen. Ein Paket geht verloren und blockiert die Übertragung der gelben Ressource, ohne jedoch die grüne zu beeinträchtigen.



Verbesserungen im Verfahren zum Aushandeln einer Sitzung führen dazu, dass „Verbindungen“ mit Servern viel schneller hergestellt werden, dh Daten schneller im Browser ankommen. Wir waren gespannt, wie sehr sich dies im realen Verkehr widerspiegelt, und haben daher mehrere Tests durchgeführt. Um den Beitrag von 0-RTT zu bewerten, haben wir mehrere Kontrolltests gestartet, um die Zeit bis zum ersten Byte (Zeit bis zum ersten Byte, TTFB) zu messen. Im Durchschnitt wird über HTTP / 3 das erste Byte nach 176 ms angezeigt. Im Fall von HTTP / 2 sehen wir 201 ms, dh HTTP / 3 reduziert hier die Verzögerung um 12,4%!



Interessanterweise regeln Entwürfe und RFCs nicht alle Aspekte des Protokolls. Beispielsweise wirkt sich die Paketübertragungsmethode auf die Leistung aus.und Verkehrsüberlastungssteuerungsalgorithmus. Die Überlastungskontrolle ist eine Methode zur Anpassung an überlastete Netzwerke auf Client- und Serverseite: Wenn Pakete verloren gehen, nimmt die Kommunikationsqualität ab. Da QUIC ein neues Protokoll ist, sind Experimente und Optimierungen erforderlich, um ein Überlastmanagementsystem ordnungsgemäß zu entwerfen und zu implementieren.

Als einfachen und sicheren Ausgangspunkt empfiehlt die Spezifikation zur Schadenserkennung und Überlastungskontrolle den Reno- Algorithmus , es kann jedoch auch jeder andere verwendet werden. Wir haben mit dem New Reno- Algorithmus begonnen , aber aufgrund unserer Erfahrung haben wir angenommen, dass er nicht optimal ist. Wir sind kürzlich zu CUBIC gewechselt - Und in einem Netzwerk mit übergroßen Übertragungen und größerem Paketverlust schnitt CUBIC besser ab als New Reno. Bald werden wir mehr darüber sprechen, seien Sie gespannt auf ein Blog-Update.

Im aktuellen HTTP / 2-Stack haben wir BBR v1 (TCP). Dies bedeutet, dass die Tests keinen exakten Vergleich von Äpfeln mit Äpfeln durchführen, da sich diese Überlastungskontrollalgorithmen bei verschiedenen Zahnradgrößen unterschiedlich verhalten. Beim Wechsel von HTTP / 2 zu HTTP / 3 sehen wir jedoch bereits eine Verbesserung bei kleineren Websites. In großen Bereichen zeigt unser fein abgestimmter und optimierter HTTP / 2-Stack eine brillante Leistung.

Eine kleine 15K-Testseite wird durchschnittlich in 443 ms über HTTP / 3 geladen, verglichen mit 458 ms für HTTP / 2. Wenn Sie jedoch die Seitengröße auf 1 MB erhöhen, verschwindet dieser Vorteil: Speziell in unserem Netzwerk arbeitet das HTTP / 3-Protokoll jetzt etwas langsamer als HTTP / 2 - 2,33 s gegenüber 2,30 s.







Synthetische Benchmarks sind interessant, aber es ist interessant, wie sich HTTP / 3 in der realen Welt zeigt.

Zum Vergleich wollten wir einen Drittanbieter-Service gewinnen, der Websites aus unserem Netzwerk herunterladen und einen Webbrowser simulieren kann. WebPageTest ist ein gängiges Framework zum Messen der Ladezeit von Seiten mit guten Kaskadendiagrammen (Wasserfall). Um das Backend zu analysieren, verwendeten wir unser eigenes Browser Insights- System , um die Timings am Rand unseres Netzwerks festzulegen. Dann verbanden sie beide Teile durch ein wenig Automatisierung.

Als Testfall zur Leistungsmessung haben wir unseren eigenen Blog genommen . Wir haben unsere WebPageTest-Instanzen so eingerichtet, dass die Site von Standorten auf der ganzen Welt geladen wird, sowohl über HTTP / 2 als auch über HTTP / 3. Enthalten sind HTTP / 3 und Browser Insights. Jedes Mal, wenn ein Browser mit HTTP / 3-Unterstützung die Seite lud, forderten Testskripte gesammelte Analysedaten vom Browser an. Das gleiche Verfahren wurde für HTTP / 2 wiederholt, damit es verglichen werden konnte.

Das folgende Diagramm zeigt die Ladezeit der tatsächlichen Seite blog.cloudflare.com mit einem Vergleich der HTTP / 3- und HTTP / 2-Metriken. Wir haben solche Metriken für verschiedene geografische Punkte.



Wie Sie sehen können, ist die HTTP / 3-Leistung immer noch schlechter als die HTTP / 2-Leistung. In Nordamerika beträgt der Unterschied durchschnittlich 1-4%. Ähnliche Ergebnisse in Europa, Asien und Südamerika. Wir vermuten, dass dies auf einen Unterschied in den Überlastungskontrollalgorithmen zurückzuführen ist: BBR v1 funktioniert unter HTTP / 2 und CUBIC unter HTTP / 3. In Zukunft werden wir versuchen, auf beiden Protokollen denselben Überlastungskontrollalgorithmus zu implementieren, um einen genaueren Vergleich von Äpfeln mit Äpfeln zu erhalten.

Fazit

Insgesamt freuen wir uns sehr, den neuen Standard weiterzuentwickeln. Unsere Implementierung funktioniert gut, zeigt in einigen Situationen eine bessere Leistung und im schlimmsten Fall - ähnliches HTTP / 2. Nach Fertigstellung des Standards freuen wir uns auf Browser, die in den Hauptversionen HTTP / 3-Unterstützung hinzufügen. Wir werden die neuesten Entwürfe unterstützen und nach neuen Möglichkeiten suchen, um HTTP / 3 zu optimieren, um die Leistung weiter zu verbessern, unabhängig davon, ob Überlastungskontrolle, Priorisierung oder Systemkonfiguration (CPU- und Kanalbandbreite) eingerichtet werden.

Wenn Sie in der Zwischenzeit HTTP / 3 in Aktion ausprobieren möchten, aktivieren Sie es einfach in unserem Dashboard und laden Sie die Testassembly (Nightly, Canary) eines der Hauptbrowser herunter. Anweisungen zum Aktivieren von HTTP / 3 finden Sie in unserer Entwicklerdokumentation .