Was ist HTTP/3? – Hintergrundinformationen über das schnelle neue UDP-basierte Protokoll

TL;DR

Im November 2018 tagte die Internet Engineering Task Force (IETF) in Bangkok, und ein neuer Internet-Entwurf wurde verabschiedet. Das QUIC-Transportprotokoll, ein HTTP/2-Nachfolger, wurde in HTTP/3 umbenannt.

HTTP/3 baut auf dem User Datagram Protocol (UDP) auf und wird bereits von bekannten Internetunternehmen wie Google und Facebook verwendet. Wenn du Chrome verwendest und eine Verbindung zu einem Google-Dienst herstellst, verwendest du wahrscheinlich bereits QUIC.

Die neue Version des HTTP-Protokolls profitiert vom Bare-Metal, Low-Level-UDP-Protokoll und definiert viele der neuen Funktionen, die in früheren Versionen von HTTP auf der TCP-Schicht waren. Dies bietet eine Möglichkeit, Einschränkungen innerhalb der bestehenden Internet-Infrastruktur zu lösen.

Die ersten Ergebnisse sind vielversprechend, und wenn der Internet Draft der IETF im August 2021 ausläuft, können wir erwarten, dass HTTP/3 als neuer HTTP-Standard der dritten Generation beworben wird.

HTTP/3 Fortschritte im 2024

Vor ein paar Jahren haben wir einen Artikel über HTTP/2 veröffentlicht, einen Standard, der laut W3Techs inzwischen eine weltweite Akzeptanzrate von 45 % erreicht hat. Und laut Can I Use wird er auch von allen modernen Webbrowsern unterstützt. Doch jetzt schreiben wir einen Artikel über die nächste Version des Protokolls, HTTP/3.

HTTP/3 ist zum Zeitpunkt dieses Schreibens ein IETF Internet-Draft oder ID, was bedeutet, dass es derzeit von der Internet Engineering Task Force – einem internationalen Gremium für Internet-Standards, das für die Definition und Förderung vereinbarter Internet-Protokollstandards wie TCP, IPv6, VoIP, Internet of Things usw. zuständig ist – für einen kommenden Internet-Standard geprüft wird.

Es ist ein offenes Gremium, das die Webbranche vereint und die Diskussion über die Richtung des Internets fördert. Derzeit ist die „Internet Draft“-Phase von HTTP/3 die letzte Phase, bevor die Vorschläge auf die Ebene der Request-for-Comments (oder RFCs) befördert werden, die wir in jeder Hinsicht als offizielle Internetprotokolldefinitionen betrachten können.

Auch wenn HTTP/3 noch kein offizielles Internetprotokoll ist, haben viele Unternehmen und Projekte bereits damit begonnen, HTTP/3-Unterstützung in ihre Produkte aufzunehmen.

Web Browser Unterstützung für HTTP/3

Was die Webbrowser angeht, so ist HTTP/3 in Chrome v87, Firefox v88 und Edge v87 standardmäßig aktiviert. Für Safari-Nutzer wurde die Option zur Aktivierung von HTTP/3 in Safari Technology Preview v104 hinzugefügt. Allerdings ist die HTTP/3-Unterstützung in der stabilen Version von Safari derzeit nicht verfügbar.

Bibliotheksunterstützung für HTTP/3

Für Entwickler, die HTTP/3-Technologien nutzen wollen, haben viele beliebte Bibliotheken bereits Unterstützung für HTTP/3 hinzugefügt. Da sich HTTP/3 noch im Internet Draft-Stadium befindet, solltest du sicherstellen, dass du auf dem neuesten Stand bist, wenn du mit einer der unten aufgeführten Bibliotheken arbeitest.

• Python – http3 und aioquic
• Rust – quiche, neqo, and quinn
• C – nghttp3 und lsquic
• Go – quicgo
• JavaScript – Node.js

Infrastruktur Unterstützung für HTTP/3

