Suche

Google SPDY – Http-Alternative auf Erfolgskurs

Hartmut Schlosser

Das in die Jahre gekommene Http bekommt durch den Google-Vorschlag SPDY neue Impulse. Dabei handelt es sich um ein zu Https kompatibles Protokoll, mit dem die Anzahl der Requests reduziert, sämtliche Daten komprimiert und Server Push ermöglicht wird.

Wir haben Sie in einem Quickvote gefragt, welche Chancen Sie dem Google-Protokoll einräumen. Dabei zeichnen Sie durchaus ein positives Stimmungsbild. Hier das Ergebnis im Überblick:

SPDY – Welche Chancen hat Googles Http-Nachfolger?

  • SPDY verfolgt einige interessante Ansätze und wird sich als Http-Alternative in gewissen Kreisen etablieren. Ein Http-Nachfolger ist es aber nicht. (35%)
  • SPDY hat das Potenzial, Http abzulösen und die gesamte Webentwicklung beträchtlich voranzubringen. (30%)
  • Wir brauchen keine Google-Alleingänger-Technologie. Man täte besser daran, Http gemeinsam zu verbessern. (15%)
  • Mit SPDY geht man technologisch den falschen Weg. (3%)
  • SPDY? Hab ich mich noch nicht mit beschäftigt. (17%)
  • Teilnehmer: 185

Anzumerken ist an dieser Stelle, dass SPDY bereits in einer Vielzahl von Browsern implementiert ist (z.B. Chrome, Firefox, Opera, Ice Cream Sandwich, Amazon Silk (Kindle Fire)). Dabei muss SPDY Http nicht unbedingt „ablösen“. Zum einen ist das Protokoll rückwärtskompatibel zu Https. Zum anderen zeichnet es sich ab, dass SPDY als Support Standard in Http 2.0 aufgenommen werden wird.

Für SPDY-Neulinge hier nochmals eine kurze Charakterisierung. Das 2009 von Google ins Rennen geschickte SPDY adressiert die folgenden Probleme:

  • Im Http-Protokoll gibt es traditioneller Weise nur einen Request (Get) auf einmal – bei vielen Bildern bedeutet das: viele Gets hintereinander
  • Requests sind nur vom Client aus möglich, nicht vom Server
  • Header-Daten werden nicht komprimiert
  • Viel Header-Daten sind redundant
  • Datenkompression ist bei http nur optional

Zur Reduzierung der Requests implementiert SPDY ein Verfahren, das dem seit Http 1.1 bekannten Pipelining ähnelt. Es baut eine einzige TCP-Verbindung auf, über die dann alle Requests laufen. 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.

Für die bidirektionale Kommunikation zwischen Server und Client wird traditioneller Weise das so genannte Long Polling verwendet: Der Browser öffnet einen Request zum Server, rechnet aber bei der Anfrage damit, dass die Antwort lange auf sich warten lassen kann. Liegen Daten auf dem Server vor, so werden diese übertragen, der Request ist abgearbeitet und die Verbindung wird 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 das Konzept „Server Hint“: Es werden nicht gleich alle Daten übertragen. Stattdessen wird dem Browser signalisiert, dass Daten bereit liegen.

Im Gegensatz zu Http ist in SPDY die Komprimierung von Daten nicht optional, sondern der Standard. Alle Daten werden ZLib-komprimiert übertragen, auch die Header-Daten. Beispielsweise werden so größere Cookies schneller übertragen.

Im Web finden sich offizielle Ressorcen zu SPDY unter http://dev.chromium.org/spdy/ und in einem Whitepaper unter http://dev.chromium.org/spdy/spdy-whitepaper.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.