Googles neues Protokoll SPDY

[(del)]

Das ist die News.
http://www.golem.de/1112/88182.html

Für mich ein Speichellecken. Wer ist der größte Spendengeber? Das gleiche gilt fpür Apache-Patches dazu, um die Verbreitung aufrechtzuerhalten. Könnte ja sein, daß die Betreiber dann auf was anderss umsteigen.

Warum? Heise liefert leider keine technischen Hintergrundinfos dazu. Die liefert fefe
http://blog.fefe.de/?ts=b402b9c9


In diesem Thread geht es um das "neue" Protokoll an sich - seine Vorteile, Nachteile und Gefahren. Der Anlass dieses Threads steht oben drüber: ab Version 11 kann Firefox auch SPDY. Die Diskussion über Firefox 11 erfolgt hier.

[hell_bird]

Also ich lese ja fefes blog wirklich gerne aber das klingt nach ganz großem Bullshit:

Google schlägt jetzt vor, der Server soll bei der Anfrage nach der Webseite auch gleich ungefragt die ganzen (ungeänderten) Dateien mitschicken. Das mag zwar im Benchmark die Latenz senken, aber es würde das Web-Verkehrsaufkommen im Internet mal eben verdoppeln.

[SavageX]

Auch wenn ich Fefes Blog abonniert habe, weil da mal etwas abseitige Neuigkeiten zu finden sind, spielt er IMHO irgenwie recht häufig Troll. Troll mit Folienhut.

Nur weil das Protokoll es vorsieht, dass der Server gleich Zeug mitpushen kann, heisst das doch nicht, dass der Server das auch machen muss (ist im verlinkten Whitepaper *ausdrücklich* als optional gekennzeichnet). Deshalb greift sein Beispiel "Spiegel Online Logo mit jedem Seitenaufruf, doppelter Internetverkehr" überhaupt nicht, da müsste der Webmaster schon hübsch ungünstig konfigurieren.

Und natürlich möchte Google, dass die eigenen Dienste damit hübsch flutschen, das umschließt *natürlich* auch die Auslieferung von Werbung (die man ja bei Missfallen sowieso blockt). Ist Google etwa die Internet-Wohlfahrt?

Die "Google-Speichellecker"-Schlussfolgerung ist meiner Meinung nach nicht schlüssig. Firefox verliert gerade Marktanteile an Chrome, welcher (auch) dank SPDY z.B. bei Google-Diensten sehr geschmeidig läuft. Es ist nur folgerichtig, wenn Firefox Techniken übernimmt, die die gefühlte Schwuppdizität erhöhen. Für SPDY wird Google keine Extrazahlungen loseisen, die Zahlungen hängen vom Suchaufkommen per Firefox-Suchfunktion ab.

[sei laut]

fefe übertreibt absichtlich, damit die Leute darüber nachdenken. (= verdoppeln ist übertrieben, der Traffic wird aber steigen - da macht selbst Google kein Geheimnis draus)
Das Problem ist, weswegen fefe auch übertreibt, dass viele die Haltung haben "Was von Google kommt, muss gut sein". Das war auch meine erste Reaktion. (also zu sagen, dass SPDY sicher gut wird/ist) Etwas kritisch zu hinterfragen schadet aber nichts.

Was man auch sehen muss, es gibt keinen Grund, HTTP ersetzen zu wollen. Das Protokoll ist etabliert, hat natürlich Altersschwächen, aber ist noch voll funktionsfähig. Und neue Sachen bringen immer Probleme mit der Sicherheit mit sich. Das ist leider so. SPDY kann man also für statische Inhalte gerne nutzen, da ist die Sicherheit egal, aber für den anderen Content sollte man erstmal den Reifungsprozess abwarten und dann Bilanz ziehen.

[SavageX]