Auf der Infrastrukturseite hat Cloudflare mit der Unterstützung für HTTP/3 in seinem gesamten Edge-Netzwerk eine Vorreiterrolle übernommen. Das bedeutet, dass Seiten, auf denen Cloudflare aktiviert ist, ohne zusätzlichen Aufwand von den Sicherheits- und Leistungsverbesserungen von HTTP/3 profitieren können.

Bei Kinsta sind alle Seiten, die wir hosten, durch unsere kostenlose Cloudflare-Integration geschützt. Zusätzlich zu einer Firewall auf Unternehmensniveau und DDoS-Schutz haben Kinsta-Kunden auch Zugang zu HTTP/3!

Um zu testen, ob deine Seite HTTP/3 unterstützt, kannst du das HTTP/3-Testtool von Geekflare verwenden. Gib einfach deine Domain ein und klicke auf die Schaltfläche „Check HTTP/3“. Das Tool teilt dir dann mit, ob deine Seite HTTP/3-fähig ist.

Wenn deine Seite HTTP/3 unterstützt, solltest du eine Meldung wie die folgende sehen. Da kinstalife.com auf Kinsta gehostet wird, wird HTTP/3 dank unserer Cloudflare-Integration vollständig unterstützt.

Du kannst auch den Inspektor deines Browsers verwenden, um zu prüfen, ob HTTP/3 unterstützt wird. Für dieses Beispiel verwenden wir die neueste Version von Google Chrome, die HTTP/3 unterstützt.

Um den Inspektor zu öffnen, klickst du mit der rechten Maustaste auf die Seite, dann auf „Inspizieren“ und navigierst zum Reiter „Netzwerk“. In der Spalte „Protokoll“ kannst du das HTTP-Protokoll sehen, das für die Verbindung verwendet wird. HTTP/2-Verbindungen werden als „h2“ angezeigt, während HTTP/3-Verbindungen als „h3-XX“ erscheinen (XX bezieht sich auf einen bestimmten HTTP/3-Draft). Wie du in der Abbildung unten sehen kannst, unterstützt kinstalife.com Verbindungen über „h3-29“, was „HTTP/3 Draft 29“ bedeutet.

Nachdem wir nun den aktuellen Stand von HTTP/3 besprochen haben, wollen wir uns nun mit den Unterschieden zwischen HTTP/2 und HTTP/3 beschäftigen!

Ein wenig Hintergrund – es begann mit HTTP/2

HTTP/2 brachte einige ernsthafte Verbesserungen bei nicht-blockierenden Downloads, Pipelining und Server-Push, was uns geholfen hat, einige Einschränkungen des zugrunde liegenden TCP-Protokolls zu überwinden. Dadurch konnten wir die Anzahl der Request-Response-Zyklen und Handshakes minimieren.

HTTP/2 ermöglichte es, mehr als eine Ressource in einer einzigen TCP-Verbindung zu verschieben – Multiplexing. Wir haben auch mehr Flexibilität bei der Reihenfolge der statischen Downloads, und unsere Seiten sind nun nicht mehr durch einen linearen Verlauf der Downloads eingeschränkt.

In der Praxis bedeutet dies, dass jetzt eine große Javascript-Ressource nicht unbedingt einem Choke-Point für alle anderen statischen Ressourcen entspricht, die auf ihren Einsatz warten.

Wenn man zu diesen Dingen die HTTP/2-Header HPACK-Kompression und das standardmäßige Binärformat der Datenübertragung hinzufügt, haben wir in vielen Fällen ein wesentlich effizienteres Protokoll.

Große Browser-Implementierungen machten es erforderlich, dass Websites eine Verschlüsselung – SSL – implementieren mussten, um die Vorteile von HTTP/2 nutzen zu können – und manchmal verursachte dies einen Rechenaufwand, der Geschwindigkeitsverbesserungen unbemerkbar machte. Es gab sogar einige Fälle, in denen Benutzer von einer Verlangsamung nach der Umstellung auf HTTP/2 berichteten.

