HTTP/2-Optimierung: Server Push

Die Analyse beginnt mit der Erläuterung der Einschränkungen des HTTP/1.1 Protokolls im Hinblick auf die Webseiten-Performance. Ein zentrales Problem ist das 'Head-of-Line Blocking'. Da HTTP/1.1 Ressourcen über eine einzige TCP-Verbindung nacheinander liefert, muss jeder Request vollständig abgeschlossen sein, bevor der nächste gesendet wird. Dies führt zu erheblichen Verzögerungen, insbesondere wenn ein Request länger dauert. Auch die Funktion 'HTTP Pipelining', welche mehrere Requests gleichzeitig senden soll, löst dieses Problem nicht vollständig, da Responses immer noch sequenziell, also nacheinander, ausgeliefert werden. Die Verzögerung wird zusätzlich durch das erneute Senden verlorener TCP-Pakete verstärkt, was die Gesamtladezeit effektiv verdoppeln kann. Grigorik (2013, 194-195) beschreibt dieses Szenario detailliert. Die Konsequenz ist eine suboptimale Auslieferung von Webseitenressourcen, was sich direkt auf die wahrgenommene Ladegeschwindigkeit auswirkt.

Um die Performance-Probleme von HTTP/1.1 zu mildern, wurden verschiedene Optimierungstechniken entwickelt. Eine wichtige Strategie ist die Nutzung mehrerer paralleler TCP-Verbindungen. Sowohl Client als auch Server unterstützen dies, um die Ladezeiten zu verkürzen. In Standardkonfigurationen sind bis zu sechs parallele Verbindungen pro Hostname möglich (Grigorik 2013, 196). Ein weiterer Ansatz ist die Zusammenfassung von Ressourcen. Hierbei werden mehrere kleine Dateien, wie beispielsweise Bilder (Spriting), zu einer größeren Datei kombiniert. Dies reduziert die Anzahl der Requests und damit die Übertragungszeit. Die Funktion 'Keepalive Connections', eingeführt in HTTP/1.1, verbessert die Performance gegenüber HTTP/1.0 durch das Wiederverwenden von TCP-Verbindungen. Jedoch erfordert die Spriting-Technik zusätzlichen Aufwand bei der Entwicklung, da die kombinierten Bilder im CSS wieder künstlich aufgeteilt werden müssen (Grigorik 2013, 202). Die Reduktion der Anzahl an Requests wird als die beste Optimierungsstrategie hervorgehoben, unabhängig von der HTTP-Version.

Der Text betont die Rolle des TCP-Protokolls und dessen Einfluss auf die Ladezeit. Die 'Slow Start'-Funktion des TCP-Protokolls und der 'cwnd'-Algorithmus steuern die Flusskontrolle (Flow Control) innerhalb einer TCP-Verbindung. Dabei wird die Fenstergröße ('cwnd') dynamisch angepasst, abhängig vom Erfolg oder Misserfolg der Datenübertragung. Verlorene Pakete führen zu einer Reduktion von 'cwnd', was die Übertragungsrate drosselt. Umgekehrt verdoppelt sich 'cwnd' bei erfolgreichem Empfang aller Pakete pro Round-Trip Time (RTT). Das 'Window'-Feld im TCP-Header ist entscheidend für die Flusskontrolle, indem es die Anzahl der empfangsbereiten Bytes angibt. Das TCP-Protokoll arbeitet nach dem 'Sliding Window'-Prinzip mit variabler Größe, um Warteschlangen beim Empfänger zu vermeiden (Holtkamp 2001). Der Text verdeutlicht, dass kleinere Ressourcen schneller übertragen werden und somit die Ladezeit positiv beeinflussen (Grigorik 2013, 19, 20, 34).

Die Wahl des richtigen Bildformats und die entsprechende Komprimierung spielen eine wichtige Rolle für die Performance-Optimierung. Für jedes Bildformat existieren verlustfreie und verlustbehaftete Komprimierungsverfahren. Verlustbehaftete Komprimierung entfernt Pixeldaten, während verlustfreie Komprimierung die Datenmenge reduziert, ohne Informationen zu verlieren. Der Text betont, dass jedes Bildformat unterschiedliche Algorithmen und Verfahren zur Komprimierung verwendet. Um optimale Ergebnisse zu erzielen, müssen die spezifischen Eigenschaften jedes Bildformats berücksichtigt werden (Grigorik 2016b). Eine effiziente Bildoptimierung trägt maßgeblich zur Reduktion der Datenmenge und somit zur Verbesserung der Ladezeiten bei.

