Datenturbo fürs Web

von Sandro Lucifora

Das Hypertext Transfer Protocol, kurz HTTP, dient nicht mehr nur als Grundlage für den Aufruf von Webseiten, sondern ist auch die Basis für vielfältige Anwendungen. Die bekannteste und immer noch auf den meisten Servern genutzte Version ist HTTP/1.1 – und das obwohl bereits HTTP/3 definiert ist. Die Geschichte des Protokolls sowie die praktischen Unterschiede zwischen den Versionen 1.1, 2 und 3 erfahren Sie in diesem Beitrag.

Die Grundlage für das heutige Internet schaffte der britische Wissenschaftler Tim Berners-Lee 1989, während seiner Arbeit am CERN. Das Web wurde ursprünglich konzipiert und entwickelt, um die Nachfrage nach automatisiertem Informationsaustausch zwischen Wissenschaftlern an Universitäten und Instituten weltweit zu ermöglichen. Als Ausgangspunkt setzten die Wissenschaftler auf Hypertext. Dies bezeichnet einen Text mit einer netzförmigen, dynamischen Struktur. Er unterscheidet sich vom bis dahin typischen linearen Text, wie er in Büchern üblicherweise zu finden ist, dadurch, dass er nicht so geschrieben ist, dass Leser ihn von Anfang bis Ende in der veröffentlichten Reihenfolge lesen. Gerade bei wissenschaftlichen Werken arbeiten die Autoren mit Verweisen und Fußnoten, die auf andere Textpassagen hinweisen und verlinken.

Technisch gesehen ist Hypertext in der sogenannten Auszeichnungssprache geschrieben, die neben für den Betrachter unsichtbaren Gestaltungsanweisungen auch Hyperlinks enthält, also Querverweise zu weiterführenden Textpassagen und anderen Dokumenten im Netzwerk. Für das Internet hat sich die Auszeichnungssprache Hypertext Markup Lan-guage, kurz HTML, durchgesetzt.

Ausgehend vom Hypertext erschufen die Wissenschaftler das Hypertext Transfer Protokoll - heute täglich millionenfach als HTTP verwendet. Ziel war es dabei, den Hypertext in der Auszeichnungssprache HTML mit anderen Computern auszutauschen, wofür ein allgemein gültiges Protokoll notwendig war. Somit lässt sich die Grundlage für das heutige Internet auf vier Punkte zusammenfassen:

- Das Textformat zur Darstellung von Hypertextdokumenten (HyperText Markup Language, HTML)

- Eine Software, die diese Dokumente anzeigt (der Webbrowser)

- Ein einfaches Protokoll zum Austausch dieser Dokumente (das Hypertext Transfer Protocol, HTTP)

- Ein Server, der Zugriff auf das Dokument gewährt (der Hypertext Transfer Protocol Daemon, HTTPD)

Das einzeilige Protokoll HTTP/0.9

Die ursprüngliche Version von HTTP hatte keine Versionsnummer. Um diese von späteren Versionen zu unterscheiden, wurde sie im Nachhinein als "0.9" bezeichnet. HTTP/0.9 ist recht einfach: Jede Anforderung besteht aus einer einzelnen Zeile und beginnt mit der einzig möglichen Methode GET, gefolgt vom Pfad zur Ressource (nicht der URL, da sowohl die Nennung des Protokolls als auch der Server und des Ports zur Verbindung mit dem Server nicht erforderlich ist):

Auch die Antwort auf den GET-Befehl war recht einfach und beinhaltete nur den Inhalt der einen Datei:

Dieser Vorläufer der heutigen Protokolle kannte noch keine HTTP-Header, sodass sich nur HTML-Dateien übertragen ließen und keine anderen Dokumenttypen. Zu der Zeit gab es auch keine Status- oder Fehlercodes. Stattdessen sendete der Server im Fall eines Problems eine generierte HTML-Datei mit der Beschreibung des aufgetretenen Fehlers zurück.

Der erste Standard: HTTP/1.1