Halten wir einfach fest, dass die ersten Tage der Einführung dieser Version nichts für Herzschwache waren.

Der Nginx-Implementierung fehlte auch die Server-Push-Funktion, die sich auf ein Modul stützte. Und NGINX-Module sind nicht die üblichen Apache Drop-In-Module, die man einfach kopieren kann – Nginx muss mit diesen neu kompiliert werden.

Während einige dieser Probleme jetzt gelöst sind, sehen wir, wenn wir uns den gesamten Protokollstapel ansehen, dass die primäre Einschränkung auf einer niedrigeren Ebene liegt, als HTTP/2 es gewagt hat.

Um dies zu erläutern, werden wir den heutigen Internet-Protokollstapel von der unteren Schicht nach oben zerlegen. Wenn Du mehr über den Hintergrund von HTTP/2 erfahren möchtest, schau Dir unbedingt unseren ultimativen HTTP/2-Leitfaden an.

Internet Protokoll (IP)

Das Internet Protocol (IP) definiert den unteren Teil der gesamten Internet-Topologie. Es ist der Teil des Internet-Stacks, der, wie wir mit Sicherheit sagen können, wirklich nicht verhandelbar ist, ohne alles zu ändern, einschließlich der Ersetzung der gesamten Hardware-Infrastruktur, von Routern über Server bis hin zu den Maschinen der Endbenutzer.

Auch wenn die Protokollrevision fällig sein mag, ist ein so weitreichendes Vorhaben derzeit nicht in Sicht, vor allem, weil wir keine brauchbare, bahnbrechende und doch rückwärtskompatible Alternative gefunden haben.

Wir können die Anfänge des IP-Protokolls bis 1974 zurückverfolgen, auf ein Papier, das vom Institute of Electrical and Electronics Engineers veröffentlicht und von Vint Cerf und Bob Cahn verfasst wurde. Es definiert die Pakete, die über ein Netzwerk gesendet werden, indem es sie über IP-Adressen und numerisch definierte Adressen von Knoten in einem Netzwerk/Netzen leitet. Das Protokoll definierte das Format dieser Pakete oder Datagramme – seine Header und Nutzlast.

Nach der RFC 760-Definition von 1980 hat sich die IETF mit der bis heute weit verbreiteten Definition in ihrer Request For Comments 791 abgefunden. Dies ist die vierte Version des Protokolls, aber man könnte sagen, es ist die erste Produktionsversion.

Es verwendet 32-Bit-Adressen, was die Beschränkung der Anzahl der Adressen auf rund 4 Milliarden setzt. Diese Einschränkung ist die Erklärung für das Rätsel, warum Nicht-Geschäfts-Internetnutzer von ihren ISPs „dynamische IP-Adressen“ erhalten, und eine statische IP als „Mehrwert“ betrachtet und oft mit zusätzlichen Kosten verbunden wird.

Sie rationieren.

Es dauerte nicht lange, bis klar wurde, dass 32-Bit-Adressen nicht ausreichen, und Mangel drohte. Viele RFCs wurden veröffentlicht, die versuchten, damit umzugehen. Obwohl diese Lösungen heute weit verbreitet und Teil unseres täglichen Lebens sind, ist es wahrscheinlich sicher, dass es sich um Hacks handelt.

Internet Protocol Version 6 oder IPv6 kam als Möglichkeit, diese Einschränkungen zu beseitigen, auch wenn sie schrittweise über die vorherige Version übernommen werden sollten. Es wurde 1998 zum Entwurf eines Standarddokuments für die IETF gemacht und 2017 zu einem Internetstandard erhoben.

Während der IPv4-Adressraum durch seine 32-Bit-Adresslänge begrenzt war, erhielt der IPv6-Standard 128 Bit oder 3,4 * 10 ^ 38 mögliche Adressen. Das sollte ausreichen, um uns für eine ganze Weile zu halten.