Im Gegensatz zu HTTP/1.1, das ein textbasiertes Format verwendet, basiert HTTP/2 auf einem binären Format. Dies wird als ein wesentlicher Faktor für die verbesserte Performance und Stabilität von HTTP/2 genannt. Textbasierte Protokolle, die ASCII-Kodierung verwenden, sind zwar einfacher zu analysieren und zu implementieren, jedoch weniger effizient und anfälliger für Fehler durch zusätzliche Leerzeichen oder Zeilenumbrüche (Grigorik 2015, 7). Das binäre Format von HTTP/2 ermöglicht eine effizientere Datenübertragung und reduziert den Overhead. Die verbesserte Effizienz resultiert in schnelleren Ladezeiten und einer stabileren Kommunikation zwischen Client und Server. Diese Vorteile machen HTTP/2 zu einer attraktiven Technologie für die Optimierung der Web Performance.

Ein Kernpunkt der Arbeit ist die Untersuchung der 'Server Push'-Funktion von HTTP/2. Server Push ermöglicht es dem Server, Ressourcen proaktiv an den Client zu senden, bevor diese explizit angefordert werden. Dies kann die Ladezeit erheblich verkürzen, da der Client nicht auf jede einzelne Anfrage warten muss. Die Effizienz von Server Push hängt jedoch von der richtigen Priorisierung der Ressourcen ab. Der Client kann einen Priorisierungsbaum erstellen, der dem Server als Hinweis dient, in welcher Reihenfolge die Ressourcen am besten übertragen werden sollten. Diese Priorisierung basiert auf Abhängigkeiten und Gewichten der einzelnen 'Streams'. Der Server berücksichtigt dabei die eigene Auslastung (CPU, RAM, Bandbreite), kann aber keine exakte Lieferreihenfolge garantieren (Grigorik 2015, 10-12). Ein ungünstiges Priorisierungsmanagement kann zum 'Head-of-Line Blocking' zurückführen.

Die Möglichkeit der Multiplexierung von Ressourcen in HTTP/2 führt zu einem Wettbewerb um die Bandbreite. Um einen geregelten Datenfluss zu gewährleisten, wird 'Flow Control' eingesetzt. Dieses Verfahren basiert auf 'WINDOW_UPDATE'-Frames, mit denen der Empfänger (Client) die Anzahl der empfangsbereiten Bytes pro Stream und für die gesamte Sitzung anzeigt. Die Fenstergröße wird dynamisch angepasst. Der Empfänger kann die Fenstergröße für einzelne Streams unabhängig voneinander steuern. 'Flow Control' kann sowohl für einzelne Streams als auch für die gesamte Sitzung deaktiviert werden (Buch IG, 219). Dieses Feature sorgt für eine effiziente Verteilung der Bandbreite und verhindert Überlastungen, die zu Performance-Einbußen führen könnten.

Die Arbeit beschreibt die Implementierung von HTTP/2 mit dem Apache-Webserver und dem Modul 'mod_http2'. 'mod_http2' unterstützt unter anderem die 'Server Push'-Funktion. Die Wahl des Apache-Servers erfolgte aufgrund seiner Verbreitung und vorhandener Erfahrung der Autorin. Als Betriebssystem wurde nach einer Recherche (DistroWatch 2016) entweder 'Fedora' oder 'openSUSE' verwendet, Kriterien waren eine große Community und eine detaillierte Dokumentation. Für die Tests wurde eine eigene Webapplikation entwickelt, die verschiedene Ressourcentypen (CSS, JavaScript, Bilder, Schriften) enthält, um die Auswirkungen von Server Push umfassend zu untersuchen. Werkzeuge wie 'Curl' zum Aufruf der Webapplikation, 'Webpagetest.org' zur Performance-Messung und 'Wireshark' zur Netzwerk-Analyse wurden eingesetzt.

Dieser Abschnitt beschreibt die detaillierte Funktionsweise von Server Push im Kontext eines Apache-Servers (Version 2.4.20) mit dem Modul mod_http2. Die Analyse nutzt Wireshark, um den Datenverkehr auf Paketebene zu untersuchen. Mozilla Firefox (Version 47.0) dient als Client. Ein wichtiges Ergebnis ist, dass die gepushten Ressourcen in der Reihenfolge des serverseitigen <VirtualHost>-Eintrags ankommen. Die Dokumentation von mod_http2 legt nahe, dass verschiedene Ressourcentypen (MIME-Typen) unterschiedlich priorisiert werden können, um die Bandbreite optimal zu verteilen. Die serverseitige Priorisierung wird über die Direktive H2PushPriority gesteuert, die MIME-Typ, Gewicht und die Reihenfolge (after, before, interleaved) der Ressourcen im Verhältnis zum Hauptstream definiert (Apache Software Foundation 2016a). Die Untersuchung zeigt, dass der Client selbst kein explizites Signal zum Annehmen der gepushten Ressourcen sendet, wie in der mod_http2-Dokumentation beschrieben. Die PUSH_PROMISE-Frames erscheinen unmittelbar nach dem Abruf der HTML-Datei.

Die Wireshark-Analyse zeigt, dass die PUSH_PROMISE-Frames genau in der Reihenfolge ankommen, wie sie im <VirtualHost> konfiguriert sind. Erwartungsgemäß sollten der Server oder der Client nun die Priorisierung der Streams (z.B. höhere Gewichte für CSS) übernehmen. Überraschenderweise weisen alle vom Client gesendeten PRIORITY-Frames das gleiche Gewicht (Weight: 1) auf. Dies deutet darauf hin, dass die serverseitig konfigurierten Gewichte für CSS und Schriftarten nicht vom Client (Mozilla Firefox 47.0) berücksichtigt werden. Die Experimente zeigen, dass die Einstellungen in der H2PushPriority-Direktive keinen signifikanten Einfluss auf die Reihenfolge der gepushten Ressourcen haben. Eine mögliche Erklärung hierfür ist, dass mod_http2 sich noch im experimentellen Stadium befindet (Apache Software Foundation 2016a) oder dass die vom Server gesetzten Gewichte vom Browser nicht korrekt interpretiert werden. Die Ergebnisse hinterfragen die Effektivität der serverseitigen Priorisierung in der aktuellen Implementierung.

Die Arbeit untersucht den Einfluss von Server Push auf den kritischen Rendering Pfad. Der Fokus liegt auf der Ladezeit und der Darstellung der ersten Pixel im Viewport. Drei Tests werden durchgeführt: Test 1 fokussiert kritische CSS-Ressourcen; Test 3 erweitert dies um Webschriften; Test 4 beinhaltet zusätzlich Bilder. Bei Test 1 wird beobachtet, dass Server Push für kritische CSS-Ressourcen zwar Anfragebytes spart und den Client schneller mit diesen Daten versorgt, jedoch die DOM-Erstellung etwas verzögert. Bei Test 3 und 4 wird eine Verzögerung im 'Start Render' festgestellt, was auf eine Blockierung durch die PUSH_PROMISE-Frames und die Client-seitige Priorisierung zurückgeführt wird. Die Ergebnisse zeigen, dass Server Push für kritische Ressourcen im Allgemeinen vorteilhaft ist, jedoch eine zu große Anzahl an gepushten Ressourcen zu Verzögerungen im kritischen Rendering Pfad und somit zu einer schlechteren Performance führen kann. Die Verwendung von Boxplot-Diagrammen visualisiert die Ergebnisse und verdeutlicht die Auswirkungen auf Metriken wie 'Time To First Byte' und 'Start Render'.

