Von HTTP zu SDPY

Neubau

Mit mehr als 20 Jahren auf dem Buckel, bietet HTTP durchaus Potenzial für Verbesserungen. Google macht mit SPDY einen Vorschlag für ein künftiges HTTP-Protokoll und will auch noch die TCP-Schicht beschleunigen.

Als Tim Berners-Lee im Jahr 1991 die erste Version des HTTP-Protokolls schriftlich fixierte, war alles noch rührend einfach. Auf gerade einmal einer Seite [1] beschreibt er in wenigen Worten, wie ein Server auf eine GET-Anfrage zu reagieren habe, und der Grundstein für das WWW war gelegt. Ein Jahr später folgte ein Draft, der nach einigen Jahren der Überarbeitung schließlich in den RFC 1945 mündete, der im Mai 1996 endlich HTTP 1.0 standardisierte.

Schon drei Jahre später wurde HTTP 1.1 standardisiert, um den gestiegenen Anforderungen des WWW Rechnung zu tragen. Das überarbeitete Protokoll reduzierte beispielsweise mit Keepalive-Verbindungen die Anzahl der für eine Webseite nötigen Verbindungsversuche. Mit HTTP-Pipelining können sogar mehrere Anfragen hintereinander abgesetzt werden, ohne zuerst auf die Antwort zu warten. Seither ist aber wenig passiert, obwohl sich nicht nur die Weblandschaft mit Anwendungen im Browser, Ajax und Echtzeit-Updates grundlegend verändert, sondern sich auch die Netzwerk-Infrastruktur, etwa mit 10-GBit-Netzen (in einzelnen Backbones sogar schon 100 GBit/s), weiterentwickelt hat. Echtzeit-Anwendungen wie Google+ und Facebook waren damals kaum vorstellbar.

Dass gar nichts passiert, ist zugegebenermaßen etwas übertrieben. Immerhin gibt es die IETF Working Group "Hypertext Transfer Protocol Bis (httpbis)" [2], die sich dem Thema widmet und den RFC 2616 überarbeiten soll. Jedoch geht es eigentlich bislang nur um eine Überarbeitung der Spezifikation, die bestehende Unklarheiten ausräumen soll. Auf der Mailing-Liste hat Mark Nottingham, der Vorsitzende der Arbeitsgruppe jüngst eine Diskussion um HTTP 2.0 angestoßen, dessen erster Draft immerhin schon im Mai 2012 vorliegen soll [3]. Ein Jahr später sollen im Rahmen des "Last Call" letzte Änderungen einfließen, bevor der Standard bei der IESG eingereicht wird.

HTTP 2.0

Bisher gibt es wenig Konkretes zu HTTP 2.0, die Anforderungen an ein künftiges Webprotokoll umfassen jedoch eine gute Performance bei konventionellen wie auch mobilen Browsern und weitgehende Rückwärtskompatiblität. Ein Kandidat für das kommende Protokoll, das diese Voraussetzungen erfüllt, ist das von Google vorangetriebene SPDY (gelesen: "speedy"), das bereits in funktionierendem Code umgesetzt ist, was die allgemeine Akzeptanz fördern dürfte. Naheliegenderweise hat Google den eigenen Browser Chrome mit SPDY-Fähigkeiten ausgestattet [4], auch in der Entwicklerversion von Firefox ist das Protokoll implementiert [5]. Schon in wenigen Monaten könnte die finale Version 11 von Firefox den Code enthalten.

Der Google-Browser Chrome 11 nutzt SPDY bereits per Default, wenn Nutzer per SSL auf Googles Server zugreifen. Ob die eigene Chrome-Version schon SPDY beherrscht, erfährt man mit der URL »chrome://net-internals/#spdy« (Abbildung 1).

Abbildung 1: Neue Versionen des Google-Browsers Chrome verwenden bei SSL-Verbindungen mit Google-Servern bereits das SPDY-Protokoll.

Initiative

Beim Apache-Modul, das den im Internet am häufigsten eingesetzten Webserver mit SPDY-Fähigkeiten versieht, ist längere Zeit nichts mehr passiert. Im Dezember brachten die Entwickler – natürlich auch von Google – es aber auf den mehr oder weniger aktuellen Stand [6]: »mod_spdy« ist ein Modul für Apache 2.2, das versucht, das SPDY-Protokoll dem um das klassische Request-Response-Modell herumgebauten Apache-Server aufzupfropfen. Außerhalb von Google hält sich das Interesse bislang in Grenzen: Die Diskussionsgruppe hat gerade einmal 19 Mitglieder und zwei Nachrichten.

Auch die immer fleißigen und innovativen Entwickler rund um das asynchrone Javascript-Webframework Node.js haben ein SPDY-Modul produziert, das sich unter [7] findet. Ansonsten gibt es Implementierungen des (experimentellen) Protokolls in Python, Java, Ruby, Go, Erlang und C, also genügend Potenzial für eigene Versuche. Den Source Code der eigenen Server-Implementierung will Google irgendwann in näherer Zukunft freigeben.

Trotz aller Neuerungen soll SPDY die Kompatibilität zu existierenden Webanwendungen wahren, also die grundlegende Struktur von HTTP erhalten, etwa die Semantik von Requests und Response. Im SPDY-Whitepaper, das auf der Homepage verlinkt ist, berichten die Autoren von bis zu 64 Prozent kürzeren Seitenladezeiten, das ausgesprochene Ziel sind im Durchschnitt 50 Prozent. Dazu beitragen soll Stream-Multiplexing, das über eine einzige TCP-Verbindung alle Anfragen abwickelt, die gleichzeitig weniger Pakete erfordern. Die Priorisierung von Requests soll dafür sorgen, dass wichtige Anfragen gegenüber anderen bevorzugt behandelt werden. Schließlich komprimiert SPDY die übertragenen HTTP-Header, um das Datenaufkommen zu reduzieren. Auch vom Server initiierte Verbindungen will SPDY erlauben und damit zahllose Hacks der Vergangenheit wie Comet und Co. überflüssig machen. Dabei soll das Web nicht nur schneller, sondern auch sicherer werden, wozu SPDY als Transportschicht auf SSL-gesicherte Verbindungen setzt.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe /2014

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit Rex
  • mit anderer Konfigurationsmanagement-Software