"SPDY"

Google will das Web flotter machen

Andreas Proschofsky, 13. November 2009 09:42
  • Artikelbild
    grafik: archiv

    SPDY: Ein Webprotokoll so flott wie die schnellste Maus von Mexiko

Neues Protokoll optimiert HTTP und sorgt so für Beschleunigung - Alle Verbindung werden verschlüsselt übertragen

Bei Google will man offenbar wirklich keine Ebene auslassen, um die Web-Benutzung flotter zu machen: So widmet man sich nicht nur seit vergangenem Jahr einem eigenen Browser, dank SPDY (ausgesprochen "speedy") soll nun gleich die gesamte Web-Kommunikation beschleunigt werden.

Optimierungen

Dabei handelt es sich um eine Optimierung des Hypertext Transfer Protocols (HTTP), das heutzutage für die Kommunikation zwischen Clients und Web-Server zuständig ist. Freilich haben sich zwischenzeitlich die Anforderungen in diesem Bereich massiv verändert, immer mehr Dateien sollen gleichzeitig übertragen werden, eine Situation in der bei HTTP ein veritabler Overhead entsteht.

SSL

SPDY verwendet zwar ebenfalls HTTP-Header und Methoden, die Verbindungsaufnahme und den Transfer hat man aber umgestaltet. So werden alle Anfragen in eine SSL-verschlüsselte Session zwischen Server und Client gepackt, der Overhead wird durch Komprimierung weiter minimiert.

Abwägungen

Zwar erhöht der Einsatz von SSL die Latenz wieder ein stückweit, bei Google hält man die verschlüsselte Übertragung aber für essentiell in Hinblick auf die Zukunft des Webs, hat sich also bewusst für diesen kleinen Performance-"Nachteil" entschieden. Trotzdem könnte dies zumindest anfänglich eine Hürde für SPDY darstellen, erhöht sich doch so der CPU-Bedarf sowohl am Server als auch auf dem Client - und das kann ja durchaus auch ein Smartphone sein.

Beschleunigung

Die Vorteile in Hinblick auf die Übertragungsgeschwindigkeit scheinen sich hingegen durchaus sehen lassen zu können: Um bis zu 55 Prozent schneller seien SPDY-Übertragungen in den eigenen Tests gewesen, so Google. Als Basis habe man hier die 25 weltweit meistbesuchten Webpages genommen.

Testen

Für eine reale Nutzung von SPDY müsste das Protokoll sowohl auf den Servern als auch im Browser unterstützt werden, für beides will Google Referenz-Implementationen als Open Source veröffentlichen. Für Google Chrome ist der entsprechende Code bereits verfügbar, ein Web-Server mit SPDY-Support soll in Kürze folgen. (apo, derStandard.at, 13.11.09)

Link

Google Chromium Blog: A 2x Faster Web

derStandard.at/Web auf Facebook
Kommentar posten
Posting 1 bis 25 von 99
«‹›»
1 2 3
Sir Harry....
14.11.2009 14:56
Man kann aber die Datenmenge im Internet auch anders reduzieren:

- weniger sinnlose Werbung (mehr Werbung auf den Seiten bedeuten nicht automatisch mehr Einnahmen),

- Weniger Animationen, Bilder uns Skripte,

Aber vor allem: was frisst zur Zeit die meiste Bandbreite? Es sind doch nicht die lächerliche Datenmengen, die für die Darstellung der Seiten notwendig sind!

Jede Seite kann man mit einer 2Mbit-DSL-Anbindung ausreichend schnell darstellen: vorausgesetzt, der Server kann die Daten auch mit 2Mbit liefern.

Die 6Mbit, 16Mbit und 50Mbit Anschlüsse werden nicht mehr zum Surfen gebraucht, sondern zur schnellen Übertragung von Musik, Filmen usw...

Und genau hier sehe ich die Einsparungen durch die neue Google-Techniken am geringsten.

Also, was soll der Geiz?

erwin meier
14.11.2009 21:58

ihr posting ist auch so eine bandbreitenverschwendung.

Pumuckel Salzstreuer
16.11.2009 16:33
Bin ich nicht Ihrer Meinung...

Sir Harry hat vollkommen recht - weg mit den unnützen animierten Werbebannern und Flashwerbungen - den wohltuenden Effekt für Augen, Bandbreite und Geschwindigkeit können Sie - zumindest zum Teil - im Selbstversuch ausprobieren. Plug-Ins abschalten und siehe da, keine nervenden Animationen, kaum mehr dröge Werbung. Alternativ: am iPhone surfen, das kann nämlich (noch) kein Flash. Und das ist (Zitat Wowereit) gut so.

her wig
14.11.2009 14:10

Google als Innovationsquelle. Android, Chrome, Go, SPDY, ... Und viel davon noch dazu Open Source.

Chakotay
15.11.2009 02:20

ihrer auch

lumbricus
14.11.2009 09:53
Rechenzeit erhöht?

Erhöht das die Rechenzeit für komprimieren und rendern? Wenn ja, heißt das nicht auch, dass mehr Server her müssen? Könnt man da nicht gleich das Netzwerk ausbaun und beim Protokoll bleiben?

Gargan G
13.11.2009 19:58
bin das nur ich...

oder klingt das nach mod_gzip+ssl?

Monopoly mit Hut
16.11.2009 08:12

Im Prinzip ja, aber nicht ganz.

Es ist eher so etwas wie zip + ssl, weil ja alle Daten komprimiert und verschlüsselt über eine einzige Verbindung laufen sollen. Bei mod_gzip wird ja jede einzelne Datei individuell komprimiert, d.h., die Anzahl der Verbindungen ist noch immer gleich hoch wie bei nicht komprimierten Dateien.

