> > Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln. > > Wie @Mitleser schon sagte, gibt es nicht das eine Prinzip hinter HTTP/2, sondern eine Menge neuer Features. Mir ist nicht klar, welches Feature von HTTP/2 du jetzt als Äquivalent zu deiner Lösung betrachtest, am ehesten wohl Server-Push. Die wesentlichen Vorteile, nämlich Ladezeiten und Netzwerklast durch einen progressiven Server zu reduzieren, kann ich bei dir allerdings nicht wiederfinden. Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann. Das hast Du doch verstanden wie Du an anderer Stelle schreibst!? Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm): ~~~perl Rate formdata binary formdata 1.02/s -- -100% binary 213/s 20679% -- ~~~ Im Übrigen ist auch JS ziemlich träge wenn ein FormData Objekt mit mehreren größeren Dateien erstellt werden muss. Wenn Du [hier](http://rolfrost.de/formdown.html) ein Upload > 1 MB mit mehreren großen Dateien aufstellst dauert es eine ganze Weile bis der Server antwortet. Bei gleicher gesendeter Datenmenge antwortet der Server viel Schneller, wenn **kein** FormData Objekt erstellt wurde sondern die Daten aneinandergehängt wurden, der guckt sich eh nur den einen Header Content-Length an. Du siehst also, daß es nicht nur eine Frage des Offenhalten einer HTTP Connection ist sondern auch eine Frage der Art und Weise der Verpackung, also eine Frage des Serialize Algorithmus. Und FormData ist so ziemlich die uneffizienteste Art, Daten zu serialisieren. Zumal sich mir der Sinn einer Boundary schon gar nicht erschließt, wenn ein Parser byte für byte arbeitet nämlich, ist eine Boundary nicht nur absolut überflüssig sondern auch noch hinderlich, weil sie von der rausgelesenen Teilsequenz wieder abgeschnitten werden muss. HTTP/2 implementiert schließlich auch nur einen Kompromiß der hinsichtlich Abwärtskompatibilität getroffen werden muss. Kurzum: Es gibt effizientere Verfahren zum Übertragen mehrerer Dateien in einem Req/Response Zyklus und zwei davon zeigen meine DEMO's hier fürs [Upload](http://rolfrost.de/mfup.html) und hier fürs [Download](http://rolfrost.de/mdown.html). MfG

> > Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln. > > Wie @Mitleser schon sagte, gibt es nicht das eine Prinzip hinter HTTP/2, sondern eine Menge neuer Features. Mir ist nicht klar, welches Feature von HTTP/2 du jetzt als Äquivalent zu deiner Lösung betrachtest, am ehesten wohl Server-Push. Die wesentlichen Vorteile, nämlich Ladezeiten und Netzwerklast durch einen progressiven Server zu reduzieren, kann ich bei dir allerdings nicht wiederfinden. Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann. Das hast Du doch verstanden wie Du an anderer Stelle schreibst!? Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm): ~~~perl Rate formdata binary formdata 1.02/s -- -100% binary 213/s 20679% -- ~~~ Im Übrigen ist auch JS ziemlich träge wenn ein FormData Objekt mit mehreren größeren Dateien erstellt werden muss. Wenn Du [hier](http://rolfrost.de/formdown.html) ein Upload > 1 MB mit mehreren großen Dateien aufstellst dauert es eine ganze Weile bis der Server antwortet. Bei gleicher gesendeter Datenmenge antwortet der Server viel Schneller, wenn **kein** FormData Objekt erstellt wurde sondern die Daten aneinandergehängt wurden, der guckt sich eht nur den einen Header an. Du siehst also, daß es nicht nur eine Frage des Offenhalten einer HTTP Connection ist sondern auch eine Frage der Art und Weise der Verpackung, also eine Frage des Serialize Algorithmus. Und FormData ist so ziemlich die uneffizienteste Art, Daten zu serialisieren. Zumal sich mir der Sinn einer Boundary schon gar nicht erschließt, wenn ein Parser byte für byte arbeitet nämlich, ist eine Boundary nicht nur absolut überflüssig sondern auch noch hinderlich, weil sie von der rausgelesenen Teilsequenz wieder abgeschnitten werden muss. HTTP/2 implementiert schließlich auch nur einen Kompromiß der hinsichtlich Abwärtskompatibilität getroffen werden muss. Kurzum: Es gibt effizientere Verfahren zum Übertragen mehrerer Dateien in einem Req/Response Zyklus und zwei davon zeigen meine DEMO's hier fürs [Upload](http://rolfrost.de/mfup.html) und hier fürs [Download](http://rolfrost.de/mdown.html). MfG

> > Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln. > > Wie @Mitleser schon sagte, gibt es nicht das eine Prinzip hinter HTTP/2, sondern eine Menge neuer Features. Mir ist nicht klar, welches Feature von HTTP/2 du jetzt als Äquivalent zu deiner Lösung betrachtest, am ehesten wohl Server-Push. Die wesentlichen Vorteile, nämlich Ladezeiten und Netzwerklast durch einen progressiven Server zu reduzieren, kann ich bei dir allerdings nicht wiederfinden. Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann. Das hast Du doch verstanden wie Du an anderer Stelle schreibst!? Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm): ~~~perl Rate formdata binary formdata 1.02/s -- -100% binary 213/s 20679% -- ~~~ Im Übrigen ist auch JS ziemlich träge wenn ein FormData Objekt mit mehreren größeren Dateien erstellt werden muss. Wenn Du [hier](http://rolfrost.de/formdown.html) ein Upload > 1 MB mit mehreren großen Dateien aufstellst dauert es eine ganze Weile bis der Server antwortet. Bei gleicher gesendeter Datenmenge antwortet der Server viel Schneller, wenn **kein** FormData Objekt erstellt wurde sondern die Daten aneinandergehängt wurden. Du siehst also, daß es nicht nur eine Frage des Offenhalten einer HTTP Connection ist sondern auch eine Frage der Art und Weise der Verpackung, also eine Frage des Serialize Algorithmus. Und FormData ist so ziemlich die uneffizienteste Art, Daten zu serialisieren. Zumal sich mir der Sinn einer Boundary schon gar nicht erschließt, wenn ein Parser byte für byte arbeitet nämlich, ist eine Boundary nicht nur absolut überflüssig sondern auch noch hinderlich, weil sie von der rausgelesenen Teilsequenz wieder abgeschnitten werden muss. HTTP/2 implementiert schließlich auch nur einen Kompromiß der hinsichtlich Abwärtskompatibilität getroffen werden muss. Kurzum: Es gibt effizientere Verfahren zum Übertragen mehrerer Dateien in einem Req/Response Zyklus und zwei davon zeigen meine DEMO's hier fürs [Upload](http://rolfrost.de/mfup.html) und hier fürs [Download](http://rolfrost.de/mdown.html). MfG