Speedy will den Thron besteigen

SPDY – der HTTP-Nachfolger
Kommentare

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.

PHP Magazin

Der Artikel “
Speedy will den Thron besteigen“ von Fabian Lange ist erstmalig erschienen im PHP Magazin 4.2012

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.

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:

1. Keep-Alive

2. 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 TCPVerbindung ü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 ist aber standardmäßig abgeschaltet. Grund für den Misserfolg dürften wohl Proxy-Server und ähnliche Netzelemente sein, die Pipelining nicht unterstützen. Um trotzdem schnell alle Daten vom Server zu erhalten, verwenden Browser heutzutage gleichzeitig mehrere Verbindungen. Das funktioniert zwar, belastet jedoch unnötig Clients, Server und das Netz.

SPDY: SPDY implementiert ein dem Pipelining ähnliches Verfahren. Es baut eine einzige TCP-Verbindung auf, über die dann alle Requests abgewickelt werden. Daten können so in beliebig großen Teilen versendet werden. Auch eine Reihenfolge muss nicht eingehalten werden, da über Sequenznummern die Requests und die Antworten auch in Teilen identifiziert werden können. Auf dieser Verbindung kann der Browser auch QoS über Priorisierung realisieren. Werden zum Beispiel zeitgleich ein Bild und eine JavaScript-Datei angefordert, kann der Browser zuerst das JavaScript anfragen, da es für die Seitendarstellung vielleicht gerade wichtiger ist. Ein weiterer Unterschied zu Keep-Alive ist, es muss nicht erst auf die Antwort des Servers gewartet werden. Übertragungspausen können mit anderen Requests gefüllt werden.

Slow Start beschleunigen

Als zusätzlicher Problemfaktor kommt bei vielen TCP-Verbindungen hinzu, dass als Teil der Flusskontrolle in TCP vorgesehen ist, den Client nicht mit zu vielen Daten vom Server zu überfordern. Deshalb sendet der Server zuerst in kleinen Häppchen und vergrößert die Datenmenge nach jeder Bestätigung durch den Client. Dadurch werden zusätzliche Roundtrips auf dem Netzwerk benötigt. Ebenfalls durch Google getrieben, gibt es deshalb den RFC 3390 [3], in dem vorgeschlagen wird, initial mehr Daten zu senden. So können viele der heute gängigen Anfragen sogar ohne ACK des Clients und damit ohne zusätzlichen Roundtrip beantwortet werden. Mit SPDY wird zwar pro Server nur eine Verbindung benötigt, dennoch wird auch SPDY von einem erhöhten Initial Window profitieren. Eine gute Erklärung zum Einstieg in dieses Thema bietet der Blog von monolight [4].

Alles komprimieren

In HTTP 1.0 und 1.1 war zwar die Komprimierung der gesendeten Daten möglich, jedoch optional. Für ältere Browserversionen wurde sogar empfohlen, bestimmte Datentypen wie CSS oder JavaScript nicht zu komprimieren. In SPDY ist Komprimierung jedoch der Standard. Alle Daten werden ZLib-komprimiert übertragen. Jedoch werden auch die Header-Daten komprimiert, anders als bei HTTP. Größere Cookies werden so schneller übertragen. SPDY geht aber noch einen Schritt weiter: HTTP Requests waren zustandslos. Fragte der Browser ein Bild vom Server an, so wurde beispielsweise erneut der Header „User-Agent“ mitgeschickt, obwohl dem Server das schon bei der Anforderung des HTML mitgeteilt wurde. SPDY verzichtet deshalb auf die erneute Übermittlung gleichgebliebener Header. Sollten die Daten serverseitig benötigt werden, so kann der Server sich diese aus vorangegangenen Requests der gleichen Verbindung holen. Obwohl die eingesparten Datenmengen teilweise relativ klein sein dürften, ist das Prinzip durchaus sinnvoll und konsequent umgesetzt.