1996 arbeitete ein Konsortium an der Standardisierung des Hypertext Transfer Protokolls in der Version 1.1 und veröffentlichte Anfang 1997 mit dem RFC 2616 den esten ausgearbeiteten Standard für HTTP/1.1. Er ist in der heutigen erweiterten Version von Juni 1999 nachzulesen [1]. Zwischenzeitlich hatte auch die Internet Engineering Task Force, kurz IETF, die zentrale Arbeit an der Definition von http übernommen. RFC 2616 hat Unklarheiten bereinigt und zahlreiche Verbesserungen eingeführt:

- Eine Verbindung lässt sich wiederverwenden, um Zeit zu sparen und Ressourcen nachzuladen.

- Mit Pipelining lässt sich eine zweite Anfrage senden, noch bevor der Server die Antwort für die erste vollständig übertragen hat. Damit lässt sich die Latenz der Kommunikation verringern.

- Bei Chunked Transfer Coding handelt es sich um eine gestückelte Übertragung von Daten mit zusätzlichen Informationen, die es dem Client ermöglicht festzustellen, ob die erhaltenen Informationen komplett sind.

- Zusätzliche Cache-Steuerungsmechanismen kamen hinzu.

- Damit der Sender und Empfänger die beste Kompatibilität erreichen, führen sie einen Handshake durch. Dabei handeln der Server und Client bestimmte Grundlagen aus, um damit die beste Kommunikationsgrundlage zu schaffen.

- Bahnbrechend und bis heute unverzichtbar ist der eingeführte Host-Header. Dieser erlaubt es dem Server erstmalig, verschiedene Domänen unter derselben IP-Adresse vorzuhalten.

Der Host-Header ist für das heutige Internet sehr entscheidend. Denn ohne diese in der RFC 7230, Sektion 5.4 [2] festgelegte Definition wäre es heute nicht möglich, eine Vielzahl von Internetseiten auf einem Server bereitzustellen. Jede Internetseite bräuchte einen eigenen HTTP-Dämon und somit auch einen eigenen Server. Damit ein Server mehrere Domains unter derselben IP-Adresse verwalten kann, ist es mit HTTP/1.1 zwingend erforderlich, bei der GET-Anfrage auch den gewünschten Host mitzuschicken. Zum Beispiel sieht eine GET Anfrage für "http://www.it-administrator.de/pub/WWW/" so aus:

Fehlt dieser Header, muss der Server nach Definition mit dem Status "400 Bad Request" antworten. Um die Seite "https:// www.it-administrator.de/trainings/" im Browser zu öffnen, sendet dieser folgenden Header:

Der Server antwortet als Erstes mit dem Status 200, der dem Client signalisiert, dass seine Anfrage fehlerfrei verarbeitet wird, und fügt dann weitere Informationen hinzu:

Danach folgt der Inhalt der angefragten Seite. Bei der Anfrage eines Bildes sieht der Host Header etwas anders aus:

Der Server antwortet mit

gefolgt vom Bild mit der zuvor angekündigten Größe von 32.768 Byte. Im Gegensatz zum Content-Type "text/html" erhält der Browser hier zwei weitere Informationen: Mit "age" erfährt der Client, wie lange das Objekt im Proxy-Cache gelegen hat, und mit "Cache-Control" erhalten alle Caching-Mechanismen die Angabe, ob und wie lange das Objekt gespeichert sein darf. Damit erreichen die Server, dass Dateien wie etwa Bilder, die sich im Regelfall nicht mehr ändern, aus dem lokalen Cache des Browsers geladen und nicht vom Server abgerufen werden.

Schnellere Übertragung mit HTTP/2

Dank der Flexibilität und Erweiterbarkeit von HTTP/1.1 und der Tatsache, dass die IETF das Protokoll über zwei Revisionen erweiterte – RFC 2616 wurde im Juni 1999 veröffentlicht und über RFC 7230 bis 7235 im Juni 2014 – dauerte es 16 Jahre, bis im Mai 2015 die IETF den neuen Standard HTTP/2.0 unter RFC 7540 [3] der Öffentlichkeit vorstellte.

