Jeder, der sich im Netz bewegt, hat die 4-stellige Buchstabenkombination schon einmal gesehen oder in die Adresszeile seines Browsers eingetippt: HTTP. Doch weißt du, was es damit wirklich auf sich hat? Wenn du nun stürmisch mit dem Kopf nickst: Herzlichen Glückwunsch! Dann gehörst du zu einem erlauchten Kreis von geschätzten fünf Prozent der Internetnutzer. Nicht zuletzt, weil einem der Browser die Tippperei in der Regel abnimmt.
Und nun zur Auflösung: Einfach ausgedrückt wird ein Protokoll definiert, das beschreibt, auf welche Weise man die Daten von einem Server geliefert bekommen möchte. Das Hypertext Transfer Protocol (HTTP) ist eines dieser sogenannten Protokolle. Zusammen mit der Hypertext Markup Language (HTML), die zur Darstellung eines Webinhalts dient und dem Uniform Ressource Locator (URL), welcher die Adressierung der Inhalte übernimmt, stellt HTTP – als Übertragungsstandard – die Grundpfeiler des World Wide Web dar. Und darauf stützt es sich noch heute.
HTTP wurde 1996 unter anderem von Tim Berners-Lee am CERN entwickelte und in der Version 1.0 veröffentlicht. Das ist nun achtzehn Jahre her: Zeit erwachsen zu werden!
Und langsam werden die Kinderschuhe doch zu klein.
Hauptgrund für eine Weiterentwicklung des Protokolls (der erst Zweiten nach HTTP/1.1 im Jahr 1999) ist vorallem die langsame Geschwindigkeit. HTTP stammt aus einer Zeit, in der Webseiten – für deren laden HTTP hauptsächlich verwendet wird – noch sehr einfach "gestrickt" waren.
Eine Seite bestand in der Regel aus:
- einer HTML-Datei
- einer CSS-Datei
- einigen Bildern
- und vielleicht noch einem Javascript-File
Nach nur wenigen Anfragen waren alle Antworten vom Server da und die komplette Seite geladen. Genau dieses Frage-Antwort-Spiel zwischen dem Browser und dem Server sorgt jedoch heute für einen großen Overhead an Übertragungsdaten beim Laden einer komplexen Website. Denn sowohl beim Request (der Anfrage an den Server) als auch beim Response (der Antwort vom Server) werden nicht nur die reinen Nutzdaten, sondern auch eine erhebliche Menge an Informationen zur Verarbeitung versendet. Diese weisen aber eine hohe Redundanz auf.
Mit dem Entwurf für die Weiterentwicklung von HTTP hat Google eine Lösung für dieses Problem vorgestellt: SPDY. Angelehnt an das englische "speedy" wird das Laden mehrerer Ressourcen über ein und dieselbe TCP-Verbindung ermöglicht. Um einzelne Daten trotzdem vorrangig zu laden, können die Ressourcen priorisiert werden – zum Beispiel um von vornherein ein CSS-Layout bereitzustellen.
SPDY: schneller, direkter - einfacher!
Aus dem SPDY-Entwurf sollen außerdem "Server Push Transactions" mit einfließen. D.h. der Server hat direkt die Möglichkeit bestehende Verbindungen offen zu halten und mehrere Antworten auf eine Anfrage zu senden - ohne Umwege über z. B. Websockets.
Auf die Vorteile gegenüber AJAX und die Notwendigkeit einer "bi-direktionalen Verbindung" im Bereich von Webanwendungen wurde schon in einem unserer früheren Blogs Bezug genommen.
Google SPDY vs. Microsoft SM, oder: Wer schafft es in die letzte Runde?
Einen Gegenentwurf zu Googles SPDY veröffentlichte Microsoft mit seinem Protokoll Microsoft Speed + Mobility (Microsoft SM). Und verfolgt damit ebenfalls das Ziel, die Ladezeiten des bisherigen Standards zu verkürzen. Zwar baut Microsoft SM auf SPDY auf, unterscheidet sich aber in manchen Punkten erheblich. So z.B. bei der Option der Verschlüsselung der Datenübertragung: Microsoft überlässt diese Entscheidung den Endpunkten, während SPDY standardmäßig die Daten verschlüsselt.
Damit will Microsoft leistungsschwächeren Endgeräten - wie z.B. Mobiltelefonen - entgegenkommen. Denn eine Verschlüsselung nimmt immer Ressourcen der CPU in Anspruch. Außerdem befürwortet Microsoft ausdrücklich die Nutzung von Websockets und sieht in "Server Pushs" eine Verfehlung der Semantik von HTTP.
Und das wird kommen! Meine Prognosen.
An welchem der beiden Entwürfe sich die IETF-Arbeitsgruppe HTTPBIS letztendlich eher orientieren wird, bleibt abzuwarten. Sicher ist, das HTTP/2.0 seinen Vorgänger ersetzen soll und daher zu 100% abwärts kompatibel sein muss. Für den Umstieg auf HTTP/2.0 ist aber unabdingbar, dass Client und Server schon vor Verbindungsaufbau miteinander "aushandeln" über welches Protokoll sie nun miteinander kommunizieren. Hier wird wahrscheinlich das von Microsoft entwickelte Application Layer Protocol Negotiation (ALPN) zum Einsatz kommen. Dieses sieht vor, dass der Client dem Server eine Liste von unterstützenden Protokollen mitteilt und der Server sich für eines davon entscheidet.
Leider gibt es über ALPN noch kaum genauere Infomationen. Einen ersten Eindruck kann man sich aber hier verschaffen.
Hands on! Es darf getestet werden.
Was die Zukunft von SPDY betrifft, so wird das Protokoll auf jeden Fall als "Spielwiese" für weitere Entwicklungen von Google zu Verfügung gestellt. Zum Abschluss ein Link um SPDY mal SCHNELL zu testen: https://ist-spdy-aktiviert.de
Und was denkt ihr? Ich bin gespannt auf euer Feedback!
