Know-how: Alles Wichtige zum neuen HTTP/2-Standard

HTTP/2: WWW Next Generation

Mit mehr als 20 Jahren auf dem Buckel ist es an der Zeit, das betagte HTTP-Protokoll zu überarbeiten. Jetzt ist der Standard für HTTP/2 veröffentlicht, der das Web-Protokoll zumindest für die nächsten paar Jahre fit machen soll.
Mit einer vernünftigen Backup-Strategie wappnen sich Administratoren erfolgreich gegen Datenverluste und längere Systemausfälle. So zeigen wir Ihnen ... (mehr)

Als Tim Berners-Lee im Jahr 1991 die erste Version von HTTP niederschrieb, war alles noch rührend einfach. Auf nur einer Seite beschrieb er in wenigen Sätzen, wie ein HTTP-Server auf die GET-Anfrage eines Clients reagieren soll, und legte damit den Grundstein für das World Wide Web. Ein Jahr später folgte ein Draft, der nach einigen Überarbeitungen in den RFC 1945 mündete, der im Mai 1996 die Version 1.0 des Hypertext Transfer Protocol (HTTP) standardisierte.

Drei Jahre später wurde HTTP 1.1 standardisiert, um den neuen Anforderungen des WWW gerecht zu werden, etwa der immer größeren Anzahl eingebetteter Bilder. Das überarbeitete Protokoll reduzierte beispielsweise mit Keepalive-Verbindungen die für eine Webseite nötigen Requests. Mit HTTP-Pipelining, das sich aber in der Praxis nie richtig durchgesetzt hat, können sogar mehrere Anfragen hintereinander abgesetzt werden, ohne zuerst auf die Antwort zu warten. In den Jahren nach HTTP 1.1 ist wenig passiert, obwohl sich nicht nur die Weblandschaft mit interaktiven Anwendungen im Browser, Ajax und Echtzeit-Updates grundlegend verändert, sondern sich auch die Netzwerk-Infrastruktur weiterentwickelt hat, etwa mit 10 GBit- und in Backbones gar 100 GBit-Netzen.

Erst im Jahr 2012 erwachte die IETF (Internet Engineering Task Force) aus ihrem Dornröschenschlaf und stellte fest, dass es mal wieder Zeit für eine Aktualisierung des Protokolls war. Die zuständige Working Group "httpbis" kam zusammen, sondierte das Feld und bemerkte, dass Google-Techniker zwischenzeitlich ein alternatives Protokoll namens SPDY entwickelt hatten. Nach eingehender Prüfung und einem Vergleich mit Alternativen entschied sich die Working Group, das künftige Protokoll auf SPDY aufzubauen.

Innerhalb der letzten zwei Jahre hat sie diverse Entwürfe erarbeitet, testweise implementiert und Interoperabilitätstests durchgeführt. Anfang dieses Jahres hat die Internet Engineering Steering Group (IESG) schließlich den Vorschlag für das HTTP/2-Protokoll angenommen, der dem Draft 17 entspricht [1]. Somit stand der Standardisierung von HTTP/2 nichts mehr im Weg und nach einer redaktionellen Bearbeitung erhielt der entsprechende RFC die Nummer 7540 zugewiesen.

Mark Nottingham, Vorsitzender der HTTP Working Group, bedankte sich nach Abschluss der Arbeit bei einigen Beteiligten namentlich, insbesondere den beiden Google-Mitarbeitern Mike Belshe und Roberto Peon, die mit ihren Arbeiten zum SPDY-Protokoll den Grundstein für HTTP/2 gelegt hätten. Allerdings habe Google entgegen eines verbreiteten Irrglaubens der IETF das Protokoll nicht aufgezwungen. Übrigens hieß das Protokoll zwischendurch einmal "HTTP 2.0", aber der Name wurde zugunsten der offiziellen Bezeichnung HTTP/2 aufgegeben, da schon beim 1er-Protokoll die Minor-Version zu Verwirrungen geführt hat. Ein HTTP 2.1 wird es deshalb auch nie geben.

HTTP/2 sollte schneller werden

Das wesentliche Entwicklungsziel von HTTP/2 war, die Ladezeiten von Webseiten zu reduzieren. Dazu bietet es einige Techniken, zum Beispiel den Transport mehrerer Anfragen über eine einzige TCP-Verbindung, um so den Overhead für den Verbindungsaufbau zu reduzieren. Dazu führt HTTP/2 eine neue Zwischenschicht ein, bei der die gewohnten HTTP-Protokollelemente in Binärpakete (Frames) zerlegt und verpackt werden. Hierbei stecken die Header und die Nutzdaten in verschiedenen Frames, die über einen sogenannten Stream verschickt werden, der Anfrage und Antworten bündelt, die zu einer Verbindung zwischen Client und Server gehören. Zwischen den beiden kann es gleichzeitig mehrere Streams geben, die aber alle innerhalb einer einzigen TCP-Verbindung abgewickelt werden.