Laut Google und IPv6-Konnektivität unter den Nutzern liegt die Akzeptanz von IPv6 im Juni 2021 bei etwas über 35%.

IP ist eine rudimentäre Schicht des Internet-Stacks, die die meisten grundlegenden Dinge definiert, ohne Garantien für die Lieferung, Datenintegrität oder die Reihenfolge der übertragenen Pakete. Allein ist es unzuverlässig. Das Headerformat von IPv4 sieht eine Header-Prüfsumme vor, mit der die Übertragungsknoten die Integrität des Headers überprüfen. Damit unterscheidet sie sich von der IPv6-Version, die auf die darunterliegende Verbindungsschicht angewiesen ist, was sie schneller macht….

Die Rolle von TCP und UDP verstehen

Jetzt ist es an der Zeit zu untersuchen, wo HTTP/3 zu TCP und UDP passt.

TCP

Während IP die Basisschicht unserer heutigen Online-Kommunikation ist, ist TCP (Transmission Control Protocol) ein übergeordneter Teil der Internet-Protokollsuite und bietet die Zuverlässigkeit, die für Web, Mail, File Transfer (FTP) – für Anwendungsschichten/Protokolle des Internets – erforderlich ist.

Dazu gehört der mehrstufige Verbindungsaufbau mit Handshakes, die sichere Reihenfolge der Pakete und die erneute Übertragung verlorener Pakete. Es gibt Rückmeldungen (Acks) über die Lieferung an den Absender und so weiter. Es gibt auch eine Prüfsummenberechnung, um Fehler zu erkennen.

All diese Dinge weisen auf viele Schritte hin, die TCP zu einem zuverlässigen Protokoll machen, was es zu einer Grundlage der berüchtigsten Internetdienste macht, die wir heute nutzen.

Die Spezifikation aus den Jahren 1974 (RFC 675) und 1981 (RFC 793) hat sich bis heute nicht wesentlich geändert.

Die Zuverlässigkeit, die TCP bietet, ist jedoch nicht ohne Kosten. Der Aufwand für alle Roundtrips, der durch Handshakes, Lieferrückmeldungen, Bestellgarantien und Prüfsummen erforderlich ist, wird als überflüssig und schlapp angesehen. Es hat TCP zu einem Engpass des modernen Protokollstacks gemacht. HTTP/2 hat ein Plateau von Geschwindigkeitsverbesserungen erreicht, die auf Basis von TCP erreicht werden können.

UDP

Das User Datagram Protocol (UDP) ist ebenfalls ein Teil der Internet Protocol Suite, dessen Spezifikation auf das Jahr 1980 zurückgeht (RFC 768).

Es ist, wie der Name schon sagt, ein datagrammbasiertes verbindungsloses Protokoll. Das bedeutet, dass es keine Händedrücke und keine Zusicherungen für Bestellung oder Lieferung gibt. Das bedeutet, dass alle möglichen Schritte zur Sicherstellung der Lieferung, Datenintegrität und anderer Dinge der Anwendungsschicht überlassen werden. Das bedeutet, dass eine Anwendung, die auf UDP aufbaut, je nach konkretem Fall Cherry-Pick-Strategien anwenden, oder dass sie möglicherweise Elemente der Verbindungsschicht, wie Prüfsummen, nutzen kann, um Overhead zu vermeiden.

Added: Da UDP genau wie TCP weit verbreitet ist, können Verbesserungen erreicht werden, ohne dass Firmware-Updates für eine Vielzahl von Geräten, die mit dem Internet verbunden sind, oder wesentliche Änderungen an den Betriebssystemen erforderlich sind.