Kritisch zu hinterfragen schön und gut (und bei Google auch sicher auch angebracht), nur serviert Fefe hier meiner Meinung nach schon eher vorverpackte Meinung als gut präsentierte Fragen. Er zieht sich irgendwelche Zahlen aus dem Allerwertesten ("Web-Verkehrsaufkommen im Internet mal eben verdoppeln" - hat er das simuliert? Mit welcher Konfiguration?) anstatt z.B. einfach mal zu fragen, was denn die höhere Last für die Infrastruktur darstellt: Das stückchenweise Anfordern von Inhalten über HTTP, womöglich mit vielen aufgemachten Verbindungen - oder das Abfeuern von Inhalten in größeren Stücken ("mehr Inhalt pro Verbindung") ohne Salamitaktik, wobei (je nach Konfiguration) auch mal Inhalte doppelt übertragen werden?

Ich habe dazu wirklich keine gut fundierte Meinung, vermute aber, dass etwas Bandbreite zu "verschwenden" tatsächlich günstiger kommen *kann*, wenn man dafür weniger Anfragen abwickeln muss.

[sei laut]

Gut gemachte Webseiten achten darauf, nicht zuviele Anfragen zu produzieren. Da ist Google übrigens Vorreiter darin und viele eifern dem nach.

Und zu fefe: Google schlägt jetzt vor, der Server soll bei der Anfrage nach der Webseite auch gleich ungefragt die ganzen (ungeänderten) Dateien mitschicken.
Wenn man das so macht (was keiner macht, der sein Gehirn nicht in die 5. Dimension gekokst hat), dann wird der Traffic vielleicht sogar mehr als verdoppelt.
Und da das keiner macht!, ist das natürlich auf die Spitze getrieben. Möglicherweise hat sich fefe da aber auch zu sehr gehen lassen. :D

[Sephiroth]

Bezüglich Werbung pushen:
Browsers receiving a pushed response MUST validate that the server is authorized to push the URL using the browser same-origin [ORIGIN] policy. For example, a SPDY connection to www.foo.com is generally not permitted to push a response for www.evil.com.

Bezüglich doppeltem Traffic:
If the browser accepts a pushed response (e.g. it does not send a RST_STREAM), the browser MUST attempt to cache the pushed response in same way that it would cache any other response. This means validating the response headers and inserting into the disk cache.
...
Implementation note: With server push, it is theoretically possible for servers to push unreasonable amounts of content or resources to the user-agent. Browsers MUST implement throttles to protect against unreasonable push attacks.
http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.3.3


When a SYN_STREAM and HEADERS frame which contains an Associated-To-Stream-ID is received, the client must not issue GET requests for the resource in the pushed stream, and instead wait for the pushed stream to arrive.
...
To cancel individual server push streams, the client can issue a stream error (Section 2.4.2) with error code CANCEL. Upon receipt, the server MUST stop sending on this stream immediately (this is an Abrupt termination).
http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml#rfc.section.3.3.2


Man muß das Thema verstehen, wenn man als Verschieber agieren möchte. SPDY ist eine Technologie und keine Software :|
Tja worum geht es dir denn nun in dem Thread, um SPDY selbst oder um den Einzug bei Firefox? Ich schlage vor die SPDY-spezifischen Beiträge in einen neuen Thread zu separieren.

[Coda]

Meine Fresse, was für ein typischer BH-Erguss mal wieder :facepalm: deluxe.

Das das Ding tatsächlich die Latenz wesentlich senkt (viele HTTP-Requests sind *das* Problem für Webseiten-Performance) und dass es gut ist, dass es SSL vorschreibt wird gar nicht erst in Erwägung gezogen, wenn das BÖSE!!! Google dahinter steckt.

[Gandharva]

Das Protokoll ist bald 2 Jahre alt. 2009 waren das noch echte News. Afaik ist es seit Chrome 11 fest im Browser implementiert.

[foobi]

Nur weil das Protokoll es vorsieht, dass der Server gleich Zeug mitpushen kann, heisst das doch nicht, dass der Server das auch machen muss (ist im verlinkten Whitepaper *ausdrücklich* als optional gekennzeichnet). Deshalb greift sein Beispiel "Spiegel Online Logo mit jedem Seitenaufruf, doppelter Internetverkehr" überhaupt nicht, da müsste der Webmaster schon hübsch ungünstig konfigurieren.