Die Priorisierung von Requests sorgt dafür, dass wichtige Anfragen gegenüber anderen bevorzugt behandelt werden. Das soll das sogenannte Head-of-Line-Blocking verhindern, bei dem der Transport von Nachrichten zum Stillstand kommt, weil einer der beiden Kommunikationspartner auf ein wichtiges Paket warten muss. Zusätzlich hat der Server die Möglichkeit, von sich aus Daten zum Client zu schicken, wenn er weiß, dass jener sie demnächst brauchen wird (Server Push). Allerdings gibt es bisher kaum erprobte Strategien, nach welchen Gesichtspunkten Clients und Server Prioritäten verwenden beziehungsweise von selbst Daten vom Server zum Client pushen.

Mit einem Verfahren namens HPACK, das formal in einem zweiten Standard festgelegt ist, komprimiert HTTP/2 die übertragenen Header, um das Datenvolumen zu reduzieren. Hierbei kommt aber keines der bekannten Komprimierungsverfahren wie Zip zum Einsatz, sondern eine indexbasierte Methode, die auf beiden Seiten der Verbindung Header-Felder speichert und in den folgenden Frames nur noch die geänderten Felder überträgt. In einer früheren Version des Protokolls kam hier die Zlib-Komprimierung zum Einsatz, aber eine dabei entdeckte Sicherheitslücke machte den Plan zunichte.

Dank der zusätzlichen Schicht des Binär-Framings konnten die Entwickler die HTTP-1-Semantik mit den bekannten HTTP-Methoden (GET, POST,...) sowie Response- und Status-Codes erhalten. Für Anwendungen auf Server- und Client-Seite ist das neue Protokoll damit transparent, denn sie kümmern sich nicht um das darunterliegende Binary Framing. Das Debugging wird dadurch möglicherweise etwas erschwert, denn das Mitlesen des Protokolls ist nun nicht mehr so einfach wie beim ASCII-basierten HTTP 1. Dafür werden aber Tools wie Wireshark HTTP/2 implementieren.

Kompatibilität und Verschlüsselung

Ein weiteres wichtiges Ziel des neuen Standards war es, aus Kompatibilitätsgründen die bisherigen URL-Schemas http und https beizubehalten. Also muss das Protokoll einen Mechanismus unterstützen, über den sich Server und Client darüber verständigen, welche Version sie verwenden. HTTP/2 bietet dazu einen Upgrade-Header, der die beteiligte Partei dazu anweist, auf das neue Protokoll zu wechseln. Allerdings erfordert das einen kompletten Roundtrip, also den Datenaustausch zwischen Client und Server und zurück. Für TLS-verschlüsseltes HTTP/2 gibt es eine andere Lösung, die weniger Overhead erzeugt, die ALPN-Extension (Application Layer Protocol Negotiation) von TLS, die das Anwendungsprotokoll beim TLS-Handshake aushandelt – der aber seinerseits wieder einen gewissen Overhead mit sich bringt.

Dass TLS-Verschlüsselung in HTTP/2 im Gegensatz zu SPDY nicht obligatorisch ist, hat seinen Grund in der Gemengelage von Interessen, die in der Working Group vertreten waren. Anbietern und Betreibern von Netzen oder Content Delivery Networks und Hardware-Herstellern ist daran gelegen, den Netzwerk-Traffic auch unterwegs inspizieren zu können, um ihn für ihre Zwecke zu "optimieren". Um dieses Anliegen zu vertreten und seinerzeit noch gegen SPDY in Stellung zu bringen, haben die Protagonisten eigens eine Organisation mit dem etwas beschönigenden Namen "Open Web Alliance" gegründet. Deren Mitglieder wie Verizon und Cisco haben sich in der Working Group für ein unverschlüsseltes Web eingesetzt. Jedoch am Ende nur mit mäßigem Erfolg, denn sowohl die Google Chrome- wie auch die Firefox-Entwickler haben angekündigt, HTTP/2 nur mit TLS zu implementieren. Der Nachfolger des Internet Explorer soll allerdings HTTP/2 auch ohne Verschlüsselung beherrschen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Zertifikatsmanagement mit Certmonger

Zertifikate werden dazu verwendet, um Benutzer, Services und Hardware mit der Hilfe eines signierten Schlüssels zu verifizieren. Hierfür existieren Public-Key-Infrastrukturen (PKI). Aber wie gelangen die Zertifikate eigentlich auf das Ziel-Gerät? Der Open-Source-Tipp in diesem Monat beschreibt, wie Sie für diese Aufgabe das Tool certmonger verwenden können. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2017

Microsite