Google wirbt für SPDY als Grundlage für HTTP 2.0

Google hat ein Protokoll zur Beschleunigung von HTTP-Datenübertragungen entwickelt. Roberto Peon stellte dieses am dritten und letzten Tag der hauseigenen Entwicklerkonferenz Google I/O vor und warb um Unterstützung. Das Protokoll heißt "SPDY", ausgesprochen wie das englische Wort "speedy" für schnell, und bietet grundsätzlich nur TLS-verschlüsselte Verbindungen an. Die Spezifikation SPDY Draft 3 wurde bereits bei der IETF als Vorschlag für das geplante HTTP 2.0 eingereicht. Wichtigster Konkurrent ist Microsoft mit "HTTP Speed+Mobility".

SPDY versucht sowohl Latenz als auch übertragene Datenmengen zu reduzieren. Gleichzeitig sollen aber alle Verbindungen End-to-End-verschlüsselt sein. Das ist dem Ziel der Beschleunigung zwar etwas abträglich, erhöht aber die Sicherheit und kann unter Umständen Probleme mit transparenten Proxys und Firewalls vermeiden helfen. Microsofts Vorschlag greift einige Ideen von SPDY auf, will aber die Verschlüsselung nur als Option anbieten, denn die Datenmengen gerieten dadurch etwas größer, und Ver- und Entschlüsselung würden Rechenkraft kosten und damit bei mobilen Geräten die Akkulaufzeit reduzieren .

Die wichtigsten Kniffe von SPDY sind eine Reduktion der Headergrößen, das Multiplexen von Full Duplex Datenstreams über eine einzelne TCP-Verbindung, das optionale Pushen von Daten vom Server zum Client sowie Priorisierung. Letzteres betrifft sowohl die Reihenfolge des Ladens verschiedener Teile einer Webseite als auch im Rahmen des Multiplexing die Bevorzugung wichtigerer Streams gegenüber weniger dringlichen.

Bei HTTP 1.0/1.1 werden in den Headern immer und immer wieder Daten übertragen, die sich im Laufe einer Sitzung kaum ändern, zum Beispiel Angaben über den Client. Hier wirft SPDY Ballast ab und erreicht laut Peon beim ersten Request eine Reduktion der Headergröße um zehn bis 35 Prozent, bei längeren Sitzungen sollen es 80 bis 97 Prozent sein. Die Gesamtladezeit der Top 100 Webseiten hat sich nach seinen Worten in Tests um 28 bis 64 Prozent reduziert, je nach Konfiguration und Leitung. Guy Podjarny, Chief Architect des Datenverteilers Akamai, beurteilt die Verbesserungen durch SPDY allerdings nicht ganz so optimistisch.

Googles Erhebungen zu Folge bezieht eine durchschnittliche Website derzeit Daten von zwölf Quellen und benötigt 84 Aufrufe. Diese Verbindungen müssen alle ausgehandelt werden – es sei denn, man multiplext verschiedene Datenströme über eine einzelne TCP-Verbindung, wie es SPDY tut. Gleichzeitig verspricht sich Peon ein Ende des derzeit üblichen Auffüllens von TCP-Buffern, das bei länger dauernden Verbindungen zu steigender Latenz führt.

Mehr als eine Milliarde gleichzeitiger, unabhängiger Streams sind in dem experimentellen Protokoll vorgesehen. Diese können bei untereinander priorisiert werden, so dass zeitkritische Dienste vorrangig abgearbeitet werden. Doch auch innerhalb einer einzelnen Webpage kann SPDY Prioritäten setzen: So könnte zunächst der HTML-Code übertragen werden, bevor die Bilder in die Datenleitung gestopft werden. "Entscheidend ist nicht die Ladezeit für die gesamte Seite, sondern die Zeit, bis die Seite nützlich wird", sagte der Google-Entwickler.

Beim optionalen Server Push versucht der Server zu erraten, welche Daten der Client als nächstes brauchen könnte, und schiebt diese selbsttätig in die Pipeline. Dies hilft insbesondere beim ersten Aufruf einer Website. Der Client kann die Übertragung stoppen, wenn er die Daten bereits im Cache hat. Eine andere Option sieht einen "Server Hint" vor. Dabei schlägt der Server dem Client vor, doch bitte bestimmte Daten schon jetzt anzufordern – noch bevor der Client sicher weiß, dass er diese Informationen benötigen wird. Dies kann auf langsameren Verbindungen hunderte Millisekunden sparen und ist vor allem für wiederholte Seitenaufrufe gedacht.

Sowohl Browser als auch Server (samt etwaiger Loadbalancer) müssen SPDY sprechen, damit es funktioniert. Für Apache 2.2 gibt es schon ein optionales Modul, auch der Nginx-Proxy ist mit an Bord. Beispielsweise Google und dessen App Engine, Twitter sowie die Content-Verteiler Akamai und F5 haben SPDY bereits aktiviert. Auf Browserseite sind zumindest Firefox, Chromium/Chrome und Amazon Silk schon dabei.

Peon gab offen zu, dass SPDY nicht alle Probleme löst. Das zugrundeliegende Transportverfahren TCP biete zwar viel Raum für Verbesserungen; doch werde es noch viel länger dauern, dieses abzulösen, als eine neue Version von HTTP zu verbreiten. Auf Leitungen mit sehr hoher Latenz und ebensolchem Packet Loss könne sich SPDY nachteilig auswirken. Keine Vorteile bringe SPDY auch, wenn eine Webpage viele fremde Domains anzapfe, für die das ursprüngliche Verschlüsselungszertifikat nicht gilt, oder wenn es sich um eine sehr einfache Website mit weniger als sechs Teilen handele, die der Nutzer nach einem einzelnen Aufruf wieder verlässt.

Die Arbeit an SPDY ist noch nicht abgeschlossen. Peon möchte gerne auch DNS-Auflösungen sowie Zertifikatsdaten pushen können, und auch eine ausdrückliche Unterstützung für Proxys fehlt noch. (hps)