Und natürlich möchte Google, dass die eigenen Dienste damit hübsch flutschen, das umschließt *natürlich* auch die Auslieferung von Werbung (die man ja bei Missfallen sowieso blockt). Ist Google etwa die Internet-Wohlfahrt?
Die Vorteile eines Inhaltsblockers bestehen nicht nur darin Elemente, die ich nicht sehen will auszublenden, sondern die Surfgeschwindigkeit zu erhöhen, den Datenverkehr zu verringern, etc, indem sie erst gar nicht übertragen werden. Wenn der Server sich dazu entschließen kann Daten zu übertragen, ohne dass der Client hierzu eine Anforderung gesendet hat, dann fallen einige dieser Vorteile weg.
Dass diese Vorgehensweise logischerweise nicht verpflichtend sein kann, sondern nur optional ist, hilft nicht, denn die Entscheidung über ihren Einsatz trifft ja der Serverbetreiber.

anstatt z.B. einfach mal zu fragen, was denn die höhere Last für die Infrastruktur darstellt: Das stückchenweise Anfordern von Inhalten über HTTP, womöglich mit vielen aufgemachten Verbindungen - oder das Abfeuern von Inhalten in größeren Stücken ("mehr Inhalt pro Verbindung") ohne Salamitaktik, wobei (je nach Konfiguration) auch mal Inhalte doppelt übertragen werden?
Auch bei HTTP wird nicht für jedes Element eine neue IP-Verbindung aufgebaut. Insoweit dürfte SPDY mehr Last hervorrufen, insbesondere aus Netzsicht.

[(del)]

@Coda
SSL ist momentan quasi am Arsch und der einzige Vorschlag dazu - von Google - ist es den Client ständig prüfen zu lassen, ob das Zertifikat gilt.

Das zum Thema Features und zum Thema Erguss. Für jemanden der sobald es nicht um Grafik geht nicht grad das hellste Stern am Firmament zu sein scheint, halte ich (nicht erst seit heute) deine Supernova-Textbausteine für übermutig.

@SavageX
Die werden schon das pushen "was es bringt"... Jeder andere Gedanke fällt unter kindliche Naivität. Oder halt Coda-like.
p.s.:
Ah, foobi hats ja schon fein gebracht. Hab ich garnicht vernommen.

[Benedikt]

Meine Fresse, was für ein typischer BH-Erguss mal wieder :facepalm: deluxe.

+1 :ubeer:

Auch wenn die Integration in FF11 absolut zu befürworten ist: SPDY ist aber kein Allheilmittel - Amazons Silk lässt grüßen...

[(del)]

Ah na guck
"Browsers MUST implement throttles to protect against unreasonable push attacks."
Neue Sicherheitslücken tun sich auf. Serverseitig wie clientseitig. "SPDY stealth push attacks" :ulol: Alte Probleme mit neuen Problemen lösen. Erstklassig...

edit:
Wenn die Browser das blocken können, ballert das erstmal trotzdem durch die Leitungen bis hierhin. Und dann bin ich noch gespannt darauf, ob der Push auf die IP dann auch garantiert aufhört, wenn man die Domain verläßt...

@Sephiroth
Ja könnte man machen, aber nicht zwingend. Wenn du grad Zeit hast, dann gibts bestimmt sinnvolleres
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=516581

[Coda]

Realitäts-Update: Es gibt auch Websockets, da braucht es kein SPDY dazu. Und es hindert auch niemand jemand einen Webserver zu programmieren, der beim Zugriff mit DoS auf die Client-IP anfängt.

Ich wüsste auch nicht was es einer Webseite abseits einer Script-Kiddie-Nummer bringen sollte deine Leitung zu saturieren. Und natürlich hört der Push auf, wenn die Verbindung getrennt wird. Wir reden hier von TCP, nicht UDP.

SSL ist momentan quasi am Arsch und der einzige Vorschlag dazu - von Google - ist es den Client ständig prüfen zu lassen, ob das Zertifikat gilt.
Genau. Weil es unbestrittene einige Probleme mit dem Vertrauen-System bei SSL gibt, kippen wir Authentifizierung und Verschlüsselung in den Müll und übertragen unsere Bankdaten, Logins und Cookies künftig wie echte Männer im Klartext.