Der Einfluss der Ressourcenaufteilung auf die Performance wird unter HTTP/2 untersucht. Die Analyse unter Verwendung einer Kabelverbindung und Wireshark zeigt, dass Ressourcen in der FIFO-Reihenfolge (First In, First Out) beim Client ankommen. Der Server verarbeitet mehrere Anfragen parallel, und es wird spekuliert, ob eine bessere Durchmischung von Requests und Responses die Performance weiter verbessern könnte. Ein Vergleich mit vorherigen Tests unter einer 3G-Verbindung zeigt, dass, unabhängig von der Ressourcenaufteilung, die Ladezeiten unter HTTP/2 langsamer als unter HTTP/1.1 sind. Dies legt nahe, dass die reine Anzahl der Ressourcen und die effiziente Multiplexierung von Frames in HTTP/2 entscheidend für die Performance sind. Die Analyse betont den Einfluss von Browserunterschieden; obwohl die Browserversionen auf dem lokalen Rechner und auf webpagetest.org übereinstimmen, sind die Messergebnisse unterschiedlich, was die Komplexität der Performance-Optimierung unter HTTP/2 hervorhebt.

Ein zentraler Punkt des Vergleichs ist die Ladezeit von Webapplikationen unter HTTP/1.1 und HTTP/2. Die Ergebnisse zeigen überraschenderweise, dass die Ladezeiten unter HTTP/2, trotz der theoretischen Vorteile, teilweise deutlich langsamer als unter HTTP/1.1 waren. Dieser Unterschied war besonders ausgeprägt bei Tests unter mobilen Netzwerken. Obwohl die Zeit für die Netzwerkverbindung unter HTTP/2 oft kürzer oder gleich der Zeit unter HTTP/1.1 war, resultierte die Gesamtladezeit dennoch in einer deutlichen Verlangsamung. Der Text verweist auf die Aussage, dass etwa 80-90% der Gesamtgeschwindigkeit einer Webapplikation vom Frontend abhängen (Rigor, Inc. 2016). Die Testergebnisse legen nahe, dass clientseitige Optimierungstechniken für HTTP/2 allein nicht ausreichen, um performante Webapplikationen zu erstellen. Die Untersuchung deutet auf Probleme bei der Implementierung von HTTP/2 hin, sowohl auf Server- als auch auf Clientseite. Die Effizienz der Multiplexierung von Frames scheint nicht optimal zu funktionieren.

Um die Ursachen der langsamen Ladezeiten unter HTTP/2 zu untersuchen, wurde Wireshark zur Netzwerk-Analyse eingesetzt. Die Analyse der Kommunikation zwischen Client und Server unter HTTP/2 zeigt, dass Ressourcen zwar über mehrere Streams parallel abgefragt werden, jedoch in einer FIFO-Reihenfolge (First In, First Out) beim Client ankommen. Die Multiplexierung scheint nicht perfekt zu funktionieren, da die Frames der verschiedenen Streams nicht ausreichend vermischt werden. Das bedeutet, der Server verarbeitet Requests nacheinander und wartet möglicherweise unnötig lang auf weitere Anfragen. Ein idealerer Zustand wäre eine bessere Durchmischung der Requests und Responses, um die Serverauslastung zu optimieren und die Gesamtladezeit zu reduzieren. Die Untersuchung legt nahe, dass ein suboptimales Verhalten der Frame-Multiplexierung einen wesentlichen Beitrag zu den beobachteten Performance-Einbußen bei HTTP/2 beiträgt, besonders im Vergleich zu HTTP/1.1.

Die Studie hebt die Unterschiede im Verhalten von HTTP/2 zwischen verschiedenen Browsern hervor. Tests mit Google Chrome und Mozilla Firefox zeigten unterschiedliche Ergebnisse, obwohl die Browserversionen auf dem lokalen Rechner und auf Webpagetest.org identisch waren. Auf Webpagetest.org funktionierte Server Push wie erwartet, während die lokalen Tests abweichende Resultate lieferten. Die Ressourcenaufteilung wird als ein wichtiges Kriterium für die Performance und die Entwicklung von Webapplikationen betrachtet. Kleinere Ressourcen vereinfachen die Entwicklung, sind einfacher zu cachen und laden unter hohen Latenzbedingungen (z.B. mobile Netzwerke) schneller. Die Ergebnisse zeigen jedoch, dass entgegen den theoretischen Erwartungen, eine größere Anzahl kleiner Dateien unter HTTP/2 zu einer langsameren Ladezeit führt, im Gegensatz zu der unter HTTP/1.1. Dies unterstreicht die Komplexität des HTTP/2-Protokolls und die Bedeutung von umfassenden Tests in realen Umgebungen.

