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 UDP auf und wird bereits von namhaften Internetunternehmen wie Google und Facebook genutzt. Wenn Du Chrome verwendest und Dich mit einem Google-Dienst verbindest, 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 Juni 2019 ausläuft, können wir erwarten, dass HTTP/3 als neuer HTTP-Standard der dritten Generation beworben wird.

Genau wie bei HTTP/2 wird HTTP/3 wieder auf neuen Errungenschaften aufbauen, um das Web zu beschleunigen. 🚀 Click to Tweet

HTTP/3 kommt

Einige sagen, dass der Hunger der Webindustrie nach mehr Geschwindigkeit und geringerer Latenz nur durch den Hunger von Google Chrome nach mehr RAM ausgeglichen wird.

Im Jahr 2016 haben wir einen Artikel über HTTP/2 veröffentlicht, einen Standard, der laut W3Techs derzeit eine weltweite Akzeptanzrate von rund 34% aufweist. Und laut Can I use wird es auch von allen modernen Webbrowsern unterstützt. Doch jetzt sind wir hier und schreiben einen Artikel über die nächste Version des Protokolls, HTTP/3.

HTTP/2 Gebrauch

HTTP/2 Gebrauch

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 ID-Phase von HTTP/3 die letzte Phase, bevor Vorschläge auf die Ebene von RFC-s oder Request-for-Comments befördert werden, die wir im Grunde genommen als offizielle Internet-Protokolldefinitionen betrachten können. Dann werden sie von allen großen Internet-Playern umgesetzt.

Das bedeutet, dass HTTP/3 nach Ablauf des Entwurfs im Laufe dieses Jahres (Juni 2019) zu einer offiziellen Norm werden soll.

Ein wenig Hintergrund – es begann mit HTTP/2

Bei Kinsta sind wir besessen davon, so viel rauszuholen wie nur möglich, sei es durch die Nutzung der neuesten Version von PHP, die Bereitstellung von Daten über das Premium-Tier-Netzwerk der Google Cloud Platform oder das Caching von Assets auf unserem HTTP/2-CDN.

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.

HTTP/2 push

HTTP/2 Push

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.

Kein pipelining vs pipelining

Kein Pipelining vs. Pipelining (Bildquelle: Wikipedia, Author Mwhitlock)

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.

HTTP/2 HPACK Kompression

HTTP/2 HPACK Kompression

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.

Darunter befindet sich die Verbindungsschicht – der Teil des Protokolls, der sozusagen „blankes Metall“ ist.

Ein überzeugendes Argument für eine vollständige Überarbeitung zeigt sich übrigens an der Geschwindigkeit, mit der es den Machern von IPFS (Interplanetares Dateisystem) gelungen ist, eine ICO-Finanzierung abzuschließen, die ihnen innerhalb eines Monats 250 Millionen US-Dollar einbrachte.

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.

Internet Protokoll (RFC791)

Internet Protokoll (Bildquelle: RFC791)

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 März 2019 bei etwas über 25%.

IPv6-Einführung

IPv6-Einführung

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….

Internet Datagram Header

Internet Datagram Header (Quellbild: RFC791)

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.

Das Ändern des TCP in irgendeiner wesentlichen Weise ist kein einfaches Unterfangen, denn das Protokoll ist als Teil des TCP/IP-Stacks, der bis in die 70er Jahre zurückreicht. Es ist tief in Betriebssysteme, Geräte-Firmware usw. eingebettet.

UDP

deren Spezifikation aus dem Jahr 1980 stammt (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.

Da UDP genauso weit verbreitet ist wie TCP, ermöglicht es Verbesserungen, ohne dass ein breiter Wechsel der Firmware auf allen mit dem Internet verbundenen Geräten oder erhebliche Änderungen in 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.

HTTP/2 Stapel vs HTTP/3 Stapel

HTTP/2 Stapel vs HTTP/3 Stapel

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:

Lucas Pardue über HTTP/3

Lucas Pardue über HTTP/3

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 gedreht, das TCP’s 3-Wege-Handshake erklärt.

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.

Google Dienst QUIC

Google Dienst QUIC

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

Es gibt diejenigen, die der Meinung sind, dass es angesichts der noch nicht vollständigen Übernahme des HTTP/2-Standards zu früh sein könnte, um auf HTTP/3 (Version drei) zu setzen. Das ist ein berechtigter Punkt, aber wie wir bereits erwähnt haben, hat dieses Protokoll bereits umfangreiche Tests und Implementierungen erfahren. Google begann bereits 2015 mit dem Testen, ebenso wie Facebook im Jahr 2017.

Seitdem haben sich weitere Akteure wie Akamai und Mozilla den Standardisierungsbemühungen angeschlossen. Beim letzten IETF-Hackathon im November 2018 zeigte die Teilnehmerliste Interesse an QUIC von Unternehmen wie Facebook, Apple, Google, Mozilla, NetApp und LiteSpeed Tech. Es gab einige vielversprechende Tests, und es sieht so aus, als ob LiteSpeed der erste große Serveranbieter mit einem funktionierenden HTTP/3-Server sein könnte. Cloudflare lässt derzeit auch QUIC in der Beta-Version laufen.

Kurz darauf wurde QUIC im Internet-Entwurf der IETF in HTTP/3 umbenannt. Sie läuft Ende Juni 2019 aus, und wir können mit dem RFC oder dem endgültigen Standard irgendwann im Juli rechnen.

Dieses Jahr wird es spannend, da wir erwarten können, dass die großen Softwareanbieter den neuen Standard umsetzen werden.

Wann wird HTTP/3 bei Kinsta verfügbar sein?

Wir verwenden Nginx bei Kinsta und müssen daher warten, bis sie QUIC offiziell unterstützen. Derzeit wird daran gearbeitet und für einen Teil des Nginx 1.17-Zweiges geplant. Sobald dies veröffentlicht ist, kannst du sicher sein, dass das Kinsta-Team nach zusätzlicher Unterstützung auf unserer Plattform suchen wird.

28
Mal geteilt