Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Google: Chrome nutzt SPDY statt HTTP

Braucht kein Mensch

  1. Thema

Neues Thema Ansicht wechseln


  1. Braucht kein Mensch

    Autor: /mecki78 08.04.11 - 19:50

    HTTP Header Kompression:
    Bei einem HTTP Request braucht der Header nur ein Paket, d.h. auch durch Komprimierung erhält man höchstens ein kleineres Paket, aber es ist immer noch ein Paket, man spart also anders als hier beschrieben keine Pakete ein und somit auch nicht mehr als vielleicht 1-2% Round Trip Zeit. Beim Reply macht der HTTP Header selbst bei sehr kleinen Dateien (JS, CSS) unter 10% aus, und schlaue Webmaster packen ihren JS/CSS Code sowieso lieber in wenige große, statt in viele kleine Dateien, weil auch SPDY kann die Server Zugriffszeiten auf Dateien (z.B. das Lesen von der Platte oder der Zugriff auf eine Datenbank) nicht verringern, die bei vielen kleinen Dateien viel öfters anfallen. Bei großen Dateien (z.B Bildern um die 100 KB) macht er unter 1%, und bei wirklich großen Dateien unter einem Promille aus. Der Header fällt somit nicht weiter ins Gewicht. HTTP Header Komprimierung mag vielleicht noch ISDN oder GPRS Nutzer noch wirklich interessieren, aber wer DSL oder UMTS hat, der hat echt andere Sorgen. HTTP Bodies unterstützen nebenbei erwähnt schon immer Komprimierung, sofern sich beide Seiten auf ein Kompressionsverfahren haben einigen können.

    Mehrere Requests Parallel über eine Verbindung:
    Das kann HTTP seit Version 1.1 auch, die praktisch überall im Einsatz ist. Nennt sich Pipelining. Ein Client kann beliebig viele Requests hintereinander absetzen, ohne darauf warten zu müssen, das vorherige Requests abgearbeitet wurden oder überhaupt deren Bearbeitung begonnen wurde. Sogar während er Antworten auf vorherige Requests erhält kann er weitere Requests absetzen (TCP Verbindungen sind immer Bidirektional, d.h. beide Seiten können zeitgleich Sender und Empfänger sein). Das das selten benutzt wird, liegt daran, dass es auf den meisten Servern abgeschaltet ist und weil es so wenige Server gibt, die das anbieten, ist es auch in vielen Clients immer noch abgeschaltet oder nur stark eingeschränkt in Gebrauch.

    Das Protokoll ist einfacher zu implementieren und weniger komplex als HTTP:
    Interessant... wie genau geht das, wenn es nur eine Zwischenschicht ist und ein vollständiges HTTP darüber sitzt?
    Siehe: http://@#$%&/6jo94co
    Ich würde sagen, es ist aufwendiger, weil man erst ein komplettes HTTP implementieren muss und dann auch noch SPDY dazu.

    (Von der SPDY Seite:)
    SPDY erlaubt Request Priorisierung:
    HTTP auch, aber eben nur implizit. Die Priorisierung ist die Reihenfolge in der die Requests beim Pipelining abgesetzt werden, denn die Antworten müssen in der gleichen Reihenfolge kommen wie die Anfragen kamen. Allerdings heißt dass nicht, dass der Server die Anfragen nicht parallel abarbeiten darf, z.B. wenn das alles langsame dynamische Anfragen sind (PHP Progs am Server, die Daten aus SQL Datenbanken holen und dynamisch was zusammenbauen z.B.), dann dürfen die natürlich alle parallel ablaufen. Die Ergebnisse müssen lediglich so lange zwischengespeichert werden, bis sie zum Senden an der Reihe sind. Das mag SPDY vielleicht schöner lösen durch Multiplexing, aber ganz ehrlich, das ist selten ein wirklicher Killer. Das Problem ist eher, dass die meisten HTTP Server nicht so geschrieben sind, dass sie mehrere Anfragen aus einer Pipeline parallel abarbeiten würden; und wenn sie das bei HTTP nicht tun, würden sie es bei SPDY auch nicht tun.

    Außerdem, was wenn man zwischen den ganzen in der Pipeline noch wartenden Requests schnell einen anderen Request absetzen muss? SPDY hat hier eben explizite Priorisierung, d.h. man sendet den Request auf der gleichen Verbindung mit höhere Priorität. HTTP sagt hingegen, mach ne zweite Verbindung auf und mach den Request da drüber. Nur weil HTTP es erlaubt viele Requests über eine Verbindung laufen zu lassen, heißt das nicht, das ein Client nicht eine Zweitverbindung aufmachen darf, um schnell mal einen Request "out-of-order" abzusetzen, die dann auch meistens wirklich parallel zur gerade beantworteten Anfrage auf der anderen Verbindung ist und somit auch nicht auf andere Anfragen warten muss. Außerdem wer soll bei SPDY die Priorisierung festlegen? Woher will ein Browser wissen, was auf der Seite wichtig ist und was nicht z.B.? Bzw., wenn er das weiß, warum setzt die Requests dann nicht bei HTTP in genau dieser Reihenfolge in die Pipeline?

    Fazit:
    Eigentlich löst SPDY keine echten Probleme, die HTTP nicht schon lange gelöst hätte. Das Problem ist eher dass viele diese Features in Servern gar nicht implementiert sind, halbherzig implementiert sind oder von Admins absichtlich abgeschaltet wurden, damit die Serverlast oder der Bandbreitenverbrauch niedrig bleibt. Und weil so wenige Server es richtig machen, geben sich auch die Clients nur bedingt Mühe HTTP Wirklich auszureizen. Wozu auch, wenn es eh mit den wenigsten Servern funktioniert? Würde man mal alle Features von HTTP konsequent umsetzen und auch aktivieren, dann würde SPDY im direkten Vergleich auch so gut wie keine messbaren Verbesserungen bringen.

    Und was macht Google glauben, dass es bei SPDY alles besser sein wird? Dann unterstützen irgendwann alle Hersteller SPDY, aber schalten parallel Verarbeitung auf ihren Servern ab, um wieder Rechenlast und Bandbreite einzusparen, beantworten Anfragen sequentiell in der Reihenfolge des Eingangs bzw. sortieren sie um anhand der Prioritäten in SPDY, aber immer noch sequentiell; und dann? Dann soll das bisschen HTTP Header Kompression das ganze rausreissen, bei immer schneller werdenden Brandbeitverbindungen der Nutzer? Wohl kaum.

    /Mecki

  2. Re: Braucht kein Mensch

    Autor: c0t0d0s0 08.04.11 - 20:14

    Erklärt sich vielleicht damit, dass Chrome immer noch kein Pipelining unterstützt?

  3. Lesenswert! (kwT.)

    Autor: Der Kaiser! 09.04.11 - 13:50

    Sein Beitrag. Nicht meiner.

    ___

    Die ganz grossen Wahrheiten sind EINFACH!

    Wirkung und Gegenwirkung.
    Variation und Selektion.
    Wie im grossen, so im kleinen.

  4. Re: Braucht kein Mensch

    Autor: tomatende2001 10.04.11 - 16:43

    c0t0d0s0 schrieb:
    --------------------------------------------------------------------------------
    > Erklärt sich vielleicht damit, dass Chrome immer noch kein Pipelining
    > unterstützt?

    Solche Dinge interessieren die Fanboys doch aber nicht, wenn man sich die Threads so anschaut. Google macht was und das muss einfach toll sein! So ist das Gesetz! ;)

  5. Super Beitrag. Danke ! n/t

    Autor: TechnicalCE 10.04.11 - 17:32

    nt

  6. Re: Super Beitrag. Danke ! n/t

    Autor: Nightdive 10.04.11 - 19:55

    Bei Http Pipelining gab es Probleme mit machen Servern und transparenten proxies und Load balancern. Deswegen wird es bisher auch nicht komplett von den Clients ausgereitzt denn die User fangen sofort an rumzuheulen wenn eine Seite nicht im eigenen Browser geht obwohl es im Browser X (der kein Pipelining nutzt) geht.

  7. Re: Super Beitrag. Danke ! n/t

    Autor: /mecki78 11.04.11 - 13:27

    Nightdive schrieb:
    --------------------------------------------------------------------------------
    > Bei Http Pipelining gab es Probleme mit machen Servern und transparenten
    > proxies und Load balancern.

    Das ist richtig und das liegt daran, dass Pipelining entweder schlecht in diesen implementiert wurde oder gar nicht.

    Proxies für HTTP sind sowieso eine aussterbende Gattung, weil immer mehr auf HTTPS gesetzt wird (Endpunkt zu Endpunkt Verschlüsselung und die Sicherheit, dass niemand unterwegs die Daten manipuliert hat) und hier kann ein HTTP Proxy ja nicht einmal die Requests sehen, ergo kann er z.B. auch nicht als Caching Proxy agieren. D.h. je mehr HTTPS benutzt wird, desto weniger macht es Sinn einen HTTP Proxy einzusetzen und man genauso gut einen "generischen" Proxy einsetzen, so was wie einen SOCKS Proxy z.B. Und einem generischen Proxy ist es total egal ob HTTP mit oder ohne Pipelining benutzt wird, weil er leitet Daten nur weiter, er interessiert sich nicht für deren Inhalt.

    Was Server angeht, so kann Apache schon lange Pipelining, mittlerweile sogar auch recht gut und wie die Tests des W3Cs zeigen, bringt das sogar einiges (bitte herunterscrollen zu den Tabellen im Abschnitt "Measurements"):
    http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
    Hier wurde auch Jigsaw getestet, der auch Pipelining beherrscht, allerdings wie man sieht, deutlich langsamer als Apache ist, wenn Kompression mitbenutzt wird.

    Das Problem ist, dass Pipelining eben dazu führt, das zumindest ein Teil der Requests parallel oder teilweise parallel ablaufen... was auch irgendwie der Sinn der Sache ist, aber d.h. auch dass jeder Nutzer, der gerade irgend eine WWW Seite anfragt automatisch eine höhere Serverlast erzeugt als bisher, da jetzt jeder Nutzer zeitgleich mehr CPU Resourcen belegt, seine Anfragen auch temporär mehr Speicher kosten und auch die Anzahl der Datenbankabfragen pro Nutzer steigt. D.h. ging ein Server bisher erst bei 10'000 Nutzern zeitgleich in die Knie, dann geht er jetzt vielleicht schon bei 5'000 oder sogar noch weniger in die Knie. Die Tatsache, dass im Gegenzug jeder Nutzer seine Seite deutlich schneller bekommt als bisher interessiert die meisten Server Admins dabei herzlich wenig. Daher schalten nach wie vor viele Admins Pipelining einfach aus, was laut HTTP 1.1 Spec absolut legal ist (ein Server muss nicht Pipelining unterstützen).

    Was Load Balancer betrifft, da kann ich nicht viel dazu sagen, außer dass Pipelining durchaus kompatible zu Load Balancern ist, sie müssen es nur unterstützen. Dabei kann ein Load Balancer alle Requests einer Pipeline auf den gleichen Server weiterleiten, das ist die einfachste Lösung, wenn auch nicht die optimale. D.h. eben Load Balancing erfolgt nur noch zwischen den Nutzern, nicht mehr zwischen unterschiedlichen Anfragen des gleichen Nutzers. Er könnte aber sogar einzelne Anfragen einer Verbindung auf verschiedene Server verteilen, was sicher besseres Load Balancing wäre, aber eben auch deutlich aufwendiger zu implementieren und auf dem LB Server deutlich mehr Resourcen kostet.

    Die Frage ist nun: Warum sollte das sich mit SPDY ändern? Proxies und Load Balancers müssten auch für SPDY umgebaut werden. Warum sollte des besser oder einfacher sein, als sie für Pipelining umzubauen, was ja bisher nicht so gut funktioniert hat? Und wer sagt bitte, dass Admins nicht trotz SPDY parallele Verarbeitung von Anfragen am HTTP Server ausschalten? Und wer garantiert mir nicht, dass es zu Problemen kommt, dass ein Server SPDY und auch normales HTTP anbietet und dann die Chrome Nutzer sagen bei ihnen geht die Webseite nicht richtig (weil dort SPDY benutzt wird), aber mit anderen Browsern schon (weil dort normales HTTP benutzt wird)? Woraufhin die Server Admins SPDY genauso abschalten wie heute Pipelining und wir haben wieder den Status Quo.

    /Mecki

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. BWI GmbH, Meckenheim
  2. operational services GmbH & Co. KG, Wolfsburg
  3. BWI GmbH, Bonn
  4. Landesbetrieb Bau und Immobilien Hessen (LBIH), Wiesbaden

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. 114,99€ (Release am 5. Dezember)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ursula von der Leyen: Von Zensursula zur EU-Kommissionspräsidentin
Ursula von der Leyen
Von "Zensursula" zur EU-Kommissionspräsidentin

Nach der "Rede ihres Lebens" hat das Europäische Parlament am Dienstagabend Ursula von der Leyen an die Spitze der EU-Kommission gewählt. Die Christdemokratin will sich in ihrem neuen Amt binnen 100 Tagen für einen Ethik-Rahmen für KI und ambitioniertere Klimaziele stark machen. Den Planeten retten, lautet ihr ganz großer Vorsatz.
Ein Bericht von Justus Staufburg

  1. Adsense for Search Neue Milliardenstrafe gegen Google in der EU

Projektorkauf: Lumen, ANSI und mehr
Projektorkauf
Lumen, ANSI und mehr

Gerade bei Projektoren werden auf Plattformen verschiedener Onlinehändler kuriose Angaben zur Helligkeit beziehungsweise Leuchtstärke gemacht - sofern diese überhaupt angegeben werden. Wir bringen etwas Licht ins Dunkel und beschäftigen uns mit Einheiten rund um das Thema Helligkeit.
Von Mike Wobker


    Transport Fever 2 angespielt: Wachstum ist doch nicht alles
    Transport Fever 2 angespielt
    Wachstum ist doch nicht alles

    Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
    Von Achim Fehrenbach

    1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
    2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
    3. Bright Memory angespielt Brachialer PC-Shooter aus China

    1. Windows 10: Windows-Defender-Dateien werden als fehlerhaft erkannt
      Windows 10
      Windows-Defender-Dateien werden als fehlerhaft erkannt

      Der System File Checker in Windows 10 markiert neuerdings Dateien des Windows Defender als fehlerhaft. Der Bug ist auch Microsoft bekannt. Das Problem: Die neue Version des Defenders verändert im Installationsimage verankerte Dateien. Der Hersteller will das mit einem Update von Windows 10 beheben.

    2. Keystone: Mechanische Tastatur passt Tastendruckpunkte den Nutzern an
      Keystone
      Mechanische Tastatur passt Tastendruckpunkte den Nutzern an

      Die auf Kickstarter finanzierte Keystone ist eine mechanische Tastatur mit Hall-Effekt-Schaltern. Diese können die Druckstärke registrieren. Eine Software ermöglicht es der Tastatur, das Tippverhalten der Nutzer zu analysieren und Druckpunkte entsprechend anzupassen.

    3. The Witcher: Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen
      The Witcher
      Erster Netflix-Trailer mit Geralt, Ciri, Triss und Striegen

      Netflix stellt den ersten Trailer seiner Serie The Witcher vor. Henry Cavill als Geralt von Riva kämpft dabei gegen Monster und Menschen und verwendet Hexerzeichen, Pirouettenkampf und Zaubertränke. Einige Szenen erinnern an Passagen aus den Büchern.


    1. 13:00

    2. 12:30

    3. 11:57

    4. 17:52

    5. 15:50

    6. 15:24

    7. 15:01

    8. 14:19