Die Bereitstellung neuer Protokolle wird durch viele Firewalls, NATs, Router und andere Middle-Boxen behindert, die nur TCP oder UDP zulassen, die zwischen Benutzern und den Servern, die sie erreichen müssen, bereitgestellt werden. – HTTP/3 erklärt

Dieser Thread auf Hacker News kann uns helfen, die Gründe für den Aufbau der neuen HTTP-Version auf dem bestehenden Netzwerkstapel zu verstehen, anstatt sie neu zu erfinden (obwohl es mehr dazu gibt als das).

Die Spezifikation des UDP-Paketformats ist eher minimal, sein Header besteht aus dem Quellport, dem Zielport, der Länge, in Bytes, dem Paketkopf und den Paketdaten sowie der Prüfsumme. Checksumme kann verwendet werden, um die Datenintegrität sowohl für den Header als auch für den Datenteil des Pakets zu überprüfen.

Checksumme ist optional, wenn die zugrundeliegende Protokollschicht IPv4 ist, und obligatorisch bei IPv6. Bisher wurde UDP für Dinge wie die Uhrensynchronisation von Computersystemen verwendet (NTP), VoIP-Anwendungen, Video-Streaming, DNS-System und DHCP-Protokoll verwendet.

QUIC und HTTP/3

QUIC (Quick UDP Internet Connections) wurde erstmals 2012 von Google eingesetzt. Es definiert die Grenzen von Netzwerkschichten neu, indem es sich auf das untergeordnete UDP-Protokoll stützt, Handshakes, Zuverlässigkeitsfunktionen und Sicherheitsfunktionen im „User-Space“ neu definiert und so die Notwendigkeit eines Upgrades von Kernels internetweiter Systeme vermeidet.

Genau wie bei HTTP/2, einer Weiterentwicklung, die von Googles SPDY oder speedy angeführt wurde, wird HTTP/3 wieder auf diesen Erfolgen aufbauen.

Während HTTP/2 uns Multiplexing ermöglichte und das Head-of-Line-Blocking abschwächte, ist es durch TCP eingeschränkt. Sie können eine einzige TCP-Verbindung für mehrere Streams verwenden, die zusammen multigeplext werden, um Daten zu übertragen, aber wenn einer dieser Streams einen Paketverlust erleidet, wird die gesamte Verbindung (und alle ihre Streams) sozusagen als Geisel gehalten, bis TCP das in Ordnung bringt (das verlorene Paket erneut sendet).

Das bedeutet, dass alle Pakete, auch wenn sie bereits übertragen werden und warten, im Puffer des Zielknotens blockiert werden, bis das verlorene Paket erneut übertragen wird. Daniel Stenberg nennt dies in seinem Buch über http/3 einen „TCP-basierten Head of Line Block“. Er behauptet, dass die Benutzer mit 2% Paketverlust besser mit HTTP/1 auskommen werden, mit sechs Verbindungen, um dieses Risiko abzusichern.

QUIC ist dadurch nicht eingeschränkt. Mit QUIC, das auf dem verbindungslosen UDP-Protokoll aufbaut, trägt das Konzept der Verbindung nicht die Einschränkungen von TCP und Ausfälle eines Stroms müssen den Rest nicht beeinflussen.

Wie Lucas Pardue von Cloudflare es ausdrückte:

Mit einem Fokus auf UDP-Streams erreicht QUIC Multiplexing, ohne sich auf eine TCP-Verbindung konzentrieren zu müssen. QUIC baut seine Verbindung auf einer höheren Ebene als TCP auf. Neue Streams innerhalb von QUIC-Verbindungen sind nicht gezwungen, auf das Ende der anderen zu warten. QUIC-Verbindungen profitieren auch davon, dass der Overhead für TCP-Handshake wegfällt, was die Latenzzeit reduziert.

Die Leute von Cisco haben ein interessantes Video gemacht, das den 3-Wege-Handshake von TCP erklärt:

Added: https://www.youtube.com/watch?v=LyDqA-dAPW4

