Leistung und Effizienz: Arbeiten mit HTTP/3

HTTP/3 ist am Horizont, dicht auf den Fersen von HTTP/2 – das selbst wohl noch sehr jung ist. Angesichts der Tatsache, dass es 16 Jahre gedauert hat, um von HTTP/1.1 zu HTTP/2 zu wechseln, sollte sich jemand wirklich mit HTTP/3 befassen?

Die kurze Antwort: Ja, es ist wichtig, und Sie sollten damit auf dem Laufenden sein. Es ist genauso, wie HTTP/2 wesentliche Änderungen gegenüber HTTP/1.1 vorgenommen hat, indem es von ASCII auf Binär umgestellt hat. HTTP/3 nimmt erneut erhebliche Änderungen vor, diesmal durch die Umstellung des zugrunde liegenden Transports von TCP auf UDP.

Obwohl sich HTTP/3 noch in der Entwurfsphase befindet und die offizielle Spezifikation ein Entwurf ist, wird es bereits bereitgestellt, und es besteht eine gute Chance, dass Sie heute eine Version davon in Ihrem Netzwerk finden.

Aber es gibt einige neue Dilemmata, die sich aus der Funktionsweise von HTTP/3 ergeben. Außerdem, was ist der Vorteil? Und was müssen Netzwerkingenieure, Systemadministratoren und Entwickler wissen?

Das Hauptthema: Leistung und Effizienz

Website- und App-Entwickler erstellen im Allgemeinen mit der Absicht, dass ihre Kreationen tatsächlich verwendet werden. Manchmal ist die Zielgruppenbasis begrenzt, aber oft geht es nur darum, so viele Benutzer wie möglich zu gewinnen. Je beliebter eine Website wird, desto mehr Einnahmen kann sie natürlich erzielen.

Eine Verzögerung von 100 Millisekunden bei der Ladezeit einer Website kann die Konversionsrate um 7 Prozent beeinträchtigen.

Akamai Online Retail Performance Report: Millisekunden sind entscheidend (2017)

Anders ausgedrückt: Eine E-Commerce-Site mit einem Umsatz von 40.000 US-Dollar pro Tag würde aufgrund einer solchen Verzögerung jährlich eine Million US-Dollar verlieren.

Es ist auch kein Geheimnis, dass die Leistung einer Website absolut entscheidend dafür ist, dass eine Website immer beliebter wird. Die Online-Shopping-Forschung findet weiterhin Zusammenhänge zwischen erhöhten Absprungraten und längeren Ladezeiten sowie zwischen Käuferloyalität und Website-Performance während des Einkaufserlebnisses.

Die Forschung hat auch Folgendes ergeben:

• 47 % der Verbraucher erwarten, dass eine Webseite in 2 Sekunden oder weniger geladen wird.
• 40 % der Nutzer verlassen eine Website, deren Ladevorgang länger als 3 Sekunden dauert.

Und das war der Stand der Geduld von Online-Käufern vor über einem Jahrzehnt . Die Leistung ist also entscheidend, und HTTP/2 und HTTP/3 bedeuten beide eine bessere Website-Leistung.

HTTP/2? …Was ist das?

Ein gutes Verständnis des HTTP/2-Protokolls ist entscheidend für das Verständnis von HTTP/3. Zunächst einmal, warum war HTTP/2 überhaupt notwendig?

HTTP/2 begann als Google-Projekt namens SPDY, das Ergebnis einer Studie, die berichtete, dass Latenz das größte Leistungsproblem im Web sei. Der Autor kam zu dem Schluss, dass „mehr Bandbreite nicht (viel) ausmacht“:

Wenn wir eine Analogie zwischen Installationen und dem Internet ziehen, können wir die Bandbreite des Internets als den Durchmesser der Wasserleitung betrachten. Ein größeres Rohr führt ein größeres Wasservolumen, und daher können Sie mehr Wasser zwischen zwei Punkten liefern.

Zur gleichen Zeit, egal wie groß Ihr Rohr ist, wenn das Rohr leer ist und Sie Wasser von einem Punkt zum anderen bekommen möchten, dauert es eine Weile, bis Wasser durch das Rohr fließt. Im Internetjargon wird die Zeit, die Wasser benötigt, um von einem Ende des Rohrs zum anderen und wieder zurück zu fließen, als Round Trip Time oder RTT bezeichnet.

Mike Belshe