Zusammenfassend lässt sich sagen, dass der Vergleich von HTTP/1.1 und HTTP/2 unerwartete Ergebnisse lieferte. Trotz der theoretischen Vorteile von HTTP/2 hinsichtlich schnellerer Datenübertragung, waren die Ladezeiten in den durchgeführten Tests oft langsamer als bei HTTP/1.1, vor allem unter mobilen Netzbedingungen. Die Analyse deutet auf eine nicht optimale Implementierung und ein unvorhergesehenes Verhalten der Frame-Multiplexierung in HTTP/2 hin. Es wird deutlich, dass clientseitige Optimierungstechniken allein nicht ausreichend sind, um performante Webapplikationen unter HTTP/2 zu entwickeln. Die Berücksichtigung des TCP-Protokolls und die Analyse von Traffic, Paketreihenfolge und -inhalten sind für die Entwicklung performanter Webapplikationen unter HTTP/2 unerlässlich. Die Komplexität des Protokolls und seine browserabhängige Funktionsweise bedingen die Notwendigkeit weiterer Tests und Experimente.

Die Arbeit fasst die Ergebnisse des Vergleichs zwischen HTTP/1.1 und HTTP/2 zusammen. Es zeigt sich, dass die erwartete Performance-Steigerung durch HTTP/2 nicht in allen Tests erreicht wurde. Im Gegenteil: Die Ladezeiten waren in einigen Fällen, besonders unter mobilen Netzbedingungen, deutlich langsamer als unter HTTP/1.1. Obwohl die reine Netzwerkverbindungszeit unter HTTP/2 oft vergleichbar oder sogar schneller war, übertraf die Gesamtladezeit die von HTTP/1.1. Dieser Befund steht im Widerspruch zu der Annahme, dass HTTP/2 eine signifikante Performance-Verbesserung bringt. Die Untersuchung weist auf die Notwendigkeit hin, neben clientseitigen Optimierungen auch serverseitige Faktoren und das Verhalten des TCP-Protokolls zu berücksichtigen, um die volle Leistungsfähigkeit von HTTP/2 zu nutzen. Die Ergebnisse betonen die Komplexität der Performance-Optimierung und die Notwendigkeit weiterer Forschung.

Die Analyse zeigt, dass unter HTTP/2 nur eine einzige TCP-Verbindung zwischen Client und Server besteht. Dies hat Auswirkungen auf die Effizienz der Datenübertragung. Wireshark-Analysen legen nahe, dass die Multiplexierung von Frames nicht optimal funktioniert. Die Ressourcen kommen beim Client in einer FIFO-Reihenfolge (First In, First Out) an, was darauf hindeutet, dass der Server die Requests nicht vollständig parallel verarbeitet. Eine bessere Durchmischung der Requests und Responses könnte die Performance verbessern. Die Ergebnisse deuten darauf hin, dass die Effizienz der Multiplexierung von Frames in HTTP/2 nicht so effizient ist, wie theoretisch erwartet. Eine Verbesserung der Multiplexierung und eine effizientere Nutzung der TCP-Verbindung könnten die Performance unter HTTP/2 deutlich verbessern.

Die Arbeit hebt die Bedeutung von Browserunterschieden bei der HTTP/2-Performance hervor. Tests mit unterschiedlichen Browsern (z.B. Google Chrome und Mozilla Firefox) zeigten erhebliche Abweichungen in den Ergebnissen, obwohl die Browserversionen identisch waren. Dies unterstreicht die Notwendigkeit, Browser-spezifische Aspekte bei der Performance-Optimierung zu berücksichtigen. Die Studie stellt fest, dass die Funktionsweise von HTTP/2 und die Effektivität der Optimierungstechniken sowohl server- als auch clientseitig nicht perfekt sind. Viele der Ergebnisse waren unerwartet und blieben teilweise unerklärt. Die im Rahmen der Arbeit durchgeführten Tests konnten nicht alle geplanten Ziele erreichen, da einige Funktionen nicht korrekt implementiert waren. Es wird deutlich, dass weitere Forschung und Tests notwendig sind, um das Verhalten von HTTP/2 besser zu verstehen und optimale Optimierungstechniken zu entwickeln.