Denn schließlich wird jede einzelne Verbindung durch mindestens drei Man-In-The-Middle-Server geroutet (u.A. Area 51, die Mafia und die Illuminati).

Amazons Silk lässt grüßen...
Damit habe ich tatsächlich ein Problem. Alle Daten durch die Amazon Cloud ist etwas heftig.

[SavageX]

Die Vorteile eines Inhaltsblockers bestehen nicht nur darin Elemente, die ich nicht sehen will auszublenden, sondern die Surfgeschwindigkeit zu erhöhen, den Datenverkehr zu verringern, etc, indem sie erst gar nicht übertragen werden. Wenn der Server sich dazu entschließen kann Daten zu übertragen, ohne dass der Client hierzu eine Anforderung gesendet hat, dann fallen einige dieser Vorteile weg.
Dass diese Vorgehensweise logischerweise nicht verpflichtend sein kann, sondern nur optional ist, hilft nicht, denn die Entscheidung über ihren Einsatz trifft ja der Serverbetreiber.


Wenn unterm Strich die Seite trotzdem schneller lädt...

Letztlich wird der Webseitenbetreiber das so ausbalancieren, dass die Seite am schnellsten lädt und seine Volumenkosten noch im Rahmen bleiben.

Da Werbung von ad-Networks geliefert werden, können die übrigens nicht in Deine "content-Verbindung" pushen. Die blockst Du wie gehabt.



Auch bei HTTP wird nicht für jedes Element eine neue IP-Verbindung aufgebaut. Insoweit dürfte SPDY mehr Last hervorrufen, insbesondere aus Netzsicht.

Nicht für jedes Element, aber so zwischen vier und acht Verbindungen, um parallel laden zu können. Eine Verbindung aufzubauen ist übrigens ziemlich verbose.

[Sephiroth]

edit:
Wenn die Browser das blocken können, ballert das erstmal trotzdem durch die Leitungen bis hierhin. Und dann bin ich noch gespannt darauf, ob der Push auf die IP dann auch garantiert aufhört, wenn man die Domain verläßt...

Bitte lies doch erstmal die verlinkten Specs weiter. Dort steht, dass zunächst ein SYN_STREAM Paket gesendet wird, bevor irgendwelche (großen) Daten gepusht werden. Will der Client diese nicht Empfangen, sendet er unmittelbar eine RST_STREAM Response mit einem Fehlercode. Dadurch wird verhindert das der Content vom Server gesendet wird. Natürlich kann es nicht-konforme Server geben die den Content trotzdem pushen aber das dürften Einzelfälle mit bösen Absichten sein.

Übrigens habe ich den Thread (erneut) verschoben und im Eingangsposting klargestellt, dass es hier doch primär ums das Protokoll selbst geht.

[foobi]

Durch Verschieben in ein totes Unterforum kann man Themen auch loswerden...

Da Werbung von ad-Networks geliefert werden, können die übrigens nicht in Deine "content-Verbindung" pushen. Die blockst Du wie gehabt.
Es gibt kein Naturgesetz, dass nicht erwünschte Elemente auf einer Seite von fremden Webseiten stammen müssen, die können genausogut über die selbe Domäne ausgeliefert werden. Was die ursprüngliche Quelle ist, ist hiervon ja unberührt.
Selbst auf den Fall Werbebilder beschränkt stimmt das beispielsweise auf eben dieser Webseite hier nicht, die Werbung wird unter anderem auch über forum-3dcenter.org übermittelt. Und wenn es sich dank SPDY als lohnenswertes Geschäftsmodell herausstellen sollte, Werbung über die gleiche Domäne auszuliefern, wird man dies zukünftig noch häufer sehen.

Abgesehen davon, stellt der aktuelle Entwicklungsstand von SPDY nicht das Ende dar, sondern erst den Anfang.

[(del)]

Natürlich kann es nicht-konforme Server geben die den Content trotzdem pushen aber das dürften Einzelfälle mit bösen Absichten sein.Geht es vielleicht primär um eben sowas? :|

Sonst ist mir foobi grad zum zweiten Mal davorgekommen.

[Coda]