In der Studie war die Reduzierung der Seitenladezeit das Ziel. Es hat sich gezeigt, dass eine Erhöhung der Bandbreite zunächst hilft, da die Seitenladezeit von 1 Mbit/s auf 2 Mbit/s halbiert wird. Allerdings stagnieren die Vorteile sehr schnell.

Im Gegensatz dazu hat eine Verringerung der Latenz einen konstanten Vorteil und erzielt die besten Ergebnisse.

HTTP HOL: Das Head-of-Line-Blocking-Problem

Die Hauptursache für Latenz innerhalb des HTTP/1-Protokolls ist das Head-of-Line-Blocking-Problem. Webseiten erfordern (fast immer) mehrere Ressourcen: CSS, JavaScript, Schriftarten, Bilder, AJAX/XMR usw. Das bedeutet, dass der Webbrowser mehrere Anfragen an den Server stellen muss. Es sind jedoch nicht alle Ressourcen erforderlich, damit die Seite nützlich wird.

Bei HTTP/1.0 musste der Browser eine Anfrage vollständig abschließen, einschließlich des vollständigen Empfangs der Antwort, bevor er die nächste Anfrage startete. Alles musste der Reihe nach erledigt werden. Jede Anfrage würde die Reihe von Anfragen blockieren, daher der Name.

In einem Versuch, das HOL-Blockierungsproblem zu kompensieren, stellen Webbrowser mehrere gleichzeitige Verbindungen zu einem einzelnen Server her. Aber sie mussten dieses Verhalten willkürlich einschränken: Server, Workstations und Netzwerke können mit zu vielen Verbindungen überlastet werden.

HTTP/1.1 führte mehrere Verbesserungen ein, um das Problem anzugehen. Das wichtigste ist das Pipelining , das es Webbrowsern ermöglicht, neue Anforderungen zu starten, ohne auf den Abschluss vorheriger Anforderungen warten zu müssen. Dies verbesserte die Ladezeiten in Umgebungen mit geringer Latenz erheblich.

Aber es erfordert immer noch, dass alle Antworten nacheinander in der Reihenfolge eintreffen, in der sie gemacht wurden, sodass der Kopf der Leitung immer noch blockiert ist. Überraschenderweise nutzen viele Server diese Funktion immer noch nicht.

Interessanterweise führte HTTP/1.1 auch keep-alive ein, wodurch Browser den Overhead vermeiden konnten, für jede HTTP-Anfrage eine neue TCP-Verbindung zu erstellen. Dies war ein früher Versuch, ein von TCP abgeleitetes Leistungsproblem zu lösen. Es war so ineffektiv, dass die meisten Leistungsexperten davon abraten, weil es den Server mit zu vielen inaktiven Verbindungen blockiert. Wir werden uns TCP unten genauer ansehen und wie dieses Problem durch HTTP/2 behoben wurde.

Die HTTP-HOL-Blockierungslösung von HTTP/2

HTTP/2 führte Request-Response-Multiplexing über eine einzelne Verbindung ein. Ein Browser kann nicht nur jederzeit eine neue Anfrage starten, sondern die Antworten können in beliebiger Reihenfolge empfangen werden – das Blockieren wird auf Anwendungsebene vollständig eliminiert.

Als direktes Ergebnis bedeutet dies, dass HTTP/2-fähige Webserver die Effizienz maximieren können – dazu später mehr.

Obwohl Request-Response-Multiplexing das Hauptmerkmal von HTTP/2 ist, enthält es mehrere andere wichtige Funktionen. Die Leser werden vielleicht bemerken, dass sie alle irgendwie verwandt sind.

HTTP/2-Binär-Framing

HTTP/2 stellt den HTTP-Protokollstandard von einem ineffizienten, für Menschen lesbaren ASCII-Request-Response-Modell auf ein effizientes binäres Framing um . Es ist nicht mehr nur eine Bitte und eine Antwort:

Bei HTTP/2 kommunizieren Browser mit Servern über bidirektionale Streams mit mehreren Nachrichten, die jeweils aus mehreren Frames bestehen.

HTTP/2 HPACK (Header-Komprimierung)

Die neue Header-Komprimierung von HTTP/2, die das HPACK-Format verwendet, spart bei den meisten Websites eine Menge Bandbreite. Dies liegt daran, dass die meisten Header für die innerhalb einer Verbindung gesendeten Anforderungen gleich sind.

Cloudflare berichtet von erheblichen Bandbreiteneinsparungen allein dank HPACK:

• 76 % Komprimierung für Ingress-Header
• Reduzierung des gesamten eingehenden Datenverkehrs um 53 %
• 69 % Komprimierung für Egress-Header
• Reduzierung des gesamten ausgehenden Datenverkehrs um 1,4 % bis 15 %

Natürlich bedeutet weniger Bandbreite im Allgemeinen eine schnellere Website.

HTTP/2-Stream-Priorisierung und Server-Push

Hier ermöglicht das Multiplexing von HTTP/2 dem Server wirklich, die Effizienz zu maximieren. Multiplexing hilft dabei, schnellere Ressourcen (z. B. im Speicher zwischengespeichertes JavaScript) vor langsameren (z. B. große Bilder, datenbankgeneriertes JSON usw.) bereitzustellen. Aber es ermöglicht auch einen zusätzlichen Leistungsschub über die Stream-Priorisierung von HTTP/2.

Die Stream-Priorisierung trägt dazu bei, dass fast fertige Aspekte einer Seite vollständig abgeschlossen werden, ohne dass auf die Fertigstellung anderer ressourcenintensiver Anforderungen gewartet werden muss. Dies wird durch einen gewichteten Abhängigkeitsbaum erreicht. Dieser Baum wird verwendet, um den Server darüber zu informieren, für welche Antworten er die meisten Systemressourcen zuordnen sollte.

Dies ist besonders wichtig für Progressive Web Applications (PWAs). Angenommen, eine Seite enthält vier JavaScript-Dateien. Zwei sind für die Seitenfunktionalität und zwei für Anzeigen. Das Worst-Case-Szenario besteht darin, die Hälfte des funktionalen JS und die Hälfte des Werbe-JS zu laden und dann große Bilder zu laden, bevor das restliche JS geladen wird. In diesem Fall funktioniert zunächst nichts auf der Seite, da alles auf die langsamste Ressource warten muss.

Mit der Stream-Priorisierung können Webbrowser den Server anweisen, beide Seitenfunktionalitäts-JS-Dateien zu senden, bevor sie eine der Werbe-JavaScript-Dateien senden. Auf diese Weise müssen Benutzer nicht warten, bis die Anzeigen vollständig geladen sind, bevor sie die Funktionen der Seite nutzen können. Obwohl sich die Gesamtladezeit nicht verbessert hat, wurde die wahrgenommene Leistung erheblich gesteigert. Leider ist dieses Verhalten innerhalb des Webbrowsers immer noch hauptsächlich Sache von Algorithmen und nicht etwas, das von Webentwicklern vorgegeben wird.

In ähnlicher Weise ermöglicht die Server- Push-Funktion von HTTP/2 dem Server , Antworten auf Anfragen, die er noch nicht gestellt hat, an den Browser zu senden! Der Server kann Übertragungslücken ausnutzen und die Bandbreite effizient nutzen, indem er Ressourcen in den Browser vorab lädt, von denen der Server weiß, dass er sie bald anfordern wird. Ein Teil der Hoffnung besteht hier darin, die Praxis des Ressourcen-Inlinings zu eliminieren, das Ressourcen nur aufbläht und das Laden länger dauert.

Leider erfordern diese beiden Funktionen viel sorgfältige Konfiguration durch Webentwickler, um wirklich erfolgreich zu sein. Es reicht nicht aus, sie einfach zu aktivieren.

HTTP/2 bringt eindeutig viele potenzielle Vorteile mit sich, von denen einige billiger zu nutzen sind als andere. Wie geht es ihnen in der realen Welt?

HTTP vs. HTTP/2-Einführung

SPDY wurde 2009 erstellt. HTTP/2 wurde 2015 standardisiert. SPDY wurde der Name eines instabilen Entwicklungszweigs des Codes, wobei HTTP/2 die endgültige Version wurde. Das Ergebnis ist, dass SPDY veraltet ist und HTTP/2 im Allgemeinen der Standard ist, dem alle folgen.

Nach der Standardisierung wuchs die Einführung von HTTP/2 (oder „h2“) schnell auf rund 40 % der Top-1.000-Websites. Dies wurde hauptsächlich von großen Hosting- und Cloud-Anbietern vorangetrieben, die im Namen ihrer Kunden Support bereitstellen. Leider hat sich die Einführung von HTTP/2 einige Jahre später verlangsamt und der Großteil des Internets ist immer noch auf HTTP/1.

Fehlende Browserunterstützung für den HTTP/2-Klartextmodus

