Google für ein schnelleres und sichereres Web mit SPDY
Zwar ist die News schon ein paar Tage älter, dennoch möchte ich kurz darüber berichten. Google arbeitet derzeit an einem Projekt, das sich SPDY (gesprochen SPeeDY) nennt. SPDY soll das in die Tage gekommene Protokoll HTTP ablösen, das zu den Anfängen des Internets seinen Dienst wunderbar verrichtete, heute aber kaum noch den Anforderungen an moderne Webseiten gerecht wird. HTTP ist ein zustandsloses Protokoll, d.h. es wird keine dauerhafte Verbindung mit dem Webserver aufgebaut, sondern immer nur eine Anfrage abgesetzt, auf die eine Antwort des Webservers erfolgt.
Dadurch wird unglaublich viel Overhead erzeugt (viele unnütze Anfragen), da z.B. für jedes Bild, jede CSS-Datei etc. einer Webseite eine einzelne Anfrage gestellt werden muss. Moderne Browser kompensieren das Ganze ein wenig, indem mehrere Anfragen auf einmal losgeschickt werden (maximal 6), das Problem mit dem Overhead bleibt jedoch. Außerdem können HTTP-Anfragen (HTTP-Requests) und -Antworten (HTTP-Responses) leicht durch einen dritten abgefangen werden und so evtl. kritische Daten (Passwörter usw.) in die falschen Hände geraten, solange der HTTP-Datenverkehr nicht mit Hilfe von SSL verschlüsselt wird (HTTPS).
SPDY möchte diese Nachteile umgehen, indem es folgenden Ansatz verfolgt:
- SPDY baut eine dauerhafte Verbindung zu dem Webserver auf, wodurch viele unnötige Requests entfallen
- Meta-Informationen (die Header einer Verbindung) werden komprimiert übertragen
- doppelte (also unnütze) Header werden entfernt
- Der Datenverkehr wird durchweg per SSL verschlüsselt (Google nimmt hierbei eine etwas erhöhte Latenz für eine erhöhte Sicherheit in Kauf)
- Der Server kann von sich aus Daten zu dem Client senden, wenn dies angebracht erscheint (ich weiß gerade leider kein Beispiel dafür)
Insgesamt finde ich, dass die Idee super ist. Schnellerer Webseiten-Aufbau, höhere Sicherheit, kein unnützer Traffic. Zur schnelleren Verbreitung macht Google den Code frei verfügbar, damit auch andere Browser und auch Webserver SPDY implementieren können. Ob man in Zukunft immer SPDY:// statt HTTP:// vor eine URL schreiben muss, ist abzuwarten. Das wäre meiner Meinung nach ein enormer Nachteil, oder wie oft tippt ihr HTTP:// vor eine URL?
Ich würde die schnelle Verbreitung sehr begrüßen, aber ob sich das Protokoll durchsetzen wird ist natürlich noch unbekannt. Potential hat es auf jeden Fall. Alles zu SPDY könnt ihr auf der Google-Projektseite nachlesen, den Quellcode für einen SPDY-fähigen Chrome gibt es schonmal. Auf die Quellen für Server muss man anscheinend noch warten. Auf dieser Seite hat Google schon ein paar beachtliche Benchmarks zu SPDY veröffentlich.
P.S.: Ob Speedy Gonzales laut CHIP.de der Namensgeber für SPDY ist, konnte ich bisher nirgends nachprüfen.
Empfehlen
4 Kommentare
Eigentlich klingt das wirklich alles ganz schön und toll, aber schon der erste Absatz ist nicht ganz korrekt. Durch HTTP-Pipelining bzw. Keep Alive ist es mit HTTP durchaus möglich eine HTTP Verbindung zwischen Server und Client über längere dauer aufrecht zu erhalten.
Hab da letzt nen interessanten Artikel gelesen, dass XMPP das nächste HTTP sein könnte, woran Google auch nicht ganz unschuldig ist: http://kaffeeringe.de/Blog/XMPP-statt-HTTP.545.html
Ein paar weitere technische Details, wieso das gar nicht so neu ist was Google da vorschlägt, findet ihr bei Fefe http://blog.fefe.de/?ts=b402b9c9
Er kommt zu dem Schluss, das SPDY eigentlich nur ein Trick gegen Werbeblocker ist, was irgendwo auch sinnmacht, verdient Google doch einen Großteil seines Geldes mit Werbung.
Auch das Sicherheitsargument ist etwas scheinheilig, man kann auch heute schon alles mit SSL verschlüsseln, SPDY macht das halt permanent, ist also auch nicht wirklich neu. Zumal die Sicherheit auch nicht wirklich gesteigert wird, da der Webserver für SPDY neue Funktionen implementieren muss, die ihn noch angreifbarer machen.
Ich bin ja mal gespannt wie das auf diesem Gebiet weitergeht
Das Argument gegen Werbeblocker verstehe ich nicht, oder werden damit Werbeblocker gemeint, die vor den Browser geschaltet werden?
Auch das könnte man umgehen, indem die Werbeblocker sich um die SSL-Verbindung kümmern und dann ungesichert an den Browser übergeben (equivalent verhält sich das zu Proxies).
Und damit nicht bei jedem Seitenaufruf jede Ressource geladen wird, kann man sich sicherlich auch noch einiges einfallen lassen, z.B. dass der Client einen Header mit allen verfügbaren Ressourcen + jeweiligem Timestamp übermittelt.
Außerdem lassen sich Header wie z.B. Browser, OS etc. durch die permanente Verbindung sparen.
Das Argument mit dem KeepAlive nützt aber nur insofern etwas, als dass nicht für jeden HTTP-REQUEST eine neue Verbindung aufgebaut werden muss. Die massiven HTTP-Requests bleiben dadurch weiterhin bestehen.
Wenn du z.B. AdBlock Plus benutzt, sparst du die HTTP-GET Anfragen für die gesperrten Elemente einer Webseite. Wenn jetzt aber Google mit SPDY kommt, pushen die dir die Werbung erstmal in den Browser, wodurch unnötig Traffic erzeugt wird und der Seitenaufbau verlangsamt wird. AdBlock würde also keine Geschwindigkeitsvorteile mehr bringen…
Die Ressourcen werden nicht jedes Mal geladen.. lies doch mal bei Fefe… Der Client hat eine Datei, fragt diese beim Server an und sagt von wann seine Datei im Cache ist. Der Server schickt dann entweder die Datei oder sagt einfach “HTTP/1.1 304 Nix Neues”. Also eigentlich genau das was du beschrieben hast
Overhead durch HTTP-Header und Requests kann man im Gegenzug vernachlässigen, die produzieren deutlich weniger Traffic als das sendent von ganzen Dateien die ich nicht brauche oder sogar gar nicht haben will.
Aber stell dir folgende Implementierung vor:
Dauerhafte Verbindung aufbauen -> Anfrage auch Webseite -> HTML kommt -> der Client kümmert sich nun darum, welche Daten angefragt werden sollen und packt diese in eine einzelne Anfrage inkl. Timestamp pro Ressource, damit der Server ggf. checken kann, ob sich was verändert hat oder nicht.
Dadurch entfallen die zig einzelnen HTTP-Requests. In jeden einzelnen Request wird ja auch z.B. dein verwendeter Browser und dein OS, die Rendering-Engine etc. gepackt. Diesen ganzen Traffic könnte man so einmal übertragen und dann bis zum Ende der Verbindung nie wieder.
Außerdem glaube ich nicht, dass ein SPDY-Server sich um das parsen der Webseite kümmert und sich komplett alleine um die Auslieferung kümmern wird, das würde viel zu viel Last auf den Rechnern erzeugen.
Wie das ganze am Ende implementiert wird ist ja außerdem noch unklar, derzeit kann man darüber nur spekulieren.
Vielleicht gibt es ja auch Leute, die das ganze forken, die Grundidee aufschnappen und das Ganze User-gerechter implementieren, falls SPDY schei** wird.