1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › IETF: HTTP 2.0 ist fertig

Paralleles Laden von Inhalten

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Paralleles Laden von Inhalten

    Autor: Anonymer Nutzer 18.02.15 - 13:35

    Macht das nicht jeder Browser heute standardmäßig?

  2. Re: Paralleles Laden von Inhalten

    Autor: minecrawlerx 18.02.15 - 13:47

    Nein. Woher soll er wissen, was er laden soll, wenn die HTML Datei noch nicht da ist? Und danach macht er mehrere Verbindungen auf. Mit HTTP/2 wird es nur noch eine Verbindung sein, und z.B. Bilder werden gleichzeitig mit der HTML Datei runtergeladen.

  3. Re: Paralleles Laden von Inhalten

    Autor: manitu 18.02.15 - 13:56

    Was noch viel geiler ist, ist das nur das Delta übertragen wird.

    D.h. Wenn man viele Icons hat, wird nicht jedes mal der komplette Header und so mit übertragen sondern nur die Änderungen gegenüber des letzten Icons.

  4. Re: Paralleles Laden von Inhalten

    Autor: Geistesgegenwart 18.02.15 - 17:47

    minecrawlerx schrieb:
    --------------------------------------------------------------------------------
    > Nein. Woher soll er wissen, was er laden soll, wenn die HTML Datei noch
    > nicht da ist? Und danach macht er mehrere Verbindungen auf. Mit HTTP/2 wird
    > es nur noch eine Verbindung sein, und z.B. Bilder werden gleichzeitig mit
    > der HTML Datei runtergeladen.

    Obacht! HTTP/2 erlaubt nun in der Tat das unaufgeforderte PUSHen von Content an den Client. Aber nur das Protokoll erlaubt das. Es ist immernoch Aufgabe vom Webserver zu bestimmen, welcher Content gepusht werden soll. Will sagen: Nur weil du HTTP/2 verwendest, bekommst du gar nix gepusht. Erst wenn der HTTP-Server auf irgend eine Art und Weise selektiert (z.B. in dem er das HTML parsed) kann er PUSHen.

    Ob ein PUSH ggü. der herkömmlichen Methode wirklich schneller ist sei dahingestellt - bisher hat keiner dazu (weder Google noch die IETF arbeitsgruppe) wissenschaftlich belastbare Zahlen hierzu vorgestellt).

    In der Praxis ist der Browser recht fix mit Bildern laden (das gilt auch für Scripte und Stylesheets) - weil er bereits das HTML parsed bevor es vollständig empfangen ist und über eine separate TCP Verbindung anfängt das Bild zu laden. Beim HTTP/2 & PUSH muss der Server mit dem PUSHen des Bildes aber warten, bis das HTML vollständig übertragen wurde und sendet danach erst das Bild raus. Zusammen mit HTTP Pipelining oder aber 5-6 parallel HTTP Verbindungen (jede als eigene TCP Verbindung) kann da HTTP/1.1 durchaus schneller sein als alles über eine einzelne HTTP/TCP Verbindung wie es bei HTTP/2 der Fall ist - denn TCP Staukontrollfenster kann dir hier einen Strich durch die Rechnung machen (die verbindung blockiert für 1-2 weitere Roundtrips).

  5. Re: Paralleles Laden von Inhalten

    Autor: TheUnichi 18.02.15 - 17:58

    morningstar schrieb:
    --------------------------------------------------------------------------------
    > Macht das nicht jeder Browser heute standardmäßig?

    Für jede "Datei" die du ziehst, findet ein komplettes HTTP Request mit kompletten Headern statt.

    Connect -> Header zusammenbauen -> Request -> Response -> Disconnect -> Parsing

    Das Ganze für jede kleine 5x5px Grafik, jede CSS Datei, jede JS Datei, sämtliche JSON Daten (AJAX sind halt auch nur HTTP Requests)

    Nun können all diese Daten mit _einem_ Request, d.h. ein Connect, ein Satz Header, ein Disconnect, geladen werden.

  6. Re: Paralleles Laden von Inhalten

    Autor: Geistesgegenwart 18.02.15 - 19:02

    TheUnichi schrieb:
    --------------------------------------------------------------------------------
    > Nun können all diese Daten mit _einem_ Request, d.h. ein Connect, ein Satz
    > Header, ein Disconnect, geladen werden.

    Nö. Du brauchst weiterhin Header für jedes Objekt das du anforderst. Macht ja auch kein Sinn sonst. Für .html Resourcen setzt ein Client den Accept: text/html und wenn du ein Ajax Call machst setzt der Client den "Accept: application/json" header. Da kommst du nicht drum rum. Selbiges gilt für Anfragen nach dem Status eines Objekts (Header "If-None-Match" etc.).

    Der *Server* kann theoretisch auf ein Request mehrere Responses schicken ("PUSH") - die Intelligenz, was auf welches Request zu schicken ist wird aber nicht durch das protokoll geregelt. Es macht auch kein Sinn AJAX requests zu pushen, da die selten beim Laden der Hauptseite (index.html) feststehen - sonst könne man das JSON ja gleich mit in das .html integrieren.

    Beim PUSH entstehen noch ganz andere Probleme (z.B. braucht der Client das Bild überhaupt? Hat er evntl Bilder laden deaktiviert? Oder hat er eine Variante im cache die noch gültig ist?) etc. Das alles wird nicht vom Protokoll abgedeckt, sondern ist aufgabe der HTTP Server. Und da gibts noch viele Probleme und ungeklärte Fragen.

  7. Re: Paralleles Laden von Inhalten

    Autor: TheUnichi 19.02.15 - 16:32

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > TheUnichi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Nun können all diese Daten mit _einem_ Request, d.h. ein Connect, ein
    > Satz
    > > Header, ein Disconnect, geladen werden.
    >
    > Nö. Du brauchst weiterhin Header für jedes Objekt das du anforderst. Macht
    > ja auch kein Sinn sonst. Für .html Resourcen setzt ein Client den Accept:
    > text/html und wenn du ein Ajax Call machst setzt der Client den "Accept:
    > application/json" header. Da kommst du nicht drum rum. Selbiges gilt für
    > Anfragen nach dem Status eines Objekts (Header "If-None-Match" etc.).

    afaik brauchst du nicht alle Header für jeden Part im Request wiederholen, sondern _überschreibst_ quasi
    d.h. die erste Zeile des Headers, Content-Type und Content-Length müssten theoretisch die einzigen sein, die wiederholt werden müssen. Maximal noch der Host-Header

    > Der *Server* kann theoretisch auf ein Request mehrere Responses schicken
    > ("PUSH") - die Intelligenz, was auf welches Request zu schicken ist wird
    > aber nicht durch das protokoll geregelt. Es macht auch kein Sinn AJAX
    > requests zu pushen, da die selten beim Laden der Hauptseite (index.html)
    > feststehen - sonst könne man das JSON ja gleich mit in das .html
    > integrieren.

    Es macht aber durchaus Sinn, mehrere API-Calls in einem AJAX-Request auszuführen bzw. verschiedene Datenstrukturen aus verschiedenen APIs in einem Request zu laden, nachträglich

    > Beim PUSH entstehen noch ganz andere Probleme (z.B. braucht der Client das
    > Bild überhaupt? Hat er evntl Bilder laden deaktiviert? Oder hat er eine
    > Variante im cache die noch gültig ist?) etc. Das alles wird nicht vom
    > Protokoll abgedeckt, sondern ist aufgabe der HTTP Server. Und da gibts noch
    > viele Probleme und ungeklärte Fragen.

    Das Request fragt ja afaik mehrere Ressourcen in einem Request an.
    d.h. genau da wird dies definiert.

    Es ist halt im Grunde nichts weiter als kombinierte Requests/Responses.

  8. Re: Paralleles Laden von Inhalten

    Autor: Geistesgegenwart 19.02.15 - 16:46

    TheUnichi schrieb:
    --------------------------------------------------------------------------------
    > afaik brauchst du nicht alle Header für jeden Part im Request wiederholen,
    > sondern _überschreibst_ quasi
    > d.h. die erste Zeile des Headers, Content-Type und Content-Length müssten
    > theoretisch die einzigen sein, die wiederholt werden müssen. Maximal noch
    > der Host-Header
    >
    Clients senden keinen Content-Type sondern ein "Accept" header - ausser der Request hat einen Body (z.B. bei POST requests). Content-Type wird vom Server in der Response gesetzt. "Host" entfällt, da über eine Verbindung nicht unterschiedliche Hosts abgefragt werden dürfen - den spart man sich also in der Tat. Ich Frage micht aber welche Header dann überhaupt noch übrig bleiben ausserdem "Host", die man sich spart? Der Großteil der HEader wird vom Server gesetzt (Etag, Expiry, Content-Type, Cross-Origin-*).

    > Es macht aber durchaus Sinn, mehrere API-Calls in einem AJAX-Request
    > auszuführen bzw. verschiedene Datenstrukturen aus verschiedenen APIs in
    > einem Request zu laden, nachträglich

    Sinn macht das zwar, kann aber HTTP/2 auch nicht. JavaScript hat keinerlei Zugriff auf HTTP/2 internas, und sonst müsste die JavaScript engine die AJAX requests erst zurückhalten und abwarten ob ggf. noch weitere Requests folgen um diese gebündelt abzuschicken. Dieses zurückhalten wird die Latenz aber unnötig in die Höhe treiben, dabei ist gerade Latenz der bestimmende Faktor bei AJAX requests (Bandbreite spielt meist keine Rolle sondern geringe Latenz ist wichtiger um AJAX Kaskaden schneller durchzuführen - und nein, Kaskaden lassen sich oft nicht vermeiden da Datenabhängigkeiten bestehen).

    >
    > > Beim PUSH entstehen noch ganz andere Probleme (z.B. braucht der Client
    > das
    > > Bild überhaupt? Hat er evntl Bilder laden deaktiviert? Oder hat er eine
    > > Variante im cache die noch gültig ist?) etc. Das alles wird nicht vom
    > > Protokoll abgedeckt, sondern ist aufgabe der HTTP Server. Und da gibts
    > noch
    > > viele Probleme und ungeklärte Fragen.
    >
    > Das Request fragt ja afaik mehrere Ressourcen in einem Request an.
    > d.h. genau da wird dies definiert.
    >

    Nein, da liegst du falsch. HTTP/2 kann weiterhin nur eine einzige Resource anfragen, da keinerlei Modifikation an den HTTP Headers bzw der Headersemantik vorgenommen wurde (steht auch im Artikel). D.h. der Aufruf auf Clientseite heisst weiterhin "GET /index.html HTTP/2.0". Neu ist lediglich dass du das parallele Anfragen, das bisher über mehrere TCP Verbindungen erfolgte, nun über eine einzige TCP Verbindung erfolgen kann. Lediglich der SERVER kann auf einen Request mehrere Responses schicken.

  9. Re: Paralleles Laden von Inhalten

    Autor: TheUnichi 25.02.15 - 18:52

    Geistesgegenwart schrieb:
    --------------------------------------------------------------------------------
    > TheUnichi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > afaik brauchst du nicht alle Header für jeden Part im Request
    > wiederholen,
    > > sondern _überschreibst_ quasi
    > > d.h. die erste Zeile des Headers, Content-Type und Content-Length
    > müssten
    > > theoretisch die einzigen sein, die wiederholt werden müssen. Maximal
    > noch
    > > der Host-Header
    > >
    > Clients senden keinen Content-Type sondern ein "Accept" header - ausser der
    > Request hat einen Body (z.B. bei POST requests).

    Darum ging es mir, aber ebenfalls um die Response, die dasselbe Prinzip verfolgt, was den Content betrifft

    > Content-Type wird vom Server in der Response gesetzt. "Host" entfällt, da über eine Verbindung
    > nicht unterschiedliche Hosts abgefragt werden dürfen - den spart man sich
    > also in der Tat. Ich Frage micht aber welche Header dann überhaupt noch
    > übrig bleiben ausserdem "Host", die man sich spart? Der Großteil der HEader
    > wird vom Server gesetzt (Etag, Expiry, Content-Type, Cross-Origin-*).

    Auf jeden Fall keine, die man wiederholen müsste, wäre also ein einfaches, es jeweils in ein Request/eine Response zu packen

    > > Es macht aber durchaus Sinn, mehrere API-Calls in einem AJAX-Request
    > > auszuführen bzw. verschiedene Datenstrukturen aus verschiedenen APIs in
    > > einem Request zu laden, nachträglich
    >
    > Sinn macht das zwar, kann aber HTTP/2 auch nicht. JavaScript hat keinerlei
    > Zugriff auf HTTP/2 internas, und sonst müsste die JavaScript engine die
    > AJAX requests erst zurückhalten und abwarten ob ggf. noch weitere Requests
    > folgen um diese gebündelt abzuschicken. Dieses zurückhalten wird die Latenz
    > aber unnötig in die Höhe treiben, dabei ist gerade Latenz der bestimmende
    > Faktor bei AJAX requests (Bandbreite spielt meist keine Rolle sondern
    > geringe Latenz ist wichtiger um AJAX Kaskaden schneller durchzuführen - und
    > nein, Kaskaden lassen sich oft nicht vermeiden da Datenabhängigkeiten
    > bestehen).

    Du hast ja nur ein Request und nur eine Response, die fragst nur eben in einem Request mehrere Dateien an und kriegst in einer Response den Inhalt aus mehreren Dateien

    Das war mein Denken dahinter.

    Das AJAX-Request würde folglich einfach etwas länger brauchen, würde dafür aber direkt alle Daten laden und würde sich das übermitteln diverser Header sparen

    > > > Beim PUSH entstehen noch ganz andere Probleme (z.B. braucht der Client
    > > das
    > > > Bild überhaupt? Hat er evntl Bilder laden deaktiviert? Oder hat er
    > eine
    > > > Variante im cache die noch gültig ist?) etc. Das alles wird nicht vom
    > > > Protokoll abgedeckt, sondern ist aufgabe der HTTP Server. Und da gibts
    > > noch
    > > > viele Probleme und ungeklärte Fragen.
    > >
    > > Das Request fragt ja afaik mehrere Ressourcen in einem Request an.
    > > d.h. genau da wird dies definiert.
    > >
    >
    > Nein, da liegst du falsch. HTTP/2 kann weiterhin nur eine einzige Resource
    > anfragen, da keinerlei Modifikation an den HTTP Headers bzw der
    > Headersemantik vorgenommen wurde (steht auch im Artikel). D.h. der Aufruf
    > auf Clientseite heisst weiterhin "GET /index.html HTTP/2.0". Neu ist
    > lediglich dass du das parallele Anfragen, das bisher über mehrere TCP
    > Verbindungen erfolgte, nun über eine einzige TCP Verbindung erfolgen kann.
    > Lediglich der SERVER kann auf einen Request mehrere Responses schicken.

    Okay, genau das ist die fehlende Information.
    Das ist schade ehrlich gesagt, ich bin der Ansicht, da geht noch mehr.

    Aber nicht bei jedem Request einen komplett neuen Socket aufbauen zu müssen ist schonmal ein Anfang.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Informatiker/in (FH-Diplom / Bachelor / Fachinformatiker/in [m/w/d])
    Zentrum Bayern Familie und Soziales Dienststelle Zentrale Personalmanagement, Bayreuth
  2. Manufacturing Digitalization Expert (m/f/d)
    Heraeus Quarzglas GmbH & Co. KG, Kleinostheim
  3. Service Manager (m/w/d) Datenbanksysteme
    operational services GmbH & Co. KG, Leinfelden-Echterdingen, Dresden, Ingolstadt, Wolfsburg
  4. Mathematiker in der iGaming Branche (w/m/d)
    Gamomat Development GmbH, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. The Walking Dead: The Telltale Definitive Series für 23,99€, Project Wingman für 18...
  2. 18,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Leserumfrage: Wie wünschst du dir Golem.de?
