Da wir bei neuen Technologien immer auf dem neuesten Stand sind, haben wir daf\u00fcr gesorgt, dass die gesamte Kinsta-Webseite und der Admin auf HTTP\/2 l\u00e4uft, und unsere neue Google Cloud-Infrastruktur unterst\u00fctzt<\/a> HTTP\/2 f\u00fcr alle unsere Kunden. Diese umfangreiche Informationsquelle erkl\u00e4rt HTTP\/2 f\u00fcr Endbenutzer, Entwickler und Unternehmen, die Innovationen verfolgen. Von grundlegenden Informationen bis hin zu fortgeschritteneren Themen erf\u00e4hrt man hier alles, was man \u00fcber HTTP\/2 wissen muss.<\/p>\n HTTP<\/a> wurde urspr\u00fcnglich von Tim Berners-Lee<\/a> vorgeschlagen, dem Pionier des World Wide Web, der das Anwendungsprotokoll mit Blick auf Einfachheit entworfen hat, um Datenkommunikationsfunktionen auf hoher Ebene zwischen Web-Servern und Clients durchzuf\u00fchren.<\/p>\n Die erste dokumentierte Version von HTTP wurde 1991 als HTTP0.9 ver\u00f6ffentlicht, was sp\u00e4ter zur offiziellen Einf\u00fchrung und Anerkennung von HTTP1.0 im Jahr 1996 f\u00fchrte. HTTP1.1 folgte 1997 und hat seitdem nur wenige iterative Verbesserungen erhalten.<\/p>\n Im Februar 2015 \u00fcberarbeitete die HTTP-Arbeitsgruppe der Internet Engineering Task Force (IETF<\/a>) HTTP und entwickelte die zweite Hauptversion des Anwendungsprotokolls in Form von HTTP\/2. Im Mai 2015 wurde die HTTP\/2-Implementierungsspezifikation als Antwort auf das HTTP-kompatible SPDY<\/a>-Protokoll von Google offiziell standardisiert. Das Argument HTTP\/2 vs. SPDY zieht sich durch den gesamten Leitfaden.<\/p>\n Die Debatte HTTP\/2 vs. HTTP1 muss mit einer kurzen Einf\u00fchrung in den in dieser Ressource h\u00e4ufig verwendeten Begriff Protokoll fortgesetzt werden. Ein Protokoll ist eine Reihe von Regeln, die die Mechanismen der Datenkommunikation zwischen Clients (z.B. Webbrowser, die von Internetbenutzern zur Anforderung von Informationen verwendet werden) und Servern (die Rechner, die die angeforderten Informationen enthalten) regeln.<\/p>\n Protokolle bestehen in der Regel aus drei Hauptteilen: Header, Payload und Footer. Die Kopfzeile, die vor der Nutzlast platziert wird, enth\u00e4lt Informationen wie Quell- und Zieladresse sowie weitere Details (wie Gr\u00f6\u00dfe und Typ) zur Nutzlast. Die Payload ist die eigentliche Information, die mit Hilfe des Protokolls \u00fcbertragen wird. Die Fu\u00dfzeile folgt der Payload und dient als Kontrollfeld, um Client-Server-Anfragen zusammen mit dem Header an die vorgesehenen Empf\u00e4nger zu leiten, um sicherzustellen, dass die Payload-Daten fehlerfrei \u00fcbertragen werden.<\/p>\n Das System ist \u00e4hnlich wie der Postversand. Der Brief (Payload) wird vor dem Versand in einen Umschlag (Header) mit aufgedruckter Zieladresse gesteckt und mit Kleber und Briefmarke (Footer) verschlossen. Die \u00dcbertragung digitaler Informationen in Form von 0 und 1 ist jedoch nicht so einfach und erfordert eine Innovation in einer neuen Dimension als Antwort auf die zunehmenden technologischen Fortschritte, die mit der explosionsartigen Zunahme der Internetnutzung einhergehen.<\/p>\n Das HTTP-Protokoll bestand urspr\u00fcnglich aus Grundbefehlen: GET, um Informationen vom Server abzurufen, und POST, um die angeforderten Informationen an den Client zu liefern. Dieser einfache und scheinbar langweilige Satz von wenigen Befehlen f\u00fcr GET-Daten und POST-Antwort bildete im Wesentlichen die Grundlage, um auch andere Netzwerkprotokolle zu konstruieren. Das Protokoll ist ein weiterer Schritt zur Verbesserung der Benutzerfreundlichkeit und Effektivit\u00e4t des Internets, der eine HTTP\/2-Implementierung zur Verbesserung der Online-Pr\u00e4senz erforderlich macht.<\/p>\n Seit seiner Einf\u00fchrung in den fr\u00fchen 1990er Jahren hat HTTP nur wenige gr\u00f6\u00dfere \u00dcberarbeitungen erfahren. Die j\u00fcngste Version, HTTP1.1, dient der Cyberwelt seit \u00fcber 15 Jahren. Webseiten in der heutigen \u00c4ra dynamischer Informationsaktualisierungen, ressourcenintensiver Multimedia-Inhaltsformate und einer \u00fcberm\u00e4\u00dfigen Neigung zur Web-Performance haben alte Protokolltechnologien in die Kategorie der Altlasten fallen lassen. Diese Trends erfordern bedeutende HTTP\/2-\u00c4nderungen, um die Internet-Erfahrung zu verbessern.<\/p>\n Das prim\u00e4re Ziel bei der Forschung und Entwicklung f\u00fcr eine neue Version von HTTP konzentriert sich auf drei Qualit\u00e4ten, die selten mit einem einzigen Netzwerkprotokoll in Verbindung gebracht werden, ohne dass zus\u00e4tzliche Netzwerktechnologien erforderlich sind: Einfachheit, hohe Leistung und Robustheit. Diese Ziele werden durch die Einf\u00fchrung von F\u00e4higkeiten erreicht, die die Latenz bei der Verarbeitung von Browser-Anfragen mit Techniken wie Multiplexing, Komprimierung, Anfragepriorisierung und Server-Push reduzieren.<\/p>\n Mechanismen wie Flusskontrolle, Upgrade und Fehlerbehandlung funktionieren als Erweiterungen des HTTP-Protokolls f\u00fcr Entwickler, um eine hohe Leistung und Belastbarkeit webbasierter Anwendungen zu gew\u00e4hrleisten.<\/p>\n Das kollektive System erm\u00f6glicht es den Servern, effizient mit mehr Inhalten zu antworten, als urspr\u00fcnglich von den Clients angefordert wurden, so dass der Benutzer nicht mehr st\u00e4ndig Informationen anfordern muss, bis die Webseite vollst\u00e4ndig im Webbrowser geladen ist. Beispielsweise erm\u00f6glicht die Server-Push-F\u00e4higkeit mit HTTP\/2 den Servern, mit dem vollst\u00e4ndigen Inhalt einer Seite zu antworten, die nicht bereits im Cache des Browsers vorhanden ist. Die effiziente Komprimierung von HTTP-Header-Dateien minimiert den Protokoll-Overhead, um die Leistung bei jeder Browser-Anfrage und Server-Antwort zu verbessern.<\/p>\n HTTP\/2-\u00c4nderungen sind so konzipiert, dass die Interoperabilit\u00e4t und Kompatibilit\u00e4t mit HTTP 1.1 erhalten bleibt. Es wird erwartet, dass die Vorteile von HTTP\/2 im Laufe der Zeit auf der Grundlage von Experimenten in der realen Welt zunehmen werden, und seine F\u00e4higkeit, leistungsbezogene Probleme im Vergleich zu HTTP1.1 in der realen Welt zu l\u00f6sen, wird seine Entwicklung langfristig stark beeinflussen.<\/p>\n „…wir ersetzen nicht das gesamte HTTP – die Methoden, Statuscodes und die meisten der Header, die Sie heute verwenden, werden die gleichen sein. Stattdessen definieren wir neu, wie es „on the wire“ verwendet wird, damit es effizienter und schonender f\u00fcr das Internet selbst ist…“. Mark Nottingham<\/a>, Vorsitzender der IETF-HTTP-Arbeitsgruppe und Mitglied der W3C-TAG.\u00a0 Quelle<\/a><\/p><\/blockquote>\n Es ist wichtig zu beachten, dass die neue HTTP-Version als eine Erweiterung des Vorg\u00e4ngers kommt und HTTP1.1 voraussichtlich nicht in naher Zukunft ersetzen wird. Die HTTP\/2-Implementierung wird nicht die automatische Unterst\u00fctzung aller mit HTTP1.1 verf\u00fcgbaren Verschl\u00fcsselungstypen erm\u00f6glichen, \u00f6ffnet aber definitiv die T\u00fcr f\u00fcr bessere Alternativen oder zus\u00e4tzliche Aktualisierungen der Verschl\u00fcsselungskompatibilit\u00e4t in naher Zukunft. Funktionsvergleiche wie HTTP\/2 vs. HTTP1 und SPDY vs. HTTP\/2 zeigen jedoch nur das neueste Anwendungsprotokoll als Sieger in Bezug auf Leistung, Sicherheit und Zuverl\u00e4ssigkeit gleicherma\u00dfen.<\/p>\n HTTP1.1 war auf die Verarbeitung nur einer ausstehenden Anfrage pro TCP-Verbindung beschr\u00e4nkt, wodurch die Browser gezwungen waren, mehrere TCP-Verbindungen zu verwenden, um mehrere Anfragen gleichzeitig zu verarbeiten.<\/p>\n Die parallele Verwendung von zu vielen TCP-Verbindungen f\u00fchrt jedoch zu einer TCP-\u00dcberlastung, die zu einer unfairen Monopolisierung von Netzwerkressourcen f\u00fchrt. Web-Browser, die mehrere Verbindungen zur Verarbeitung zus\u00e4tzlicher Anforderungen verwenden, belegen einen gr\u00f6\u00dferen Anteil der verf\u00fcgbaren Netzwerkressourcen, wodurch die Netzwerkleistung f\u00fcr andere Benutzer herabgesetzt wird.<\/p>\n Die Ausgabe mehrerer Anfragen vom Browser aus f\u00fchrt auch zu einer Datenverdoppelung auf den Daten\u00fcbertragungsleitungen, was wiederum zus\u00e4tzliche Protokolle erfordert, um die gew\u00fcnschten Informationen an den Endknoten fehlerfrei zu extrahieren.<\/p>\n Die Internetbranche war nat\u00fcrlich gezwungen, diese Einschr\u00e4nkungen mit Praktiken wie Domain-Sharing, Verkettung, Daten-Inlining und Spriting, unter anderem, zu hacken. Die ineffektive Nutzung der zugrundeliegenden TCP-Verbindungen mit HTTP1.1 f\u00fchrt auch zu einer schlechten Priorisierung der Ressourcen, was zu einer exponentiellen Verschlechterung der Leistung f\u00fchrt, wenn Web-Anwendungen in Bezug auf Komplexit\u00e4t, Funktionalit\u00e4t und Umfang wachsen.<\/p>\n Das Web hat sich weit \u00fcber die Kapazit\u00e4t der veralteten HTTP-basierten Netzwerktechnologien hinaus entwickelt. Die vor \u00fcber einem Jahrzehnt entwickelten Kernqualit\u00e4ten von HTTP1.1 haben die T\u00fcren zu mehreren peinlichen Leistungs- und Sicherheitsl\u00fccken ge\u00f6ffnet.<\/p>\n Der Cookie-Hack zum Beispiel erm\u00f6glicht es Cyberkriminellen, eine fr\u00fchere Arbeitssitzung wiederzuverwenden, um Kontopassw\u00f6rter zu kompromittieren, da HTTP1.1 keine M\u00f6glichkeiten zur Identifizierung von Sitzungsendpunkten bietet. W\u00e4hrend die \u00e4hnlichen Sicherheitsbedenken HTTP\/2 weiterhin verfolgen werden, ist das neue Anwendungsprotokoll mit besseren Sicherheitsfunktionen ausgestattet, wie z.B. der verbesserten Implementierung neuer TLS-Funktionen<\/a>.<\/p>\n Bidirektionale Sequenzen von Textformatrahmen, die \u00fcber das HTTP\/2-Protokoll gesendet und zwischen Server und Client ausgetauscht werden, werden als „Streams“ bezeichnet. Fr\u00fchere Iterationen des HTTP-Protokolls waren in der Lage, jeweils nur einen Stream mit einer gewissen Zeitverz\u00f6gerung zwischen den einzelnen Stream-\u00dcbertragungen zu \u00fcbertragen.<\/p>\n Der Empfang von Tonnen von Medieninhalten \u00fcber einzelne Streams, die einer nach dem anderen gesendet werden, ist sowohl ineffizient als auch ressourcenintensiv. Die HTTP\/2-\u00c4nderungen haben dazu beigetragen, eine neue bin\u00e4re Framing-Schicht zu etablieren, die diesen Bedenken Rechnung tr\u00e4gt.<\/p>\n Diese Schicht erm\u00f6glicht es Client und Server, die HTTP-Nutzlast in kleine, unabh\u00e4ngige und handhabbare verschachtelte Sequenzen von Frames zu zerlegen. Diese Informationen werden dann am anderen Ende wieder zusammengef\u00fcgt.<\/p>\n Bin\u00e4re Frame-Formate erm\u00f6glichen den Austausch mehrerer, gleichzeitig offener, unabh\u00e4ngiger bidirektionaler Sequenzen ohne Latenz zwischen aufeinanderfolgenden Streams. Dieser Ansatz bietet eine Reihe von Vorteilen von HTTP\/2, die im Folgenden erl\u00e4utert werden:<\/p>\n Mit dieser F\u00e4higkeit werden Datenpakete aus mehreren Str\u00f6men im Wesentlichen gemischt und \u00fcber eine einzige TCP-Verbindung \u00fcbertragen. Diese Pakete werden dann auf der Empfangsseite aufgeteilt und als einzelne Datenstr\u00f6me dargestellt. F\u00fcr die gleichzeitige \u00dcbertragung mehrerer paralleler Anfragen \u00fcber HTTP Version 1.1 oder fr\u00fcher waren mehrere TCP-Verbindungen erforderlich, die trotz der \u00dcbertragung von mehr Datenstr\u00f6men mit h\u00f6heren Geschwindigkeiten naturgem\u00e4\u00df zu Engp\u00e4ssen in der Gesamtnetzwerkleistung f\u00fchren.<\/p>\n\n Diese F\u00e4higkeit erm\u00f6glicht es dem Server, zus\u00e4tzliche zwischenspeicherbare Informationen an den Client zu senden, die nicht angefordert werden, aber bei zuk\u00fcnftigen Anfragen erwartet werden. Wenn der Client z.B. die Ressource X anfordert und davon ausgegangen wird, dass die Ressource Y mit der angeforderten Datei referenziert ist, kann der Server w\u00e4hlen, Y zusammen mit X zu pushen, anstatt auf eine entsprechende Client-Anforderung zu warten.<\/p>\n Der Client legt die gepushte Ressource Y zur sp\u00e4teren Verwendung in seinen Cache. Dieser Mechanismus erspart einen Request-Antwort-Roundtrip und reduziert die Netzwerklatenz. Server-Push wurde urspr\u00fcnglich im SPDY-Protokoll von Google eingef\u00fchrt. Stream-Kennungen, die Pseudo-Kopfzeilen wie :path enthalten, erm\u00f6glichen es dem Server, den Push f\u00fcr Informationen zu initiieren, die im Cache gespeichert werden m\u00fcssen. Der Client muss dem Server ausdr\u00fccklich erlauben, cachespeicherbare Ressourcen mit HTTP\/2 zu pushen oder gepushte Streams mit einer bestimmten Stream-Kennung zu beenden.<\/p>\n Andere HTTP\/2-\u00c4nderungen wie Server-Push aktualisieren oder invalidieren proaktiv den Cache des Clients und werden auch als „Cache-Push“ bezeichnet. Langfristige Konsequenzen drehen sich um die F\u00e4higkeit von Servern, m\u00f6gliche Push-f\u00e4hige Ressourcen zu identifizieren, die der Client eigentlich nicht will.<\/p>\n Die HTTP\/2-Implementierung bietet eine betr\u00e4chtliche Leistung f\u00fcr Push-Ressourcen, wobei weitere Vorteile von HTTP\/2 im Folgenden erl\u00e4utert werden:<\/p>\n \u00c4hnliche Push-F\u00e4higkeiten sind bereits mit suboptimalen Techniken wie Inline-to-Push-Server-Antworten verf\u00fcgbar, wohingegen Server-Push eine L\u00f6sung auf Protokollebene darstellt, um Komplexit\u00e4ten mit Optimierungs-Hacks zu vermeiden, die den Basisf\u00e4higkeiten des Anwendungsprotokolls selbst untergeordnet sind.<\/p>\n HTTP\/2 multiplext und priorisiert den gepushten Datenstrom, um eine bessere \u00dcbertragungsleistung wie bei anderen Anfrage-Antwort-Datenstr\u00f6men zu gew\u00e4hrleisten. Als eingebauter Sicherheitsmechanismus muss der Server zuvor autorisiert werden, die Ressourcen zu pushen.<\/p>\n Die neueste HTTP-Version hat sich in Bezug auf F\u00e4higkeiten und Attribute wie die Umwandlung von einem Textprotokoll in ein Bin\u00e4rprotokoll erheblich weiterentwickelt. HTTP1.x wurde zur Verarbeitung von Textbefehlen verwendet, um Anfrage-Antwort-Zyklen abzuschlie\u00dfen. HTTP\/2 verwendet bin\u00e4re Befehle (in 1s und 0s), um die gleichen Aufgaben auszuf\u00fchren. Dieses Attribut erleichtert Komplikationen beim Framing und vereinfacht die Implementierung von Befehlen, die aufgrund von Befehlen, die Text und optionale Leerzeichen enthalten, verwirrend vermischt wurden.<\/p>\n Obwohl das Lesen von bin\u00e4ren Befehlen im Vergleich zu Textbefehlen wahrscheinlich mehr Aufwand erfordert, ist es f\u00fcr das Netzwerk einfacher, bin\u00e4r verf\u00fcgbare Frames zu generieren und zu parsen. Die eigentliche Semantik bleibt unver\u00e4ndert.<\/p>\n Browser, die eine HTTP\/2-Implementierung verwenden, konvertieren dieselben Textbefehle in Bin\u00e4rform, bevor sie \u00fcber das Netzwerk \u00fcbertragen werden. Die bin\u00e4re Framing-Schicht ist nicht abw\u00e4rtskompatibel mit HTTP1.x-Clients und -Servern und ein Schl\u00fcsselfaktor f\u00fcr die Erzielung erheblicher Leistungsvorteile gegen\u00fcber SPDY und HTTP1.x. Die Verwendung bin\u00e4rer Befehle zur Erm\u00f6glichung wichtiger Gesch\u00e4ftsvorteile f\u00fcr Internetfirmen und Online-Gesch\u00e4fte wird im Folgenden mit den Vorteilen von HTTP\/2 erl\u00e4utert:<\/p>\n Die HTTP\/2-Implementierung erm\u00f6glicht es dem Client, bestimmte Datenstr\u00f6me zu bevorzugen. Obwohl der Server nicht verpflichtet ist, diesen Anweisungen des Clients zu folgen, erlaubt der Mechanismus dem Server, die Zuweisung von Netzwerkressourcen auf der Grundlage der Anforderungen der Endbenutzer zu optimieren.<\/p>\n \u00a0<\/p>\n Die Stream-Priorisierung arbeitet mit Abh\u00e4ngigkeiten und Gewichten, die jedem Stream zugeordnet sind. Obwohl alle Streams inh\u00e4rent voneinander abh\u00e4ngig sind, werden auch den abh\u00e4ngigen Streams Gewichte zwischen 1 und 256 zugewiesen. Die Details f\u00fcr die Mechanismen der Stream-Priorisierung werden noch diskutiert.<\/p>\n In der realen Welt hat der Server jedoch selten die Kontrolle \u00fcber Ressourcen wie CPU und Datenbankverbindungen. Die Komplexit\u00e4t der Implementierung selbst hindert die Server daran, Stream-Priorit\u00e4tsanforderungen zu ber\u00fccksichtigen. Forschung und Entwicklung in diesem Bereich ist f\u00fcr den langfristigen Erfolg von HTTP\/2 besonders wichtig, da das Protokoll in der Lage ist, mehrere Datenstr\u00f6me mit einer einzigen TCP-Verbindung zu verarbeiten.<\/p>\n Diese F\u00e4higkeit kann zum gleichzeitigen Eintreffen von Server-Anforderungen f\u00fchren, die sich aus der Sicht des Endbenutzers tats\u00e4chlich in ihrer Priorit\u00e4t unterscheiden. Das Zur\u00fcckhalten von Datenstromverarbeitungsanforderungen auf zuf\u00e4lliger Basis untergr\u00e4bt die Effizienz und das Endbenutzererlebnis, die durch HTTP\/2-\u00c4nderungen versprochen werden. Gleichzeitig bietet ein intelligenter und weit verbreiteter Mechanismus zur Priorisierung von Datenstr\u00f6men Vorteile von HTTP\/2, die im Folgenden erl\u00e4utert werden:<\/p>\n Die Bereitstellung eines hochwertigen Web-Benutzererlebnisses erfordert Webseiten, die viele Inhalte und Grafiken enthalten. Das HTTP-Anwendungsprotokoll ist zustandslos, was bedeutet, dass jede Client-Anfrage so viele Informationen enthalten muss, wie der Server ben\u00f6tigt, um die gew\u00fcnschte Operation auszuf\u00fchren. Dieser Mechanismus bewirkt, dass die Datenstr\u00f6me mehrere sich wiederholende Informationsframes tragen, so dass der Server selbst keine Informationen aus fr\u00fcheren Client-Anfragen speichern muss.<\/p>\n Im Falle von Webseiten, die medienreiche Inhalte anbieten, schieben Clients mehrere nahezu identische Header-Frames, was zu Latenzzeiten und unn\u00f6tigem Verbrauch der begrenzten Netzwerkressourcen f\u00fchrt. Eine priorisierte Mischung von Datenstr\u00f6men kann die gew\u00fcnschten Leistungsstandards der Parallelit\u00e4t nicht erreichen, ohne diesen Mechanismus zu optimieren.<\/p>\n \u00a0<\/p>\n Die HTTP\/2-Implementierung begegnet diesen Bedenken mit der M\u00f6glichkeit, eine gro\u00dfe Anzahl von redundanten Header-Frames zu komprimieren. Sie verwendet die HPACK-Spezifikation als einen einfachen und sicheren Ansatz zur Header-Komprimierung. Sowohl Client als auch Server f\u00fchren eine Liste von Headern, die in fr\u00fcheren Client-Server-Anfragen verwendet wurden.<\/p>\n HPACK komprimiert den individuellen Wert jedes Headers, bevor er an den Server \u00fcbertragen wird, der dann die kodierten Informationen in der Liste der zuvor \u00fcbertragenen Header-Werte nachschl\u00e4gt, um die vollst\u00e4ndigen Header-Informationen zu rekonstruieren. Die HPACK-Header-Komprimierung f\u00fcr die HTTP\/2-Implementierung bietet immense Leistungsvorteile, einschlie\u00dflich einiger Vorteile von HTTP\/2, die im Folgenden erl\u00e4utert werden:<\/p>\n Die zugrundeliegende Anwendungssemantik von HTTP, einschlie\u00dflich HTTP-Statuscodes, URIs, Methoden und Header-Dateien, bleibt in der neuesten Iteration von HTTP\/2 unver\u00e4ndert. HTTP\/2 basiert auf SPDY, Googles Alternative zu HTTP1.x. Die wirklichen Unterschiede liegen in den Mechanismen, die zur Verarbeitung von Client-Server-Anfragen verwendet werden. Das folgende Diagramm zeigt einige Bereiche mit \u00c4hnlichkeiten und Verbesserungen zwischen HTTP1.x, SPDY und HTTP\/2 auf:<\/p>\nDieser Leitfaden beleuchtet die folgenden Schl\u00fcsselaspekte von HTTP\/2:<\/h3>\n
\n
<\/a>Was ist HTTP\/2?<\/h2>\n
![\"HTTP-Zeitleiste\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http-zeitleiste.png\")
Was ist ein Protokoll?<\/h3>\n
![\"E-Mail](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/e-mail-http2.png\")
<\/a>Ziel der Erstellung von HTTP\/2<\/h2>\n
![\"Internet-Erfahrung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/internet-erfahrung.png\")
![\"Sicherheitsverschl\u00fcsselung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/sicherheitsverschlusselung.png\")
<\/a>Was war falsch an HTTP 1.1?<\/h2>\n
![\"HTTP-Anfragen\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http-anfragen.png\")
![\"Domain-Sharing\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/domain-sharing.png\")
<\/a>HTTP\/2-Feature-Upgrades<\/h2>\n
Multiplex-Streams<\/h3>\n
![\"HTTP\/2-Streams\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-streams.png\")
\n
HTTP\/2-Server-Push<\/h3>\n
![\"Push](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-push.png\")
\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-autoziert.png\")
Bin\u00e4re Protokolle<\/h3>\n
![\"Bin\u00e4re](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/binare-protokolle.png\")
\n
Stream-Priorisierung<\/h3>\n
![\"HTTP\/2-Gewicht\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-gewicht.png\")
\n
![\"Laden](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/laden-von-http2-seiten.png\")
Stateful-Header-Komprimierung<\/h3>\n
![\"HTTP\/2-HPACK-Komprimierung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http-2-hpack-komprimierung.png\")
\n
<\/a>\u00c4hnlichkeiten mit HTTP1.x und SPDY<\/h2>\n
![\"HTTP\/2](\"https:\/\/kinsta.com\/wp-content\/uploads\/2016\/04\/http2-https.png\")
![\"HTTP\/2-Verschl\u00fcsselung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-verschlusselung.png\")
![\"Internet-Geschwindigkeit\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/internet-geschwindigkeit.jpg\")
![\"HTTP\/2-Leistungsverbesserungen\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-leistungsverbesserungen.jpg\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2_mobile.png\")
![\"Internet-Preissenkung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/internet-preissenkung.png\")
![\"Bandbreitenkarte\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/bandbreitenkarte.png\")
![\"Mobile-first\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/mobile-first.png\")
![\"HTTP\/2-Sicherheit\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-sicherheit.png\")
![\"HTTP\/2-SEO-Vorteile\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-seo-vorteile.png\")
![\"HTTP\/2-Leistungsdiagramm-Vergleich\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-vergleich.png\")
![\"HTTP\/2-Browser-Unterst\u00fctzung\"](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-browser-unterstutzung.png\")
![\"HTTP\/2](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/http2-nginx-apache-unterstutzung.png\")
![\"Let's](\"https:\/\/kinsta.com\/de\/wp-content\/uploads\/sites\/5\/2020\/04\/lets-encrypt-zertifikat-hinzufugen.png\")