Es geht primär darum unnötige Latenzen zu vermeiden, indem weniger Verbindungen aufgebaut und das Protokoll weniger geschwätzig ist. Das ist übrigens auf allen SSL-Seiten von Google auch schon ausgerollt.

[MartinB]

Das klingt recht interessant. Ich behandel in meinem Studium grade das OSI-Schichtenmodell und habe mich immer gefragt ob es nicht höllisch ineffizient ist so viele Verbindungen aufzubauen und so viel Overhead zu erzeugen.

Scheinbar schon.


Dass natürlich Google das Protokoll nutzt um Bandbreite zu sparen und um Chrome schneller zu machen ist ja nichts verwerfliches. Den Vergleich mit Amazon Silk finde ich etwas daneben, denn SPDY ist ja eine offene Schnittstelle und letztendlich hat dadurch jeder nu Vorteile.

[Sephiroth]

Geht es vielleicht primär um eben sowas? :|

Sonst ist mir foobi grad zum zweiten Mal davorgekommen.
Ach und das geht mit HTTP nicht? Es existieren diverse Anti-Caching-Header (Expires: auf 1970, max-age=0 usw) die dafür sorgen, dass der Inhalt immer wieder gezogen wird. Keiner sagt das SPDY der makellose Heiland ist aber gefährlicher als HTTP ist es imho sicher nicht.

[Coda]

Der Cache wird erst verwendet, wenn der Tag den der Browser per Header bekommt stimmt. Das heißt ein voller Roundtrip Latenz.

[Demirug]

Der Cache wird erst verwendet, wenn der Tag den der Browser per Header bekommt stimmt. Das heißt ein voller Roundtrip Latenz.

Wenn man die Daten mit einem entsprechenden Verfallsdatum überträgt fragt der Browser nicht mehr nach bevor dieses erreicht ist und nimmt direkt die Datei aus dem Cache. Wir machen davon recht heftig gebrauch um zu verhindern das bei unseren Webspielen jedes Mal das gesamte Assetset angefragt wird. Das wäre zum einen lästig für die Spieler und würde uns unnötige CDN Kosten verursachen. Trotzdem erscheint mir SPDY ein großer Fortschritt gerade für das füllen eines kalten Caches zu sein. Leider wird es noch nicht von den großen CDN Providern unterstützt.

[steve.it]

Auch wenn ich Fefes Blog abonniert habe, weil da mal etwas abseitige Neuigkeiten zu finden sind, spielt er IMHO irgenwie recht häufig Troll. Troll mit Folienhut.


Er schreibt auch folgendes:

"Der Fokus liegt auf Spaß und thematischer Breite, nicht so sehr auf Fakten, journalistischer Sorgfalt oder ähnlichen Unterhaltungsbremsen. Nachlesen und herausfinden, was wirklich passiert ist, sollt ihr schließlich selbst :-)"
http://alternativlos.org/
(in Blog auf Alternativlos rechts oben klicken).

[SavageX]

Er schreibt auch folgendes:

"Der Fokus liegt auf Spaß und thematischer Breite, nicht so sehr auf Fakten, journalistischer Sorgfalt oder ähnlichen Unterhaltungsbremsen. Nachlesen und herausfinden, was wirklich passiert ist, sollt ihr schließlich selbst :-)"
http://alternativlos.org/
(in Blog auf Alternativlos rechts oben klicken).

Ich wünschte das würden die ganzen Leute berücksichtigen, die ein fachlich-kritisches Gespräch mit "Fefe sagt..." torpedieren, ohne anschließend einen eigenen Blickpunkt darstellen zu können :)

[TechnikJunkie]

wir werden sehen was das ganze in der Zukunft bringt.... oder? :)

[mekakic]

Laut about:config ist Speedy bei Fx14 eingeschaltet und lt. http://browserfame.com/527/twitter-spdy-support soll es in den HTTP Header einen X-Firefox-Spdy: 1 Eintrag geben. Den haben ich aber bei Google oder Twitter noch nicht gefunden.

Mache ich was falsch oder ist der X-Header seit SPDY standardmäßig aktiv ist wieder weg?

[mekakic]

^^
weiß das jemand?

[Coda]

Die Konzepte von SPDY werden übrigens wohl in HTTP 2.0 integriert.