Während QUIC die TCP-Zuverlässigkeitsfunktionen abschafft, gleicht es sie oberhalb der UDP-Schicht aus, indem es die erneute Übertragung von Paketen, die Bestellung und so weiter ermöglicht. Die Google Cloud Platform führte 2018 die QUIC-Unterstützung für ihre Load Balancer ein und verzeichnete eine Verbesserung der durchschnittlichen Seitenladezeit um 8% weltweit und bis zu 13% in Regionen mit höherer Latenz.

Zwischen Google Chrome, YouTube, Gmail, Googles Suche und anderen Diensten konnte Google QUIC auf einem großen Teil des Internets einsetzen, ohne auf IETF zu warten. Die Ingenieure von Google behaupten, dass 2017 bereits 7% des Internetverkehrs über QUIC abgewickelt wurden.

Googles Version von QUIC konzentrierte sich auf den reinen HTTP-Transport unter Verwendung der HTTP/2-Syntax. Leute von der IETF (die für die Standardisierung von QUIC verantwortlich sind), beschlossen, dass die IETF-Version von QUIC in der Lage sein sollte, mehr als nur HTTP zu transportieren. Vorläufig ist jedoch jede Arbeit an Nicht-HTTP-Protokollen über QUIC auf Eis gelegt.

Eine weitere Entscheidung der IETF-Arbeitsgruppe ist, dass die standardisierte Version anstelle der benutzerdefinierten Lösung von Google die Verschlüsselung TLS 1.3 verwenden wird. TLS 1.3 trägt im Vergleich zu den älteren Versionen auch zur Protokollgeschwindigkeit bei, da seine Handshakes weniger Roundtrips erfordern. Kinsta unterstützt TLS 1.3 auf allen unseren Servern und unser Kinsta CDN.

Im Moment verwendet Google weiterhin eine eigene Version von QUIC in seinem Produkt und richtet seine Entwicklungsarbeit auf die IETF-Standards aus. Die meisten anderen Internet-Player bauen auf der IETF-Version auf (die beiden unterscheiden sich neben der Verschlüsselung in einigen anderen Aspekten).

Wenn wir Chrome Dev Tools öffnen und einige von Googles Produkten, wie Google Mail, in der Spalte Protokoll auf der Registerkarte Netzwerk laden, werden wir viele Ressourcen sehen, die über Googles Version des QUIC-Protokolls geladen werden. Dies gilt auch für die Produkte von Google wie Analytics, Google Tag Manager, etc.

Cloudflare hat kürzlich ein sehr umfangreiches Update über den Fortschritt der Standardisierung veröffentlicht.

Während UDP QUIC und HTTP/3 einige inhärente Vorteile bieten, bringt es auch einige Herausforderungen mit sich.

TCP ist seit Jahren das Mainstream-Protokoll, während UDP es nicht ist, so dass Betriebssysteme und der Software-Stack dafür im Allgemeinen nicht so optimiert sind. Folglich gibt es bei QUIC, nach einigen Schätzungen, viel höhere CPU-Last/-Anforderungen, doppelt so viel wie bei HTTP/2.

Optimierungen gehen tief in den Kern von Betriebssystemen und verschiedenen Routern und Geräte-Firmware ein. Dieser Red Hat Tuning-Leitfaden kann das Thema für diejenigen, die eher technisch orientiert sind, näher beleuchten.

Wir könnten sagen, dass QUIC versucht, TCP-Features auf Basis eines minimaleren und flexibleren Protokolls neu zu entwickeln.

QUIC-Verbindungen, die wir bereits erwähnt haben, kombinieren TLS und transportieren Handshakes. Einmal eingerichtet, werden sie durch eindeutige CIDs (Connection IDs) identifiziert. Diese IDs bleiben auch bei IP-Änderungen erhalten und können dazu beitragen, ununterbrochene Downloads zu sichern, z.B. bei einem Wechsel von 4G zu WiFi. Dies ist relevant, zumal immer mehr Internetverkehr auf mobilen Geräten abgewickelt wird. Es kann sich die Frage stellen, ob dieses Element von Google konzipiert wurde, um eine bessere Benutzerverfolgung über verschiedene Verbindungen und Internetanbieter hinweg zu ermöglichen.