Abb. 1: Verbindungen und Datenmenge pro Webseite (Quelle: httparchive.org)
Endlich echter Server Push

Will man vom Server nachträglich Daten über HTTP an den Browser schicken, so bemerkt man schnell, dass das nicht geht. Die Verbindungen wurden abgebaut, nachdem der Browser zufrieden war. Um Server Push zu realisieren, wird deshalb generell auf so genanntes Long Polling gesetzt. Dafür öffnet der Browser einen Request zum Server, weiß aber bereits bei der Anfrage, dass die Antwort lange auf sich warten lassen kann. Es wird also eine leere Verbindung aufrechterhalten. Liegen Daten auf dem Server vor, so können sie zwar übertragen werden, jedoch ist dieser Request dann abgearbeitet, und die Verbindung wird (ohne Keep-Alive) getrennt und muss vom Browser erneut aufgebaut werden.

SPDY nutzt zwar auch eine lang laufende Verbindung, jedoch wird sie für sämtliche Kommunikation bidirektional genutzt und nicht beendet. Das erlaubt nicht nur das Pushen von Daten durch den Server an den Client, sondern auch ein etwas verfeinertes Konzept: Server Hint. Anders als im Modus Server Push werden nicht gleich alle Daten übertragen, sondern es wird lediglich dem Browser signalisiert, dass Daten bereit liegen. Das ist auch nötig, da anders als beim Long Polling der Browser die Daten gar nicht explizit anfordert.

Abb. 2: Ladezeit von blog.codecentric.de in Millisekunden
Bonus: alles verschlüsselt

Aus Gründen des Datenschutzes sollten generell alle übertragenen Daten verschlüsselt werden. HTTPS bietet dafür die notwendigen Werkzeuge. Werden aber viele Verbindungen benötigt, muss der in HTTPS wesentlich teurere Verbindungsaufbau sehr häufig gemacht werden. Im Endeffekt ist die Seite viel langsamer geladen. Bei SPDY wird grundsätzlich alles verschlüsselt.

Durch die Verwendung einer einzelnen Verbindung ist der SSL-Verbindungsaufbau in Summe günstiger und in der Regel durch die Einsparungen bereits rausgeholt. Die genaue Verbesserung hängt von vielen Faktoren ab. Abbildung 2 zeigt als Beispiel den Zugriff von einer DSLAnbindung auf einen bei Amazon in Irland gehostetes Blog. Die Ping-Zeit beträgt 40 Millisekunden. Es ist gut zu sehen, dass HTTPS fast doppelt so lange benötigt wie HTTP. SPDY hingegen kommt mit der Hälfte der Zeit aus.

SPDY als HTTP-Nachfolger

Im Januar 2012 kündigte die W3C Working Group für HTTP 2.0 an, in Gespräche mit SPDY zu treten. Dieser Schritt verlieh dem anfangs Google-proprietären, später jedoch veröffentlichten Protokoll einen offizielleren Status. Der aktuelle Draft 3 für SPDY liegt seit Februar der Internet Engineering Task Force vor [5]. Die Chancen, dass SPDY das Transportprotokoll in HTTP 2.0 wird, stehen gut, denn auch der Browser- und Server-Support sind schon gut: Aktuell finden sich SPDY-Client-Implementierungen in Chrome und Firefox sowie Chrome für Android und dem Kindle Fire. Serverseitig gibt es die Implementierungen in httpd (mod_spdy), netty, node-spdy und erlang-spdy. Für Entwickler und Endanwender ist die Benutzung von SPDY völlig transparent. Wird eine HTTPS-Adresse verwendet, so kann über Next Protocol Negotiation (NPN) [6] auf SPDY gewechselt werden. Der Adaption eines neuen, besseren Protokolls steht also nichts im Weg.

Anm. d. Red.: Mittlerweile ist es offiziell geworden, dass SPDY der HTTP-Nachfolger wird. Der erste Entwurf einer Spezifikation für HTTP 2.0 ist komplett identisch mit der von SPDY. Wir berichteten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -