Google erfindet SPDY - was ist da wirklich dran?

[Felix Riesterer]

Liebe Mitlesenden,

heute bin ich auf Heise.de über eine Meldung zu Googles SPDY-Projekt gestolpert. Da ich in Sachen HTTP nicht besonders firm bin, kann ich nicht beurteilen, ob diese Idee wirklich soviel Erfolg verspricht, oder ob die Idee bereits vorhandene Probleme nicht noch verschlimmbessert.

Wer kennt sich da besser aus und kann mir sagen, welchen Vorteil SPDY gegenüber gzip-komprimierten HTTP-Responses hat und inwieweit mich das in Sachen serverseitiger Scriptsprachen betreffen könnte?

Liebe Grüße,

Felix Riesterer.

[Joe A]

Hallo ihr Diskutierenden!»» Liebe Mitlesenden,

Wer kennt sich da besser aus und kann mir sagen, welchen Vorteil SPDY gegenüber gzip-komprimierten HTTP-Responses hat und inwieweit mich das in Sachen serverseitiger Scriptsprachen betreffen könnte?

Also ich denke das gerade bei Skriptsprachen wie PHP SPDY etwas nutzen wird.
Grundgedanke ist ja die persistente Verbindung, die es ermöglicht die einzelnen Dateien schneller holen zu können (Styles, Skripte, Bilder).

Gerade für Seiten ohne ausgereiftes Caching-System wird sich das schon lohnen. Gerade diese Projekte sind oft nicht sehr groß und auf langsameren Servern.

Tschüss ihr Diskutanten!

[Kai345]

[latex]Mae  govannen![/latex]

heute bin ich auf Heise.de über eine Meldung zu Googles SPDY-Projekt gestolpert. Da ich in Sachen HTTP nicht besonders firm bin, kann ich nicht beurteilen, ob diese Idee wirklich soviel Erfolg verspricht, oder ob die Idee bereits vorhandene Probleme nicht noch verschlimmbessert.

Ich kenne nicht fefes Qualifikation bezüglich HTTP, er sieht es jedenfalls kritisch

Cü,

Kai

[Beat]

Ich kenne nicht fefes Qualifikation bezüglich HTTP, er sieht es jedenfalls kritisch

Mich erinnert das an AJAX.
Am Ende musst du zweigleisig entwickeln. Einmal Spitty und einmal trocken.

mfg Beat

[ChrisB]

Hi,

Ich kenne nicht fefes Qualifikation bezüglich HTTP, er sieht es jedenfalls kritisch

Wenn der Aspekt, dass Werbung ge„push”t werden könnte, der Hauptkritikpunkt ist - dann sehe ich die Auseinandersetzung damit als eher unbrauchbar an.

Dass der „zentrale Vorteil” von Werbeblockern wegfiele, wenn die Seite mit Werbung genauso schnell lädt wie ohne, ist ein vollkommen blödsinniges Argument.
Wenn fefe derzeit seinen Werbeblocker *ausschliesslich* deshalb einsetzt - dann kann er sich freuen, wenn er dadurch überflüssig wird.
Wenn er ihn jedoch noch aus anderen Gründen einsetzt - weil er Werbung nicht sehen will, weil der damit einher gehendes Tracking nicht akzeptieren will - dann wird er Werbung auch weiterhin blocken können, egal ob sie jetzt gepusht wird oder nicht.

Insb. initiale Ladezeiten von umfangreichen Seiten sind seit längerem ein Thema, an dem geforscht und gearbeitet wird. Wenn jetzt jemand einen Weg entwickelt, diese klein zu halten, in dem dem Client früher mitgeteilt wird, welche externen Ressourcen noch dazu gehören (CSS, Scripte, Bilder), dann sehe ich das erst mal positiv.

Davon, Caching-Mechanismen vollkommen ausser Kraft zu setzen (fefes SPON-Logo-Beispiel) sehe ich in dem Entwurf jedenfalls nichts.

MfG ChrisB

[suit]

Wenn er ihn jedoch noch aus anderen Gründen einsetzt - weil er Werbung nicht sehen will, weil der damit einher gehendes Tracking nicht akzeptieren will - dann wird er Werbung auch weiterhin blocken können, egal ob sie jetzt gepusht wird oder nicht.

Davon, Caching-Mechanismen vollkommen ausser Kraft zu setzen (fefes SPON-Logo-Beispiel) sehe ich in dem Entwurf jedenfalls nichts.

Wieso - woher soll der Server wissen, was der client im Cache hat oder der Client tatsächlich benötigt?

Aktuell kann ich meinen Client derart Konfigurieren, sodass er bestimmte Ressourcen blockt, die einem bestimmten Muster entsprechen, von einem bestimmten Host kommen usw.

Wenn ich pauschal mal einfach "alles" geliefert bekomme, kann ich zwar die Inhalte nachher dennoch blockieren und nicht anzeigen lassen, übertragen werden müssen sie trotzdem. Dass das im Schnitt ggf. traffic spart - besonders bei einmal-Besuchern - eben jenen Besuchern die aus einer Suchmaschine kommen und nur eine oder zwei Seiten ansehen mag schon stimmen. Bei tieferen Besuchen und längeren Sessions schwindet der Vorteil aber sehr schnell wieder.

[dedlfix]

Hi!

Davon, Caching-Mechanismen vollkommen ausser Kraft zu setzen (fefes SPON-Logo-Beispiel) sehe ich in dem Entwurf jedenfalls nichts.
Wieso - woher soll der Server wissen, was der client im Cache hat oder der Client tatsächlich benötigt?

Muss er nicht. Der Client teilt dem Server mit, dass er etwas bestimmtes vom Server Angebotenes nicht haben möchte, worauf der Server das Senden dieser Ressource einstellt.

Aktuell kann ich meinen Client derart Konfigurieren, sodass er bestimmte Ressourcen blockt, die einem bestimmten Muster entsprechen, von einem bestimmten Host kommen usw.

Nein, das wäre der zukünftige Fall mit SPDY, denn derzeit "kommt" nichts sondern muss angefordert werden. Du kannst also deinem Client nur sagen, er möge bestimmte Ressourcen gar nicht erst anfordern, obwohl eine andere Ressource drauf verlinkt.

Wenn ich pauschal mal einfach "alles" geliefert bekomme, [...]

Irrelevante Argumentation. Lies doch erst einmal die Beschreibung anstatt über Dinge zu mutmaßen, die nicht vorgesehen sind. (Speziell der Punkt Prefetching/server push, ziemlich am Ende.)

Lo!

[LX]

Hallo, Felix!

Einerseits ist eine Komprimierung und Ausdünnung der Header gerade für langsame Verbindungen durchaus positiv, andererseits wird für jede solche Verbindung, solange sie aufrechterhalten wird, ein Thread benötigt, was erhebliche Serverlast verursacht - und einen DDOS-Angriff noch wirkungsvoller werden läßt.

Die einzige wesentliche Verbesserung besteht darin, dass mehrere Dateien über den gleichen Verbindungszustand geholt werden können - und das hätte man ebenso mit einer Art MultiPart-Requests, die zu normalen HTTP-Requests kompatibel sind, regeln können. Server und Browser, die derartige Requests nicht beherrschen, machen dann weiter wie bisher.

Die Komprimierung auch der Header hätte man mit einem HTTPZ-Protokoll, welches ansonsten zum HTTP-Protokoll identisch ist, regeln können. Insofern ist SPDY ein extremes Vorpreschen, bei dem viel Porzellan zerschmissen wird. Derartige Un-Standards haben im Internet nichts zu suchen.

Abgesehen davon: mit Comet besteht bereits die Möglichkeit, Verbindungen für den beiderseitigen asynchronen Datenaustausch aufrecht zu erhalten, so dass auch dieser Grund hinfällig wird.

Gruß, LX

[Cheatah]

Hi,

Die einzige wesentliche Verbesserung besteht darin, dass mehrere Dateien über den gleichen Verbindungszustand geholt werden können

das ist nicht ganz richtig. SPDY erlaubt zusätzlich einen Server-Push, was in HTTP derzeit komplett fehlt - damit wäre also ein HTTP-basierter Chat endlich sinnvoll umsetzbar. Ferner wäre es denkbar, dass bei einer Anfrage "liefere mir Seite XYZ" gleich die Antwort käme "hier hast Du sie, oh, und da gibt's noch eine CSS- und eine JavaScript-Ressource, die Du auch haben solltest". Natürlich ergeben sich daraus Folgeprobleme, wenn man den Traffic sinnvoll organisieren möchte.

Die Komprimierung auch der Header hätte man mit einem HTTPZ-Protokoll, welches ansonsten zum HTTP-Protokoll identisch ist, regeln können.

So identisch kann es nun auch nicht sein, wenn man es ermöglichen möchte, das ständige Neusenden der immer selben Header zu unterlassen. Bei SPDY können User-Agent-, Accept-Header usw. nach dem ersten Mal weggelassen werden.

Insofern ist SPDY ein extremes Vorpreschen, bei dem viel Porzellan zerschmissen wird. Derartige Un-Standards haben im Internet nichts zu suchen.

Ich werde mir SPDY noch mal genauer ansehen, aber den Kommentaren nach zu urteilen hat es mit einem Un-Standard wenig gemein, sondern scheint statt dessen eher ausgereift und praxistauglich zu sein.

Abgesehen davon: mit Comet besteht bereits die Möglichkeit, Verbindungen für den beiderseitigen asynchronen Datenaustausch aufrecht zu erhalten, so dass auch dieser Grund hinfällig wird.

Verbindungen ständig ab- und wieder aufzubauen um zu warten, ob der Server einem irgendwann mal was sagen will, ist ebenso wenig eine Lösung, wie jemandem Löcher in den Kopf zu bohren. Comet ist eine Krücke, SPDY definiert ein _stabiles_ Verfahren dazu.

Cheatah

[Tim Tepaße]

Verbindungen ständig ab- und wieder aufzubauen um zu warten, ob der Server einem irgendwann mal was sagen will, ist ebenso wenig eine Lösung, wie jemandem Löcher in den Kopf zu bohren. Comet ist eine Krücke, SPDY definiert ein _stabiles_ Verfahren dazu.

Noch besser wäre es wohl, ein Verfahren zu nutzen, das darauf hin optimiert wurde und gleich auch Unterstützung im BOM spezifiziert; letzteres fehlt in SPDY.

[Tim Tepaße]

Verfahren

Pardon, ich verwechselte die URIs, ich meine natürlich WebSockets.