News Google Chrome ersetzt SPDY durch HTTP/2

[Daaron]

nene, kann mich noch erinnern das im FF es schon aktiviert war und dann die Meldung kam man solle es deaktivieren wegen Sicherheitslücken.

Na die Meldung zeig mir jetzt mal.
Ich weiß von einer einzigen Lücke im Bezug auf SPDY, und das ist ne CRIME-Attacke... die genauso auch bei regulären HTTPS funktioniert. Der Fehler liegt hier in der Kompression.

Aber wenn es jetzt so sicher ist warum wieder ausbauen? Als nächstes kommt dann HTTP2 und hat wieder Bugs.

SPDY wird entfernt, weil es von Anfang an eine Übergangslösung sein sollte, die schlichtweg einen möglichen Weg zu HTTP/2 zeigen sollte. Nenn es Grundlagenforschung.

SPDY in den Clients zu lassen würde Server-Betreiber dazu animieren, weiterhin SPDY-Module in ihren Servern zu verwenden (obwohl diese nicht mehr entwickelt werden), statt HTTP/2-Module zu verwenden. Du hättest also auf Protokoll-Ebene dasselbe Problem, dass man bei CSS mit Vendor Prefixes, vor allem -webkit, hat.
Praktisches Beispiel: Es gibt ein (gut funktionierendes und getestetes) SPDY-Modul für Apache 2.2, aber keines für Apache 2.4. Apache 2.2 selbst ist aber ein Auslaufmodell. Würde SPDY client-seitig jetzt ewig und drei Tage supported, dann würden Serverbetreiber evtl. lieber auf den alten 2.2 mit mod_spdy setzen als auf 2.4 ohne SPDY.

Etwas schneller war es vielleicht was ich da auf der Testseite gecheckt hatte.
Aber so extrem war es nicht. Keine Ahnung wann sich das auswirkt.

- Leere deinen Browsercache komplett.
- Erzeuge einen neuen Tab in Chrome, öffne die Entwickler-Werkzeuge (F12) und aktiviere den Netzwerk-Tab
- Geh auf Facebook oder eine andere SPDY-aktivierte Seite und schau dir die Timeline der verschiedenen Ressourcen an. Achte vor allem auf den Startzeitpunkt des jeweiligen Transfers.

Mach dasselbe jetzt noch einmal, nachdem du SPDY zwangsweise deaktiviert hast. Die Unterschiede sind monströs.

Jetzt überleg mal, was das für einen SERVER bedeutet, der nicht nur dich, sondern n paar tausend andere User mit abspeisen muss.

 

[cbtestarossa]

Denke es wirkt sich eher bei vielen Anfragen aus.
Die ganzen Testseiten sind mir zu ungenau.

Facebook intressiert mich nicht aber ich glaube dir natürlich wenn du sagst es wirkt sich dort gravierend aus.

 

[Daaron]

Nicht nur Facebook verwendet SPDY. Sämtliche Google-Dienste laufen über SPDY, genauso wie z.B. das CDN Cloudflare. Du profitierst großflächig von SPDY, du merkst es nur nicht aktiv. Installier dir mal einen Indikator, der dir SPDY-aktive Server anzeigt. Der Blitz taucht recht oft auf.

Und was ist dir an den Testseiten zu ungenau? Der Untershcied ist nicht nur mathematisch, er ist deutlich sichtbar.
Ein sehr realistisches Beispiel: Eine SSL-aktive Seite bindet 20 winzig kleine Icon-Files (z.B. PNGs) ein, anstatt ein komplexes und kaum wartbares CSS Sprite zu verwenden. Mit HTTP/1 musst du jetzt für alle 20 winzigen Icons komplett einen SSL-Handshake durchführen (1-300ms sind dafür realistisch), für jedes Icon muss ein kompletter HTTP-Request gestartet werden, riesige Mengen an Headern werden übertragen,... Da schickst du dann für ein 2kB großes Icon erst einmal 0.5kB an Headern. Außerdem baut dein Browser nur maximal 5-6 Verbindungen zum Server auf. Erst wenn die ersten 5 Icons da sind, werden die näcshten 5 Handshakes gestartet, Header übertragen und Icons empfangen. Und so weiter, und so weiter,...
So... und jetzt kommt SPDY bzw. HTTP/2, genauer gesagt das Multiplexing, ins Spiel. Du hast bereits einen aktiven SSL Handshake für die Seite an sich. Du hast auch eine offene HTTP-Verbindung. Du hast die meisten Header schon durchgeballert. Alle weiteren Informationen, also die 20 Icons, kannst du jetzt in einen gebündelten Datenstrom verpacken. KEINE zusätzlichen SSL Handshakes, KEINE riesigen Header, KEIN Verbindungs-Limit (weils nur eine Verbindung ist)