Es gab viele Forderungen nach HTTP/2, um die Verschlüsselung zu einem erforderlichen Bestandteil des Standards zu machen. Stattdessen definierte der Standard sowohl den verschlüsselten (h2) als auch den Klartextmodus (h2c). Als solches könnte HTTP/2 HTTP/1 vollständig ersetzen.

Trotz des Standards unterstützen alle aktuellen Webbrowser nur HTTP/2 über verschlüsselte Verbindungen und implementieren bewusst keinen Klartextmodus. Stattdessen verlassen sich Browser auf den HTTP/1-Abwärtskompatibilitätsmodus, um auf unsichere Server zuzugreifen. Dies ist ein direktes Ergebnis eines ideologischen Vorstoßes, das Internet standardmäßig sicher zu machen.

Warum HTTP/3? Und wie ist es anders?

Nachdem das HTTP-Head-of-Line-Blocking-Problem jetzt durch HTTP/2 behoben wurde, haben Protokollentwickler ihre Aufmerksamkeit auf den nächstgrößten Latenztreiber gerichtet: das TCP -Head-of-Line-Blocking-Problem.

Transmission Control Protocol (TCP)

IP-Netzwerke (Internet Protocol) basieren auf der Idee, dass Computer sich gegenseitig Pakete senden. Ein Paket besteht nur aus Daten, an deren Spitze einige Adressierungsinformationen angehängt sind.

Anwendungen müssen jedoch normalerweise mit Datenströmen umgehen. Um diese Illusion zu erreichen, präsentiert das Transmission Control Protocol (TCP) Anwendungen eine Röhre, durch die ein Datenstrom fließen kann. Wie bei den meisten Pipes gibt es eine Garantie, dass Daten die Pipe in der gleichen Reihenfolge verlassen, in der sie eintreten, auch bekannt als „first in, first out“ (FIFO). Diese Eigenschaften haben TCP sehr nützlich und sehr weit verbreitet gemacht.

Als Teil der Datenlieferungsgarantien, die TCP bereitstellt, muss es in der Lage sein, eine Vielzahl von Situationen zu bewältigen. Eines der komplexesten Probleme besteht darin, alle Daten zu liefern, wenn ein Netzwerk überlastet ist, ohne die Situation für alle zu verschlimmern. Der Algorithmus dafür heißt Congestion Control und ist ein sich ständig weiterentwickelnder Teil der Internetspezifikationen. Ohne ausreichende Staukontrolle kommt das Internet zum Erliegen.

Im Oktober 1986 hatte das Internet den ersten einer Reihe von „Überlastungszusammenbrüchen“. Während dieses Zeitraums fiel der Datendurchsatz von LBL zu UC Berkeley (Standorte, die durch 400 Yards und drei IMP-Hops getrennt sind) von 32 Kbps auf 40 bps.

V. Jacobson (1988)

Hier kommt das TCP-Head-of-Line-Blocking-Problem ins Spiel.

TCP-HOL-Blockierungsproblem

Die TCP-Überlastungskontrolle funktioniert durch die Implementierung von Backoff- und Neuübertragungsmechanismen für Pakete, die immer dann verwendet werden, wenn ein Paketverlust erkannt wird. Backoff soll helfen, das Netzwerk zu beruhigen. Die erneute Übertragung stellt sicher, dass die Daten schließlich geliefert werden.

Dies bedeutet, dass TCP-Daten in der falschen Reihenfolge am Ziel ankommen können und es in der Verantwortung der empfangenden Partei liegt, die Pakete neu zu ordnen, bevor sie sie wieder in den Stream einfügen. Leider bedeutet dies, dass ein einzelnes verlorenes Paket dazu führen kann, dass der gesamte TCP-Stream angehalten wird, während der Server auf seine erneute Übertragung wartet. Daher ist der Kopf der Leitung blockiert.

Ein weiteres Projekt von Google zielte darauf ab, dieses Problem durch die Einführung eines Protokolls namens QUIC zu lösen.

Das QUIC-Protokoll baut auf UDP statt auf TCP auf, und QUIC bildet die Grundlage für HTTP/3.

Was ist UDP?

Das User Datagram Protocol (UDP) ist eine Alternative zu TCP. Es bietet nicht die Illusion eines Streams oder die gleichen Garantien, die TCP bietet. Stattdessen bietet es einfach eine einfache Möglichkeit, Daten in ein Paket zu packen, es an einen anderen Computer zu adressieren und es zu senden. Es ist unzuverlässig , ungeordnet und verfügt über keinerlei Überlastungssteuerung.

Sein Zweck ist es, leicht zu sein und die minimalen Funktionen bereitzustellen, die erforderlich sind, um eine Kommunikation zu ermöglichen. Auf diese Weise kann die Anwendung ihre eigenen Garantien implementieren. Dies ist in Echtzeitanwendungen oft sehr nützlich. Beispielsweise ziehen es die Benutzer bei Telefonaten im Allgemeinen vor, 90 % der Daten sofort zu erhalten, anstatt 100 % der Daten schließlich.

Die TCP-HOL-Lösung von HTTP/3

Die Lösung des TCP-HOL-Blockierungsproblems erforderte mehr als nur den Wechsel zu UDP, da es immer noch notwendig ist, die Lieferung aller Daten zu garantieren und einen Zusammenbruch der Netzwerküberlastung zu vermeiden. Das QUIC-Protokoll wurde entwickelt, um all dies zu tun, indem es eine optimierte Erfahrung vom Typ HTTP über UDP bereitstellt.

Da QUIC die Kontrolle über das Stream-Management, binäres Framing usw. übernimmt, bleibt HTTP/2 nicht mehr viel zu tun, wenn es auf QUIC läuft. Dies ist einer der treibenden Faktoren dafür, dass diese neue Kombination aus QUIC + HTTP als HTTP/3 standardisiert wird.

Hinweis: Es gibt viele Versionen von QUIC, da sich das Protokoll seit Jahren in der Entwicklung befindet und in Produktionsumgebungen eingesetzt wird. Es gibt sogar eine Google-spezifische Version namens GQUIC. Daher ist es wichtig, zwischen den alten QUIC-Protokollen und dem neuen HTTP/3-Standard zu unterscheiden.

Immer verschlüsselt

HTTP/3 enthält eine Verschlüsselung, die sich stark an TLS anlehnt, es aber nicht direkt verwendet. Eine der größten Herausforderungen bei der Implementierung von HTTP/3 besteht darin, dass die TLS/SSL-Bibliotheken geändert werden müssen, um die neu erforderliche Funktionalität hinzuzufügen.

Diese Änderung liegt daran, dass sich HTTP/3 in Bezug auf die Verschlüsselung von HTTPS unterscheidet. Beim älteren HTTPS-Protokoll werden nur die Daten selbst durch TLS geschützt, sodass viele der Transportmetadaten sichtbar bleiben. Bei HTTP/3 sind sowohl die Daten als auch das Transportprotokoll geschützt. Das mag wie ein Sicherheitsmerkmal klingen, und das ist es auch. Aber es wird auf diese Weise gemacht, um einen Großteil des in HTTP/2 vorhandenen Overheads zu vermeiden. Daher macht die Verschlüsselung des Transportprotokolls sowie der Daten das Protokoll tatsächlich leistungsfähiger.

Auswirkungen von HTTP/3 auf die Netzwerkinfrastruktur

HTTP/3 ist nicht unumstritten. Die Hauptsorgen betreffen die Netzwerkinfrastruktur.

Clientseitiges HTTP/3

Auf der Client-Seite ist es ziemlich üblich, dass der UDP-Verkehr stark in der Rate begrenzt und/oder blockiert wird. Die Anwendung dieser Beschränkungen auf HTTP/3 macht den Sinn des Protokolls zunichte.

Zweitens ist es durchaus üblich, dass HTTP überwacht und/oder abgefangen wird. Selbst bei HTTPS-Verkehr überwachen Netzwerke regelmäßig die Klartext-Transportelemente des Protokolls, um festzustellen, ob sie die Verbindung trennen sollten, um den Zugriff auf bestimmte Websites von bestimmten Netzwerken oder innerhalb bestimmter Regionen zu verhindern. In einigen Ländern ist dies für bestimmte Dienstleister sogar gesetzlich vorgeschrieben. Die obligatorische Verschlüsselung in HTTP/3 macht dies unmöglich.

Es ist nicht nur eine Filterung auf Regierungsebene. Viele Universitäten, öffentliche Bibliotheken, Schulen und Haushalte mit besorgten Eltern entscheiden sich aktiv dafür, den Zugang zu bestimmten Websites zu sperren oder zumindest ein Protokoll darüber zu führen, welche Websites besucht wurden. Die obligatorische Verschlüsselung in HTTP/3 macht dies unmöglich.

