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. Schwarz Dienstleistung KG, Raum Neckarsulm
  2. AB SCIEX Germany GmbH, Darmstadt
  3. AssetMetrix GmbH, München
  4. Stadtwerke München GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 349€ (Vergleichspreise ab 378,81€)
  2. 139€ (Bestpreis!)
  3. (u. a. Sony KD-55XG8096 55 Zoll (138,8 cm) für 529€, Sony UBPX800 4K UHD Blu-ray-Player für...
  4. 79€ (Vergleichspreise ab 108€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nasa: Boeing umging Sicherheitsprozeduren bei Starliner
Nasa
Boeing umging Sicherheitsprozeduren bei Starliner

Vergessene Tabelleneinträge, fehlende Zeitabfragen und störende Mobilfunksignale sollen ursächlich für die Probleme beim Testflug des Starliner-Raumschiffs gewesen sein. Das seien aber nur Symptome des Zusammenbruchs der Sicherheitsprozeduren in der Softwareentwicklung von Boeing. Parallelen zur Boeing 737 MAX werden deutlich.
Von Frank Wunderlich-Pfeiffer

  1. Nasa Boeings Starliner hatte noch einen schweren Softwarefehler
  2. Boeing 777x Jungfernflug für das größte zweistrahlige Verkehrsflugzeug
  3. Boeing 2019 wurden mehr Flugzeuge storniert als bestellt

Galaxy-S20-Serie im Hands-on: Samsung will im Kameravergleich an die Spitze
Galaxy-S20-Serie im Hands-on
Samsung will im Kameravergleich an die Spitze

Mit der neuen Galaxy-S20-Serie verbaut Samsung erstmals seine eigenen Isocell-Kamerasensoren mit hoher Auflösung, auch im Zoombereich eifert der Hersteller der chinesischen Konkurrenz nach. Wer die beste Kamera will, muss allerdings zum sehr großen und vor allem wohl teuren Ultra-Modell greifen.
Ein Hands on von Tobias Költzsch, Peter Steinlechner und Martin Wolf

  1. Micro-LED-Bildschirm Samsung erweitert The Wall auf 583 Zoll
  2. Nach 10 kommt 20 Erste Details zum Nachfolger des Galaxy S10
  3. Vorinstallierte App Samsung-Smartphones schicken Daten an chinesische Firma

Pathfinder 2 angespielt: Abenteuer als wohlwollender Engel oder rasender Dämon
Pathfinder 2 angespielt
Abenteuer als wohlwollender Engel oder rasender Dämon

Das erste Pathfinder war mehr als ein Achtungserfolg. Mit dem Nachfolger möchte das Entwicklerstudio Owlcat Games nun richtig durchstarten. Golem.de konnte eine frühe Version des Rollenspiels bereits ausprobieren.
Von Peter Steinlechner

  1. 30 Jahre Champions of Krynn Rückkehr ins Reich der Drachen und Drakonier
  2. Dungeons & Dragons Dark Alliance schickt Dunkelelf Drizzt nach Icewind Dale

  1. Elektromobilität: Umweltbonus gilt auch für Jahreswagen
    Elektromobilität
    Umweltbonus gilt auch für Jahreswagen

    Vom neuen Umweltbonus für Elektroautos können künftig Käufer von Gebrauchtwagen profitieren. Neben einem zeitlichen Limit hat die Bundesregierung eine Obergrenze für die Kilometerzahl und den anrechenbaren Wertverlust festgelegt.

  2. Ausdiskutiert: Sony schließt das Playstation-Forum
    Ausdiskutiert
    Sony schließt das Playstation-Forum

    Falls es technische Probleme mit der Playstation 5 geben sollte, wird man an einer Stelle keine Hilfe finden: im offiziellen Playstation-Forum. Sony will den schon länger nur noch schwach frequentierten Treff schließen.

  3. Alphabet: Google strukturiert Cloud-Business um
    Alphabet
    Google strukturiert Cloud-Business um

    Um Nummer eins im Cloud-Business zu werden, strukturiert Google derzeit um. Auch einige Mitarbeiter müssen gehen. Das Unternehmen will sich dabei auf fünf Kernmärkte konzentrieren.


  1. 18:22

  2. 18:00

  3. 17:45

  4. 17:30

  5. 17:15

  6. 16:39

  7. 16:20

  8. 16:04