Das Hauptanliegen von HTTP/2.0 war es, das Internet beziehungsweise die Übertragung der Daten zu beschleunigen. Gegenüber den Anfängen sind die Webseiten mittlerweile komplexer geworden. Sie sind keine reinen Darstellungen von Informationen mehr, sondern interaktive Anwendungen. Die Menge der benötigten Dateien pro Seite als auch deren Größe haben zugenommen. Resultierend daraus sind deutlich mehr HTTP-Anforderungen notwendig. HTTP/1.1-Verbindungen müssen Anforderungen in der richtigen Reihenfolge senden. Auch wenn sich theoretisch mehrere parallele Verbindungen öffnen lassen, bedeutet das eine nicht unerhebliche Komplexität der Anfragen und Antworten.

Vorarbeit durch Google und Microsoft

Bereits Anfang der 2010er-Jahre stellte daher Google eine alternative Methode zum Datenaustausch zwischen Client und Server vor. Sie entwickelten das Protokoll SPDY. Es definiert eine Erhöhung der Reaktionsfähigkeit und löste die Begrenzung der Anzahl der zu übertragenen Daten. So diente neben SPDY auch die Weiterentwicklung HTTP Speed+Mobility von Microsoft als Grundlage für das heutige HTTP/2-Protokoll.

Eine wesentliche Änderung gegenüber HTTP/1.1 ist, dass es ein binäres gegenüber dem vorherigen textbasierten Protokoll ist. Daher lässt sich HTTP/2 nicht mehr manuell auslesen oder erstellen. Zudem komprimiert es den Header. Da bei den meisten Anforderungen der Header ähnlich ist, fasst das neue Protokoll diese zusammen und verhindert damit die unnötige doppelte Übertragung von Daten. Des Weiteren ermöglicht HTTP/2 dem Server, Daten vorab in den Client-Cache zu senden, bevor der Client diese anfordert. Ein Beispiel verdeutlicht den Zweck: Eine "index.html"-Datei lädt innerhalb der Datenstruktur die Dateien "style.css" und "script.js". Stellt der Browser mit dem Server eine Verbindung her, liefert dieser erst den Inhalt der HTML-Datei. Der Browser analysiert die Inhalte und findet die beiden Anweisungen im Code, die Dateien "style.css" und "script.js" nachzuladen.

Erst jetzt kann der Browser die Dateien anfordern. Mit HTTP/2 ist es den Webentwicklern möglich, Regeln aufzustellen, damit der Server die Initiative ergreift und die beiden Dateien "style.css" und "script.js" direkt mit "index.html" ausliefert, ohne erst auf die Anforderung durch den Client zu warten. Damit liegen die Dateien bereits im Browser-Cache, wenn "index.html" analysiert ist. Die Wartezeit entfällt somit, die das Anfordern und Warten auf die Dateien sonst mit sich bringt. Dieser Mechanismus ist als Server-Push bekannt.

Server-Push unter Apache und ngnix

Da ein Server nicht wissen kann, welche Dateien in Abhängigkeit mit anderen stehen, ist es Aufgabe der Webentwickler oder Administratoren, diese Anweisung manuell vorzunehmen. Bei Apache 2 lässt sich diese Anweisung in "httpd.conf" oder ".htaccess" hinterlegen. Um zum Beispiel eine CSS-Datei immer dann zu pushen, wenn der Browser eine HTML-Datei anfragt, sieht die Anweisung für die Datei "httpd.conf" beziehungsweise ".htaccess" so aus:

Mehrere Dateien fügen wir mit "add Link" anstatt mit "set Link" hinzu:

Hier haben wir auch die Möglichkeit, das Pushen von Dateien von Fremdseiten zu imitieren. Dafür ergänzen wir den Tag mit "crossorigin":

Wer die entsprechenden Apache-Dateien nicht ändern kann oder möchte, hat noch die Möglichkeit, das Pushen von Dateien über zum Beispiel die "header function" von PHP oder andere serverseitige Skriptsprachen zu imitieren. Der Eintrag sieht dann so aus:

Um mehrere Ressourcen zu pushen, trennten wir jede Push-Direktive mit einem Komma:

Diese Anweisung können wir auch mit anderen Regeln kombinieren, die wir auch sonst über den Link-Tag einbinden. Wie zum Beispiel die gleichzeitige Anweisung der Push-Direktive mit einem Preconnect-Hinweis:

Darüber wiesen wir den Server zum einen an, die Datei "style.css" an den Client zu pushen und gleichzeitig schon eine Verbindung zu "fonts.gstatic.com" aufzubauen. Da ngnix keine .htaccess-Datei oder Ähnliches verarbeitet, lässt sich auch hier die Anweisung wie eben beschrieben über PHP umsetzen oder direkt in der Konfiguration des Servers. Hier müssen wir den Absatz "location" mit dem Kommando "http2_push" erweitern. Nach der Anpassung sieht er so aus:

Besser viele kleine als eine große Datei

Im Laufe der Jahre hatte sich bei HTTP/1.1 herausgestellt, dass das HTTP-Pipelining die Ressourcen eines Servers stark belastet. Rein technisch sieht es dabei so aus, dass der Browser die Anforderung der benötigten Dateien in eine Pipeline legt und der Server diese nach und nach abarbeitet. Für Webentwickler bedeutete das bis dato, dass ihr Ziel sein muss, so wenige einzelne Dateien wie möglich nachzuladen. Daher hat es sich als sehr hilfreich erwiesen, zum Beispiel einzelne CSS- oder JS-Dateien zu kombinieren. Das Laden einer einzelnen 80 KByte großen CSS-Datei geht schneller als das Laden von acht 10 KByte großen Dateien. Denn jede Anforderung einer neuen Datei braucht wieder Zeit für den Aufbau der TCP-Verbindung.

Da sich nicht alle Dateien zusammenfassen und als eine herunterladen lassen – vor allem bei Bildern – ist HTTP/2 zum Multiplex-Protokoll geworden. Die beiden Kernänderungen sind dabei, dass ein Client nur einen Stream zum Server öffnet und sich darüber alle Dateien übertragen lassen, ohne für jede neue Anforderung einen neuen Stream zu öffnen. Dadurch sind die vorhandenen TCP-Verbindungen langlebiger, wodurch sie wiederum öfter die volle Datenübertragungsgeschwindigkeit aufbauen können.

Die zweite Änderung besteht darin, dass der Server durch diese Anpassung die Dateien parallel und nicht mehr seriell sendet. Also anstatt einer Datei nach der anderen liefert der Server jetzt viele Dateien auf einmal aus. Das bedeutet nun im Umkehrschluss, dass die zuvor genannte Regel mit den acht CSS-Dateien nicht mehr gilt. Im Gegenteil: Die Anwendung dieser Regel verlangsamt die Webseite unnötig. Denn die maximale Übertragungszeit aller Dateien entspricht der Übertragungszeit für die größte Datei. Braucht zum Beispiel die Übertragung einer 80 KByte großen Datei 347ms, dauert die Übertragung von acht 10-KByte-Dateien nur etwa 48ms, da der Sever diese zur selben Zeit liefert. Mit HTTP/2 nutzen Browser üblicherweise nur eine TCP-Verbindung zu jedem Host anstatt der vorherigen bis zu sechs bei HTTP/1.1.

Aktivierung unter Apache 2 notwendig

Unter Apache 2 ist HTTP/2 nicht von Haus aus aktiviert. Das muss der Administrator einmalig manuell vornehmen. Dazu reicht es aus, das Modul "http2_module" zu installieren und per

in der Konfigurationsdatei zu laden. Die zweite einzutragende Direktive lautet

Damit wird HTTP/2 zum bevorzugten Protokoll, sofern der Client auch HTTP/2 unterstützt. Ansonsten gibt es einen Fallback auf HTTP/1.1.

Hohe Akzeptanz dank Abwärtskompatibilität

Gut ein Jahr nach der Veröffentlichung der HTTP/2-Spezifikation nutzten laut der Statistik von w3techs.com bereits knapp neun Prozent der damaligen Webseiten das neue Protokoll. Wichtiger ist jedoch, dass diese rund zwei Drittel aller Seitenaufrufe abwickelten. Dieser schnellen Akzeptanz ist die Tatsache zugutegekommen, dass HTTP/2 komplett abwärtskompatibel ist. Das bedeutet, dass ein Wechsel der Technologie zunächst keine Anpassung an den Webseiten und -applikationen notwendig macht.

Erst wenn ein Unternehmen mit seiner Webseite oder Applikation die gesamten Vorteile von HTTP/2 nutzen möchte, bedarf es einer Anpassung durch Webentwickler, indem diese – wie zuvor beschrieben – möglichst einzelne Dateien soweit aufteilen wie möglich und die Regeln für den Server-Push definieren.

