Das Transportprotokoll SPDY verspricht die Anzahl der Verbindungen zu reduzieren, sämtliche Daten zu komprimieren und Server Push zu erlauben. Ob SPDY wirklich das Potenzial hat, das Hypertext Transfer Protocol (HTTP) von seinem Thron zu stürzen, zeigt dieser Artikel.

HTTP ist das Synonym für Internet. Es zählt zu den ältesten Protokollen und hat andere, ähnlich alte Protokolle wie Gopher überlebt. Trotz seiner Beliebtheit (es gibt ja auch keine Alternativen) sieht man dem Protokoll an, dass es für die Übertragung weniger, einzelner HTML-Dateien gemacht wurde. Es heißt ja auch Hypertext Transfer Protocol. Doch heute leistet es weit mehr als das. Um eine einzige Seite anzuzeigen, werden laut HTTP Archive [1] aktuell über 80 Requests gestellt (Abb. 1). Neben Multimediainhalten sind das auch JavaScript- und CSS-Dateien sowie Interaktivität realisierende JSON- oder XML-Übertragungen. Als wahrscheinlich größter Nutzer des Internets beschloss Google 2009 HTTP zu verbessern. Die wichtigsten Designziele waren hierbei, die Anzahl der Verbindungen zu reduzieren, sämtliche Daten zu komprimieren und Server Push zu erlauben. Schnell wurde den Entwicklern bei Google jedoch klar, dass sich HTTP nicht mit einzelnen Verbesserungen aufwerten ließ. Stattdessen wurde der Nachfolger SPDY [2] („speedy” ausgesprochen) entwickelt.

Abb. 1: Verbindungen und Datenmenge pro Webseite (Quelle: httparchive.org)

Viele Verbindungen belasten das Netz

In HTTP 1.0 wird für jede Ressource eine TCP-Verbindung zum Server aufgebaut und nach Übertragung der Ressource auch wieder abgebaut. War das früher mal O.K., ist es heute unbestritten ineffizient, da zahlreiche Ressourcen vom Server heruntergeladen werden. Die HTTP-1.1-Spezifikation erfand dagegen zwei Gegenmaßnahmen:

• Keep-Alive

• Pipelining

Keep-Alive: Keep-Alive wird sehr kontrovers diskutiert, da es bis zum Keep-Alive Timeout eine Verbindung exklusiv für einen Client reserviert. Nach Übertragung der Ressource kann eine zweite auf der gleichen TCP-Verbindung übertragen werden. Jedoch gibt es keine Signalisierung über das Transferende, sodass der Server nicht effizient arbeiten kann. Als Kompromiss werden häufig kleine Keep-Alive Timouts von zwei bis zehn Sekunden verwendet.

Pipelining: Pipelining sendet alle Requests direkt über die gleiche TCP-Verbindung und beendet sie, sobald alle beantwortet wurden. Obwohl das konzeptionell sehr nützlich ist, wird es in der Praxis kaum gemacht. Manche Browser (z. B. Firefox) bieten zwar Support, er i...