fbuchinger
24.11.2009 15:39

ich dachte, eine SSL-Verschlüsselung inkludiert sowieso eine Komprimierung. Redundanzen in der verschlüsselten Nachricht würden es ja einem Angreifer erleichtern, diese zu knacken.

werwolfi
13.11.2009 22:43

falls es wirklich eine protokollerweiterung ist, dann ist es nicht vergleichbar, weil es mehr ist als einfach gezipptes HTML über SSL.

muss man sich genau anschauen...

dr.no3
13.11.2009 18:16
Alle Verbindung werden verschlüsselt übertragen

warum nicht
ich finde auch jetzt schon alle suchen mit googel

monkeybase
13.11.2009 20:10
versteh ich nicht.

someones
13.11.2009 16:22
http optimieren

wie wärs mit http auf ein binäres protokoll umstellen?
wozu soll ich lesbare header verschicken, wenn ich binär nur einen bruchteil verschicken könnte...

1 byte als response ohne inhalt.
(zb im fehlerfall: seite nicht gefunden, zugriff verweigert, ...)

oh ja!
weil jeder seine 404-seite selbst anpassen will...
(was von den meisten browsern so wie so ignoriert wird.)

derKleine
16.11.2009 01:10
404 werden ignoriert??

also meines Wissens macht das nur der dumme IE mit seinem "friendly error". Absolut dumm und unnötig.

Wenn eine Webseite ein nettes 404 ausspuckt, habe ich da gleich einen "Home" Button oder ähnliches.

Bei einer weißen Seite mit "Page not found" habe ich gar nix und muss manuell auf die Startseite zurück.

Wilfried P.
15.11.2009 00:48

Der größte Vorteil von SPDY wäre, dass im Idealfall nur eine Verbindung pro Webseitenaufruf aufgebaut werden muss.

Tatsächlich ist die übertragene Datenmenge von Webseiten heutzutage kaum Ursache für einen langsamen Seitenaufbau. Das Problem ist meist, dass im Worst Case für jedes nochso kleine Element der Webseite eine eigene HTTP-Anfrage an den Server gestellt wird. Zum Beispiel für jedes einzelne Bild, Style-Sheet und .js-File. Auf dieser Seite sind das schon mal weit über 20 Anfragen.

Egal ob Binär, komprimiert oder sonstwie getrickst, es sollte einfach unnötig sein, zig Mal hintereinander (oder gar parallel mit mehreren Verbindungen gleichzeitig) den gleichen Server mit Anfragen zu belästigen, anstatt einmal und dafür richtig.

werwolfi
13.11.2009 22:49

aber geh.

der protokolloverhead (und damit die mögliche einsparung durch ein binärprotokoll) von HTTP ist im vergleich zum typischen HTML/JavaScript/Flash/weißdergeierwasnoch-payload praktisch vernachlässigbar.

dagegen hat ein binäres protokoll sonst nur nachteile - schwerer zu debuggen, nicht selbsterklärend, erzeugungs- und parsing-code ist schwerer zu durchschauen etc.

her wig
14.11.2009 14:06

Naja, nichts was sich durch fachgerechte Programmierung nicht lösen liesse. Das ist wirklich nur eine Frage von Kosten/Nutzen, und eine Umstellung, egal welche, muss schon einiges bringen um sich zu amortisieren.

werwolfi
14.11.2009 16:49

dann lass es mich nochmal kürzer ausdrücken:

binärprotokolle sind (sofern man sich den overhead der expliziten version *einigermaßen* leisten kann) sch**ße.

drwestbahn
13.11.2009 22:16
Ein Paket ist ein Paket ist ein ...

Ob die Antwort jetzt binär oder als Text erfolgt bleibt ziemlich egal, da die Rückmeldungen ja sowieso innerhalb eines Pakets und einer Verbindung stattfinden. Außerdem ist HTTP und HTML im Vergleich zum Bandbreitenverbrauch anderer Anwendungen wie Video, div. Onlinespiele, Flashwerbung etc. nicht einmal ein Tropfen auf den heißen Stein.

/dev/urandom
13.11.2009 21:20
negativ

binäre protokolle sind sch******

das hat .doc zur genüge bewiesen. zurück ans reissbrett.

/dev/urandom
14.11.2009 21:24
Sogar MS hat es verstanden....

... und mit docx und Konsorten von Binärformaten Abstand genommen. Schlecht zu warten, schlecht zu debuggen, egal ob proprietär oder offen.

¤
14.11.2009 17:50

Sie kennen aber hoffentlich schon den Unterschied zwischen "offen" vs. "proprietär" im Vergleich zu "Plain-Text" und "Binary". Das eine hat mit dem anderen rein garnichts zu tun.

socram
13.11.2009 19:40

von welchem browser wird eine angepasste 404 seite, die ja vom server bereitgestellt wird, ignoriert? der browser kriegt ja gar nicht mit, dass es sich um einen 404 handelt.

Cranio-schamanischer Bachblütenakupunkteur C30
13.11.2009 19:51

"der browser kriegt ja gar nicht mit"

Klar kriegt er das mit, er muss ja den Response Code prüfen. HTTP-Spezifikation lesen.

PostIt
13.11.2009 18:53
das is doch wirklich herzlich egal...

bandbreite und rechenleistung wird immer billiger, die menge des contents kann da kaum mithalten.

Kommentar posten
Posting 1 bis 25 von 99
«‹›»
1 2 3

Die Kommentare von Usern und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.

© derStandard.at GmbH 2012 - Impressum

Alle Rechte vorbehalten. Nutzung ausschließlich für den privaten Eigenbedarf.
Eine Weiterverwendung und Reproduktion über den persönlichen Gebrauch hinaus ist nicht gestattet.