TLS ist obligatorisch und soll es Geräten in der Mitte der Verbindungskette schwermachen, den Datenverkehr zu manipulieren oder zu schnüffeln. Deshalb ist es nicht selten, dass Firewall-Provider und Anbieter wie Cisco das UDP-Protokoll als Problem betrachten und Möglichkeiten zur Deaktivierung anbieten. Es ist für Zwischenhändler schwieriger, den QUIC-Verkehr zu inspizieren und zu überwachen oder zu filtern.

QUIC-Streams werden über QUIC-Verbindungen, unidirektional oder bidirektional gesendet. Streams haben IDs, die den Initiator identifizieren, und angeben ob der Stream uni- oder bidirektional ist, und dienen unter anderem auch der Durchflusskontrolle im Strom.

Während QUIC ein Transportschichtprotokoll ist, ist HTTP die darüber liegende Schicht, ein Anwendungsschichtprotokoll oder ein Anwendungsprotokoll.

Da Abwärtskompatibilität von größter Bedeutung ist, fordert die IETF, dass die Implementierung von HTTP/3 die alte Version (HTT1 oder HTTP/2) in die Antwort einbezieht. Es wird einen Header enthalten, der den Client darüber informiert, dass HTTP/3 verfügbar ist, zusammen mit Port-/Host-Informationen, wie in RFC 7838 beschrieben.

Dies unterscheidet sich von HTTP/2, bei dem der Transport innerhalb des TLS-Handshake ausgehandelt werden kann. Da IETF jedoch quasi QUIC-basiertes HTTP/3 als nächsten Standard übernommen hat, können wir erwarten, dass Webclients die HTTP/3-Unterstützung immer mehr erwarten. Es ist möglich, dass Clients Daten von früheren HTTP/3-Verbindungen zwischenspeichern und sich bei nachfolgenden Besuchen auf demselben Host direkt verbinden (Zero-Round-trip oder 0-RTT).

Zusammenfassung

Manche meinen, dass es angesichts der Tatsache, dass der HTTP/2-Standard noch nicht vollständig verabschiedet ist, noch zu früh ist, um HTTP/3 auf breiter Front zu propagieren. Das ist ein berechtigter Einwand, aber wie wir bereits erwähnt haben, wurde dieses Protokoll bereits in großem Umfang getestet und implementiert. Google begann bereits 2015 damit, es zu testen, ebenso wie Facebook im Jahr 2017.

Seit 2024 wird HTTP/3 von großen Browsern wie Google Chrome und Brave unterstützt. Auf der Infrastrukturseite haben Webserver wie Litespeed und Nginx bereits funktionierende Implementierungen von HTTP/3, während Netzwerkanbieter wie Cloudflare bereits vollständige Unterstützung für HTTP/3 bereitgestellt haben.

Zurzeit befindet sich HTTP/3 noch in der Internet Draft-Phase, und die letzte Revision läuft im August 2021 aus. Dieses Jahr wird spannend, denn wir können erwarten, dass die großen Softwareanbieter den neuen Standard implementieren werden.

Tonino Jankov

Tonino ist Unternehmer, Linux- und OSS-Enthusiast, Entwickler und Ausbilder im Bereich Technik. Er hat über zehn Jahre Erfahrung in der Entwicklung und ist seit über 3 Jahren im Blockchain-Bereich tätig. Wenn er nicht gerade programmiert, schreibt er für SitePoint und Alibaba Cloud, schaut sich die neuesten Romane auf Netflix an und entdeckt neue Reiseziele.

• Twitter