Leserumfrage
Wie wünschst du dir Golem.de?

Ob du täglich mehrmals Golem.de liest oder ab und zu: Wir sind an deiner Meinung interessiert! Hilf uns, Golem.de noch besser zu machen - die Umfrage dauert weniger als 10 Minuten.

  1. TECH TALKS Kann Europa Chips?
  2. TECH TALKS Drohnen, Daten und Deep Learning in der Landwirtschaft
  3. In eigener Sache Englisch lernen mit Golem.de und Gymglish

Vernetzung im Smart Home: Alles eins mit Thread und Matter
Vernetzung im Smart Home
Alles eins mit Thread und Matter

Mit Thread und Matter soll endlich etwas gelingen, woran bislang alle gescheitert sind: verschiedenste Smart-Home-Produkte zu einem Ökosystem zu verbinden.
Von Jan Rähm

  1. Wiz Signify bringt neue WLAN-Lampen
  2. Smarte Beleuchtung Wiz im Test Es muss nicht immer Philips Hue sein
  3. Smart Home Matter verzögert sich bis 2022

Elite 3 und Studio Buds im Test: Jabra deklassiert doppelt so teure Beats-Stöpsel
Elite 3 und Studio Buds im Test
Jabra deklassiert doppelt so teure Beats-Stöpsel

Können 80 Euro teure Bluetooth-Hörstöpsel Konkurrenten für 150 Euro schlagen? Wir haben die Probe aufs Exempel gemacht.
Ein Test von Ingo Pakalski

  1. Jabra Elite 7 Pro Besonders kleine ANC-Stöpsel mit sehr langer Akkulaufzeit
  2. Elite 3 Airpods-Konkurrenz von Jabra für 80 Euro