Das Internet ist mittlerweile 25 Jahre alt und die Art, wie Ihr Browser mit einer Website kommuniziert, via HTTP, hat sich seither nicht sehr verändert. Allerdings hat sich die Art und Weise geändert, wie wir das Web nutzen, und dabei zeigen sich allmählich die Einschränkungen von HTTP/1. Das Laden von Webseiten läuft langsamer als notwendig und das Netzwerk wird dabei nicht effizient genug genutzt. Das liegt daran, dass HTTP/1 praktisch nur eine Abfrage pro TCP-Verbindung im selben Zeitraum zulässt.
Da moderne Webseiten oft mehr als hundert Abfragen machen müssen, um JavaScript, CSS und Bilder zu laden, stellt das ein großes Problem dar. Heutzutage nutzen Browser eine Vielzahl von Verbindungen pro Seite, um all diese Inhalte herunterzuladen. Allerdings können sie auch nicht zu viele nutzen, denn das würde das Netzwerk überlasten, indem es den Datenstau verschlimmert. Also nutzen Browser aktuell zwischen 4 und 8 Verbindungen und schätzen dabei ab, welche Abfrage sie über welche Verbindung verschicken – und manchmal liegen sie falsch.
Die große Zahl der Anfragen an moderne Webseiten verursacht auch noch ein weiteres Problem: Jede einzelne Anfrage enthalt eine bestimmten Satz an HTTP-Headern, der mit der Zeit anwächst – etwa durch Elemente wie Cookies. Dieser kann sich zu einer großen Menge versendbarer Daten aufsummieren. In mobilen Netzwerken mit hoher Latenz hat dies eine deutliche Auswirkung auf die Performance. All das hat HTTP/1 bisher verlangsamt und seine Nutzung zunehmend verkompliziert. Viele Webseiten versuchen, diese Probleme zu bewältigen, indem sie selbige durch Kniffe umgehen: mit Techniken wie CSS-Druck, Inline-Ersetzung und Dateienverknüpfung. Obwohl sie weiterhelfen, sind diese Kniffe auch ein klarer Hinweis darauf, dass wir uns noch deutlich verbessern können.
Deshalb begann 2012 die Arbeit an HTTP/2. Dieses neue Protokoll, basierend auf dem Speedy-Projekt, erlaubt es, eine Verbindung für jegliche Kommunikation zwischen dem eigenen Web-Browser und einer Webseite zu nutzen. Es tut dies, indem es Anfrage- und Antwort-Nachrichten in kleine Datenblöcke namens „Frames“ (Rahmen) aufteilt und sie einzeln benennt, sodass sie wieder zusammengesetzt werden können, sobald sie beim Empfänger angelangt sind.
Dieses Verfahren heißt „Multiplexing“. Es erlaubt, das Netzwerk viel effizienter zu nutzen, weil dabei viele Nachrichten gleichzeitig unterwegs sein können – anders als bei HTTP/1. Zusätzlich erlaubt HTTP/2 die Komprimierung von Headern. Das bedeutet, dass dabei nicht unnötig Übertragungsgeschwindigkeit verschwendet wird, um wiederholt überflüssige Informationen zu übermitteln. Das ermöglicht, Seiten viel schneller zu laden, auch wenn sie eine große Zahl an Anfragen bearbeiten müssen (wie viele das tun), da die Anfragen in kürzerer Zeit durch das Netzwerk gelangen. Andere Optimierungen wie Server Push ermöglichen es einer Seite, Antworten zum Browser zu senden, bevor er diese braucht – auch das verbessert die Performance.
Frühe Ergebnisse deuten darauf hin, dass allein die Aktivierung von HTTP/2 oft – wenn auch nicht immer – zu einer 5- bis 15-prozentigen Verbesserung der Performance führt. Mit ein paar Anpassungen ist sogar eine deutlich stärkere Verbesserung möglich. Es ist wichtig zu wissen, dass das neue Protokoll grundlegende Dinge wie die HTTP-Methoden nicht verändert. Header oder Statuscodes, welche die HTTP-Programmierschnittstellen nutzen, bleiben weitgehend unverändert. Es kann sogar auf einer Hop-by-Hop-Basis verwendet werden, sodass man nicht zeitgleich seine gesamte eigene Infrastruktur aktualisieren muss.
HTTP/2 ist fast fertig. Es wird demnächst auch von gängigen Web-Browsern wie Firefox, Internet Explorer und Google Chrome unterstützt werden. Akamai wird HTTP/2 ebenfalls unterstützen und das neue Protokoll so einem großen Teil des Webs näherbringen.