Immer mehr Content muss dem Benutzer via HTTP übermittelt werden. Zwar werden die Netzverbindungen immer schneller – trotzdem müssen auch geringere Bandbreiten bedient werden. Da stellt sich die Frage: Was tun, wenn die Menge der Daten nicht minimiert werden kann?

Im letzten Teil der Netty-Reihe wurde anhand eines Beispiels gezeigt, wie es möglich ist, WebSocket-gestützte Anwendungen zu entwickeln. Ein weiterer Teil der Neuerungen, wenn es um skalierbare und schnelle Webanwendungen geht, soll im Folgenden beleuchtet werden: das Netzwerkprotokoll SPDY. Um das hier gezeigte Beispiel anzuwenden, bedarf es folgender Voraussetzungen:

• Netty 3.5.8. Final oder höher

• NPN-Boot [1]

• NPN-API [2]

Warum SPDY?

SPDY (ausgesprochen „speedy“) wurde von Google entwickelt, mit dem Ziel, Webseiten bzw. Content schneller zur Verfügung zu stellen, und zwar mithilfe mehrerer Aktionen. Zu den Hauptmerkmalen zählen:

• Jede SPDY-Übertragung wird via GZIP komprimiert. Das betrifft Content und die HTTP-Header.

• Jede SPDY-Übertragung wird via TLS verschlüsselt und ist somit vor Abhörversuchen geschützt.

• Mehrere Übertragungen per Verbindung sind möglich.

• Priorisierung der einzelnen Anfragen, um kritische Daten schneller zur Verfügung zu stellen.

Weitere erwähnenswerte Features sind unter anderem:

• Server-Push

• Server-Hint, wodurch es möglich ist, den Client einen Hinweis auf die Daten zu schicken.

Somit sind einige Features durchaus redundant mit denen von WebSockets. Und so sind auch die Anwendungsfälle oft identisch, wie z. B.:

• Chat-Systeme

• Monitoring-Systeme

• Webmail

• Stock-Ticker

Nichtsdestotrotz befinden sich beide oft in Benutzung bei Webseiten oder Webapplikationen, die ihren Nutzern Daten möglichst schnell zur Verfügung stellen wollen. Hierbei wird oft eine Geschwindigkeitsverbesserung von 50 % oder sogar mehr erreicht, sobald SPDY eingesetzt wird. Wer einen tieferen Einblick in SPDY erlangen möchte, dem sei das SPDY-Whitepaper [3] ans Herz gelegt.

SPDY und dessen Verbreitung

Da SPDY noch stetig weiterentwickelt wird, ist es kaum verwunderlich, dass es mehrere Versionen in der „freien Wildbahn“ gibt. Sie sind in einzelnen Drafts beschrieben:

• Draft 1 – Erste Version

• Draft 2 – Spezifizierung von Server-Push (u. a.)

• Draft 3 – Hinzufügen von Flow-Control

Genauso wenig verwunderlich ist es, dass Chrome der erste Webbro...