1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › MXHR - Webseiten in einem…

HTTP-Pipelining

  1. Thema

Neues Thema Ansicht wechseln


  1. HTTP-Pipelining

    Autor: ZinoS 23.04.09 - 10:15

    Hallo,

    mit HTTP 1.1 wurde eigentlich das HTTP-Pipelining eingeführt. Der Client kann dann mehrere HTTP-Request am Stück absetzen ohne auf die einzelnen Antworten warten zu müssen. "Eigentlich" weil es zwar von vielen Webserver und Clients unterstützt wird, aber per default deaktiviert ist. Für den Firefox kann man dieses Verhalten über "about:config" aktivieren.

    Statt eine weitere Schicht drauf zu packen sollte man ersteinmal die vorhandenen Möglichkeiten ausschöpfen.

    Grüße

    ZinoS

  2. Re: HTTP-Pipelining

    Autor: @ 23.04.09 - 10:20

    Genau.

  3. Re: HTTP-Pipelining

    Autor: hTTp 23.04.09 - 10:46

    Schon, aber leider:

    > Achtung: Das Aktivieren von Pipelining kann u.U. zu Problemen mit
    > einigen Seiten führen, die dieses Feature nicht korrekt unterstützen.

    (Quelle:
    > http://www.firefox-browser.de/wiki/About:config_(Einstellungen)
    )

    Deswegen dürfte es standardmäßig deaktiviert sein.

  4. Boah!

    Autor: Jeee Em 23.04.09 - 11:38

    Danke! Das beschleunigt meine Lieblings-Seiten enorm!

  5. Re: Boah!

    Autor: ZinoS 23.04.09 - 15:45

    keine Ursache! Gerade bei Seiten mit vielen kleinen Elementen, wie im Bericht bechrieben, bringt Pipelining was. Allerdings kann es bei einigen Seiten zu Problemen kommen, deshalb ist es wohl auch deaktiviert (siehe Beitrag von hTTp). Meine Erfahrung ist bis jetzt allerdings durchweg positiv.

    Grüße

    ZinoS

  6. Re: HTTP-Pipelining

    Autor: Pipe, die Linie 26.04.09 - 23:46

    hTTp schrieb:
    -------------
    > Schon, aber leider:
    >
    > > Achtung: Das Aktivieren von Pipelining kann
    > > u.U. zu Problemen mit
    > > einigen Seiten führen,
    > > die dieses Feature nicht korrekt unterstützen.

    Ist schon einmal jemand auf eine solche Seite gestoßen? Eigentlich ist das überhaupt kein Feature, vor allem nicht server-seitig. Lediglich client-seitig muss man die Transfer-Logik dahin ändern, dass der nächste schon angestoßen wird, obwohl der vorherige noch nicht beendet ist. Server-seitig ändert sich überhaupt nichts, außer eben, dass der Empfangspuffer nicht nach jeder gelesen Anfrage leer ist. Die einzige Stelle an der etwas schief laufen könnte, ist wenn man wie blöde den Empfangspuffer ausliest. Darüber wird der Sender auf TCP-Ebene benachrichtigt, der dann die nächsten Anfragen schickt. Das könnte dann dazu führen, dass Empfangspuffer beim Server voll ist und der deshalb einen Fehler zurückliefert. Man darf also den Empfangspuffer nicht schneller leeren als man die Anfragen bearbeiten kann. Im Zweifel liest man nur exakt eine Abfrage und die nächste erst, wenn die Antwort abgeschickt ist. Da sich das eigentlich von selbst versteht und alle bekannteren HTTP-Server damit keine Probleme haben dürften, finde ich die Warnung ziemlich überzogen.

    Im Gegenteil, man sollte es auf jeden Fall aktivieren, damit diese Drecksserver aus dem Verkehr gezogen werden. Die Warnung vor Pipelining gab es übrigens schon vor mindestens vier Jahren. So langsam sollte auch der letzte den Schuss gehört haben.


  7. Re: HTTP-Pipelining

    Autor: IhrName9999 07.05.09 - 14:02

    > Server-seitig ändert sich überhaupt nichts, außer
    > eben, dass der Empfangspuffer nicht nach jeder
    > gelesen Anfrage leer ist.

    WAS? Ein "Empfangspuffer" auf dem SERVER?? Nun, den gibt es wirklich - nennt sich entweder "char *name" oder "(char*)malloc(size)" und ist im schlimmsten Falle einige Dutzend Bytes lang. Sobald die GET-Anfrage des Clients komplett übermittelt wurde (und die kann nicht "teilweise" rausgehauen werden) beginnt auch schon der Sendeprozess.

    >Die einzige Stelle an
    > der etwas schief laufen könnte, ist wenn man wie
    > blöde den Empfangspuffer ausliest.

    Ähm ... das is ne ganz normale Programmfunktion. Ein Programm, welches den Puffer nicht zur Gänze und so schnell wie möglich leert verliert automatisch Daten. So ein Programm nennt man dann "fehlerhaft"

    > Darüber wird
    > der Sender auf TCP-Ebene benachrichtigt

    Schwachsinn. Was du meinst ist wohl die Anfrage, ein nicht vollständig oder nicht korrekt erhaltenes Paket erneut erhalten zu dürfen. Das hat aber recht wenig mit dem Thema zu tun.

    > Das könnte dann
    > dazu führen, dass Empfangspuffer beim Server voll
    > ist und der deshalb einen Fehler zurückliefert.

    *lach*
    Du hast offensichtlich keine Vorstellung davon wie Computer funktionieren ...

    > Man darf also den Empfangspuffer nicht schneller
    > leeren als man die Anfragen bearbeiten kann.

    Ich habe einige Minuten benötigt um diesen Satz zu VERSTEHEN ...
    Was du meinst mit "man DARF nicht" ist garnicht MÖGLICH. Es sei denn du übertaktest zwischen den Abläufen "Puffer füllen" und "Puffer auslesen" den PC :-)

    >Im
    > Zweifel liest man nur exakt eine Abfrage und die
    > nächste erst, wenn die Antwort abgeschickt ist.

    Wie sollte es denn sonst gehen? Im Quelltext eines Programms wird immer von OBEN NACH UNTEN abgearbeitet, die einzige Ausnahme bilden Threads, aber auch diese müssen letztendlich serialisiert werden.

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Allianz Partners Deutschland GmbH, Aschheim bei München
  2. Panasonic Industrial Devices Europe GmbH, Lüneburg
  3. über duerenhoff GmbH, Raum Hamburg
  4. SCHOTT AG, Mainz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (Dyson Cinectic Big Ball Parquet 2 Staubsauger für 249€ statt 399€ im Vergleich)
  2. (u. a. Rising Storm 2: Vietnam für 7,59€, Upwards, Lonely Robot für 2,99€, MONOPOLY® PLUS...
  3. 3 Monate nur 2,95€ pro Monat, danach 9,95€ pro Monat - jederzeit kündbar
  4. (u. a. Aladin 11,52€ (Blu-ray) & 22,99€ (4K), A Toy Story: Alles hört auf kein Kommando 12...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Alternatives Android im Test: /e/ will Google ersetzen
Alternatives Android im Test
/e/ will Google ersetzen

Wie Google, nur mit Privatsphäre - /e/ verbindet ein alternatives Android mit Cloudfunktionen und einer Suchmaschine.
Ein Test von Moritz Tremmel


    Coronavirus: Spiele statt Schule
    Coronavirus
    Spiele statt Schule

    Wer wegen des Coronavirus mit Kindern zu Hause ist, braucht einen spannenden Zeitvertreib. Unser Autor - selbst Vater - findet: Computerspiele können ein sinnvolles Angebot sein. Vorausgesetzt, man wählt die richtigen.
    Von Rainer Sigl

    1. CCC "Contact Tracing als Risikotechnologie"
    2. Coronapandemie Robert Koch-Institut sammelt Gesundheitsdaten von Sportuhren
    3. Google Chrome rollt Regeln für Same-Site-Cookies vorerst zurück

    Coronakrise: Hardware-Industrie auf dem Weg der Besserung
    Coronakrise
    Hardware-Industrie auf dem Weg der Besserung

    Fast alle Fabriken für Hardware laufen wieder - trotz verlängertem Chinese New Year. Bei Launches und Lieferengpässen sieht es anders aus.
    Ein Bericht von Marc Sauter

    1. Kaufberatung (2020) Die richtige CPU und Grafikkarte
    2. SSDs Intel arbeitet an 144-Schicht-Speicher und 5-Bit-Zellen