Es ist erwähnenswert, dass derzeit eine eingeschränkte Filterung möglich ist . Das liegt daran, dass das Server Name Indication (SNI)-Feld – das den Hostnamen der Website enthält, aber nicht Pfad, Abfrageparameter usw. – immer noch nicht verschlüsselt ist. Dies soll sich aber in naher Zukunft mit der Einführung von ESNI (encrypted SNI) ändern, das kürzlich in den TLS-Standard aufgenommen wurde.

Serverseitiges HTTP/3

Auf der Serverseite empfiehlt es sich, alle Ports und Protokolle zu blockieren, die keinen Datenverkehr erwarten, was bedeutet, dass Serveradministratoren jetzt UDP 443 für HTTP/3 öffnen müssen, anstatt sich auf ihre bestehenden TCP 443-Regeln zu verlassen.

Zweitens kann die Netzwerkinfrastruktur TCP-Sitzungen sticky machen, was bedeutet, dass sie immer an denselben Server weitergeleitet werden, selbst wenn sich die Routing-Prioritäten ändern. Da HTTP/3 über sitzungsloses UDP läuft, muss die Netzwerkinfrastruktur aktualisiert werden, um HTTP/3-spezifische Verbindungs-IDs zu verfolgen, die unverschlüsselt gelassen wurden, um das Sticky-Routing zu unterstützen.

Drittens ist es durchaus üblich, dass HTTP untersucht wird, um Missbrauch zu erkennen, auf allgemeine Sicherheitsprobleme zu überwachen, die Verbreitung von Malware und Viren zu erkennen und zu verhindern usw. Dies ist mit HTTP/3 aufgrund seiner Verschlüsselung nicht möglich. Dennoch sind Optionen möglich, bei denen das abfangende Gerät über eine Kopie der Sicherheitsschlüssel verfügt, vorausgesetzt, die Geräte implementieren HTTP/3-Unterstützung.

Schließlich haben viele Administratoren Einwände dagegen, noch mehr SSL-Zertifikate verwalten zu müssen, obwohl das jetzt weniger ein Problem darstellt, da Dienste wie Let's Encrypt verfügbar sind.

Bis es weithin akzeptierte, bekannte Lösungen gibt, um diese Bedenken auszuräumen, werden wahrscheinlich viele große Netzwerke HTTP/3 einfach blockieren.

Auswirkungen von HTTP/3 auf die Webentwicklung

An dieser Front gibt es nicht viel zu befürchten. Die Stream-Priorisierung und die Server-Push-Funktionen von HTTP/2 sind auch in HTTP/3 vorhanden. Für Webentwickler lohnt es sich, sich mit diesen Funktionen vertraut zu machen, wenn sie ihre Website-Performance wirklich optimieren wollen.

Verwenden Sie jetzt HTTP/3

Benutzer von Google Chrome oder des Open-Source-Browsers Chromium sind bereits auf die Verwendung von HTTP/3 eingestellt. Releases von HTTP/3-Servern in Produktionsqualität sind noch in weiter Ferne – die Spezifikation ist zum jetzigen Zeitpunkt noch nicht ganz abgeschlossen. Aber inzwischen gibt es viele Tools, mit denen man spielen kann, und sowohl Google als auch Cloudflare haben die Unterstützung bereits in ihre Produktionsumgebungen verschoben.

Der einfachste Weg, es auszuprobieren, ist die Verwendung von Caddy in Docker. Dafür wird ein SSL-Zertifikat benötigt, eine öffentlich zugängliche IP-Adresse macht es also einfach. Die Schritte sind:

1. DNS-Setup. Holen Sie sich einen funktionierenden Hostnamen, der im Internet aktiv ist, z. B. yourhostname.example.com IN A 192.0.2.1 .
2. Caddyfile-Erstellung. Es sollte diese Zeilen enthalten:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Ausführen von Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic – oder außerhalb von Docker, caddy --quic .
2. Chromium mit aktiviertem QUIC ausführen: chromium --enable-quic
3. (Optional) Installieren einer Protocol Indicator-Erweiterung.
4. Navigieren Sie zum QUIC-fähigen Server , wo ein Dateibrowser sichtbar sein sollte.

Entwickler können ihre Server auch mit den folgenden nützlichen Tools testen:

• HTTP/2-Test von Keycdn
• HTTP3Check von LiteSpeed
• SSL-Servertest von Qualys

Danke fürs Lesen!