Der Wechsel von TCP und TLS zu QUIC

Wie beschrieben lag das Hauptaugenmerk beim Wechsel von HTTP/1.1 zu HTTP/2 auf dem Multiplexing und der damit besseren Ausnutzung der Bandbreite. Geht jedoch bei der Übertragung ein Paket verloren, stoppt die gesamte TCP-Verbindung solange, bis das Paket erneut vom Sender zum Empfänger gelangt ist. Je nach Verlustrate hat HTTP/2 dadurch sogar eine geringere Geschwindigkeit als HTTP/1.1 – was daran liegt, dass alle Daten über nur eine TCP-Verbindung laufen und daher alle Übertragungen von dem Paketverlust betroffen sind.

Um dieses Problem zu lösen, hat eine Arbeitsgruppe bei Google im Juli 2016 das Netzwerkprotokoll QUIC (Quick UDP Internet Connections) standardisiert. Es hebt die Beschränkungen bei der Nutzung von TCP auf und basiert auf UDP. Eine Vorgabe ist auch, dass Daten immer mit TLS 1.3 verschlüsselt sind, was die Sicherheit erhöht. Ein geteilter Header schafft weitere Vorteile. Der erste Teil dient lediglich dem verschlüsselten Verbindungsaufbau und enthält keine weiteren Daten. Erst wenn die Verbindung steht, übermittelt das System den Header zur Übertragung der Daten. Bei einem erneuten Verbindungsaufbau zum selben Host muss QUIC die Verschlüsselung nicht neu aushandeln, sondern kann direkt mit der Übertragung über die gesicherte Verbindung starten. Ein weiterer Vorteil ist, dass sich QUIC nicht mehr nur auf die Übertragung von HTTP beschränkt.

Da es schwer ist, im Internet komplett neue Protokolle zu etablieren, hat Google QUIC der IETF vorgestellt. Diese hat QUIC als Grundlage für HTTP/3 genommen und arbeitet seit Anfang 2017 an der Standardisierung. Der letzte Entwurf datiert vom 14. Dezember 2020 [4]. So trennt sich HTTP/3 komplett von TCP und nutzt zukünftig QUIC. Damit HTTP/3 zukünftig HTTP/2 ablösen kann, müssen die Webserver QUIC unterstützen. Apache, der immer noch am weitesten verbreitete HTTP-Daemon, hat bisher noch keine Ankündigung in diese Richtung gemacht. Ngnix hat im Juni 2020 eine erste Version basierend auf dem IETF-QUIC-Dokument vorgestellt. LiteSpeed ist derzeit der einzige Server, der QUIC und damit HTTP/3 vollständig implementiert hat.

Ein langer Weg in die Browser

Da es nicht ausreicht, dass nur der Server QUIC versteht, ist es unumgänglich, dass auch die Clients HTTP/3 unterstützen. Da QUIC aus dem Hause Google stammt, liegt es nahe, dass Chrome bereits QUIC unterstützt. Auch Firefox bietet seit Version 72 eine experimentelle Unterstützung nach der von der IETF veröffentlichten Definition. Microsoft Edge, der inzwischen auf dem Open-Source-Project Chromium basiert, hat mit der Implementierung begonnen. Diese ist derzeit über den Microsoft Edge Insider Channel Canary [5] zu beziehen.

Fazit

Der heutige Standard für die Bereitstellung von Webseiten und -applikationen ist eindeutig HTTP/2. Es löst das gravierendste Problem von HTTP/1.1, das "HTTP Head-of-line blocking". Dabei musste ein Client so lange warten, bis eine gestellte Anfrage fertig ist, bevor er die nächste stellen kann. Das führte zu extremen Verzögerungen, da heutige Webseiten nicht mehr nur aus einer Handvoll Dateien bestehen, sondern viele zusätzliche Daten nachladen. Administratoren haben dabei keinen großen Aufwand, HTTP/2 in Betrieb zu nehmen. HTTP/3 steht derweil in den Startlöchern und bringt den Wechsel von TCP zu QUIC mit.

HTTP 1.1 versus 2.0 und 3.0