Schlanke Alternative zu multipart/form-data

[pl]

Hi,

die Abende werden länger und da fällt mir immer mal was ein, z.B. sowas. Es ist an der Zeit über neue Content-Types nachzudenken.

Viel Spaß beim Lesen.

[Rolf B]

Hallo pl,

interessant. An welchen Stellen haben deine Messungen welchen Performancegewinn ergeben?

Rolf

[pl]

Benchmark serverprozess

           Rate formdata   binary
formdata 20.4/s       --     -90%
binary    213/s     943%       --

Faktor > 10 😉

Und da hab ich schon den schnellsten Parser genommen. MfG

[pl]

Ergänzung:

Und da hab ich schon den schnellsten Parser genommen. MfG

Gegenüber dem Parsen mit legacy CGI.pm ergibt sich ein Geschwindigkeitszuwachs um das 200fache!

Freundschaft 😉

[pl]

Moin,

interessant. An welchen Stellen haben deine Messungen welchen Performancegewinn ergeben?

Im Browser stehen die Erzeugung eines FormData-Objekts oder eines Blob-Objekts zur Disposition. Da dürfte wohl hinsichtlich der Performance kaum ein Unterschied bestehen.

Der mit FormData erzeugte UploadStream ist nur unwesentlich länger als die als Blob gesendete Binary. Auch hier gibt es wohl kaum Unterschiede die exakt erfasst werden könnten.

Interessant wird es jedoch serverseitig. So ist das Parsen eines FormData-Body sehr CPU-lastig und speicherfressend, je nachdem wie der Parser arbeitet. Je nach Parser werden auch temporäre Dateien angelegt die ein Sicherheitsrisiko darstellen können.

Der Hauptgewinn gegenüber multipart/form-data ergibt sich somit daraus daß der Upload-Stream nicht geparst werden muss. Der serverseitige Prozess begnügt sich damit, die Binary nur zu lesen anhand der mitgelieferten Längenangaben wobei mit dem Lesen unmittelbar begonnen werden kann (streaming).

MfG

[Mitleser]

Mir ist es ehrlich gesagt zu müßig, auf die Nummer einzugehen. Ausnahme:

Interessant wird es jedoch serverseitig. So ist das Parsen eines FormData-Body sehr CPU-lastig und speicherfressend, je nachdem wie der Parser arbeitet. Je nach Parser werden auch temporäre Dateien angelegt die ein Sicherheitsrisiko darstellen können.

Zitat:

my @names = $self->param('name');
while( my($i, $len) = each @lens){
        my $name = $names[$i];
        $fh->open( "d:/tmp/$name", O_CREAT|O_BINARY|O_TRUNC|O_RDWR ) or die $!;
}

Sieht mir schwer nach Sicherheitsrisiko aus. Außer, Du machst vorher eine nicht weiter erwähnte Magie auf $self->param('name'). Solltest Du dann aber dazuschreiben. So ist das eine böse Lücke und keine gute Empfehlung.

[pl]

Danke für den Hinweis, ich habe die Datei-Namen rausgenommen damit das nicht weiter verwirrt. MfG

[pl]

Hi,

für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet. Die einzelnen Längenangaben werden über einen custom Header mitgeschickt.

MfG

[Mitleser]

für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet.

Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

[pl]

für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet.

Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

[Mitleser]

Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

Komische Antwort in Zeiten, in denen sich HTTP/2 immer weiter durchsetzt 😀

Das bringt den von Dir skizzierten Vorteil und noch eine ganze Menge mehr.

Im Gegensatz zu Deinem propietären Vorschlag ist HTTP/2 ein definierter Standard, der ohne eigene Implementationen im Client / Server einfach funktioniert.

Du musst einen (immer teuren) Scriptprozess starten, um die Ressourcen zusammenzupacken... wenn der Client immer einen großen Blob statt z.B. 10 Bildreferenzen vor den Latz geknallt bekommt, sind die Bilder nicht mehr einzeln adressierbar... Lazy Loading fällt flach... usw...

Fazit: Dein Vorschlag bringt viele Nachteile mit sich. Der von Dir skizzierte Vorteil ist mit HTTP/2 keiner mehr.

Daher nochmals meine kleine Nachfrage: warum?

[pl]

Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

Komische Antwort in Zeiten, in denen sich HTTP/2 immer weiter durchsetzt 😀

Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

[Mitleser]

Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

Kleine Nachfrage: warum sollte man das so tun wollen?

[pl]

Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

Kleine Nachfrage: warum sollte man das so tun wollen?

Der Sinn von HTTP/2 besteht darin, die Anzahl der Requests zu verringern. Insofern gibt es keinen Unterschied zu meiner Demo: Anstatt für 3 Images 3 Requests zu feuern ist nur noch ein Request erforderlich. Ebenso wie bei HTTP/2 muss eine solche Vorgehensweise serverseitig unterstützt sein und auch das Protokoll muss bestimmte Voraussetzungen bieten. HTTP ist grundsätzlich zur Übertragung beliebiger Bytesequenzen geeignet weil es einen Headerblock voranstellt um dem Empfänger mitteilen zu können was er überhaupt zu tun hat mit dem nachfolgenden Content.

Somit ist der wichtigste Header derjenige welcher den Content-Type angibt. Wenn der z.B. application/pdf lautet, lädt der Browser (falls vorhanden) den PDF Betrachter und der stellt anhand der Binary Texte mit Bildern dar ohne die Bilder vom Server nachladen zu müssen. Genauso können wir uns das bezüglich HTTP/2 vorstellen, nur daß hier der Browser selbst den Inhalt darstellt -- Texte, Bilder, Audio, Video und das alles ohne weitere Requests auf die einzelnen Mediatypen.

MfG

[Mitleser]

Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉

Der Sinn von HTTP/2 besteht darin, die Anzahl der Requests zu verringern.

Nicht nur, aber nehmen wir der Einfachheit halber mal an, es wäre der einzige Vorteil.

Insofern gibt es keinen Unterschied zu meiner Demo: Anstatt für 3 Images 3 Requests zu feuern ist nur noch ein Request erforderlich.

Insofern kannst Du das schon so sagen. Nur hast Du gleichzeitig eine Menge Nachteile gegenüber HTTP/2 im Gepäck. Beispiele:

• die Ressourcen können nicht mehr einzeln gecached werden
• du benötigst einen teuren Scriptprozess, um die Ressourcen serverseitig zusammenzupacken
• Bilder / Videos sind nicht mehr einzeln adressierbar
• ...

Ebenso wie bei HTTP/2 muss eine solche Vorgehensweise serverseitig unterstützt sein und auch das Protokoll muss bestimmte Voraussetzungen bieten.

Ja. Beinahe alle gängigen Clients können heute schon HTTP/2, einfach so. Wenn ich (du/er/sie/es) dann irgendwann auf dem Server HTTP/2 implementiere(aktiviere), dann funktioniert das. Einfach so!

Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren, die zwar das Ziel, mehrere Ressourcen mit einem Request zu übertragen ebenfalls erreicht, bezahlst das aber im Vergleich zu HTTP/2 mit heftigen Nachteilen.

Das bring mich zu meiner Eingangsfrage zurück: warum?

[pl]

Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉

Du hast meine Antwort nicht verstanden.

Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren,

Nein eben nicht stattdessen. Meine Demo zeigt lediglich wie man mehrere legacy responses in einer response zusammenfassen kann. Das konnte ich Dir übrigens vor 10 Jahren schon zeigen 😉

MfG

PS: FetchAPI kann übrigens formData() als Response Demo auch damit ist multipart Content möglich -- Nicht proprietär.

[Mitleser]

Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉 Du hast meine Antwort nicht verstanden.

OK!

Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren, Nein eben nicht stattdessen. Meine Demo zeigt lediglich wie man mehrere legacy responses in einer response zusammenfassen kann. Das konnte ich Dir übrigens vor 10 Jahren schon zeigen 😉

Ah... Du wolltest lediglich sagen: Hey, gäbe es heute kein HTTP/2 und man wollte trotzdem in einer Response mehrere Ressourcen an den Client senden und dabei diverse Nachteile in Kauf nehmen, dann könnte man es genauso machen, wie ich es vor 10 Jahren schon gemacht habe!

Habe ich es jetzt richtig verstanden?

[pl]

hi,

Ah... Du wolltest lediglich sagen: Hey, gäbe es heute kein HTTP/2 und man wollte trotzdem in einer Response mehrere Ressourcen an den Client senden und dabei diverse Nachteile in Kauf nehmen, dann könnte man es genauso machen, wie ich es vor 10 Jahren schon gemacht habe!

Habe ich es jetzt richtig verstanden?

Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln. Auch das grottige FormData-Objekt muss dafür herhalten -- weils halt mittlerweile damit geht. Auf der MDN Seite hahmse noch kein Beispiel, ich hab eins. Im Gegensatz zu anderen Body-Methods wie text(), arrayBuffer(), blob() interessiert sich die Methode formData() nunmehr für den Response-Header Content-Type samt boundary.

Der Zeit immer ein Stück voraus, MfG

[1unitedpower]

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. Hier mal ein einfaches Beispiel wie Server-Push funktioniert:

Du gibst in der Adresszeile https://example.com/index.html ein, darauf reagiert der Server und schickt dir ein HTML-Dokument:

<!DOCTYPE html>
<html>
    <head>
        <title>Hello World!</title>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <h1>Hello World!</h1>
    </body>
</html>

Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß, "PS: Du wirst gleich mit Sicherheit das Stylesheet style.css brauchen, hier hast du es schonmal". Der Browser denkt sich "Sehr zuvorkommend, die jungen Server von heute" dann fängt er an die HTML-Datei zu parsen, sieht dass er das Stylesheet tatsächlich gebrauchen kann, muss es aber nicht mehr anfragen, weil der Server es ihm ja schon zugesteckt hat. Ein wichtiger Punkt, das hat @Mitleser auch schon gesagt, ist dass das Stylesheet und das HTML-Dokument beide adressierbar bleiben und auch unabhängig voneinander gecacht werden können. Und Server-Push funktioniert auch schon beim ersten Seitenaufruf.

[pl]

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):

           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 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 und hier fürs Download.

MfG

[1unitedpower]

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.

Alle im Web gebräuchlichen Formate sind streamingfähig, das ist also kein Alleinstellungsmerkmal deines Algorithmus'. Aber danach hatte ich auch garnicht gefragt, sondern nach dem HTTP/2-Feature, welches du eigenen Angaben zufolge "mit anderen Mitteln" zu erklären versuchtest.

Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm):

Nichts für Ungut, aber das sind nur Zahlen, was und wie du gebenchmarkt hast ist daraus nicht ersichtlich. Aber die Mühe musst du dir wegen mir auch nicht machen, Perl ist ohnehin nicht meine Welt.

[pl]

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.

Alle im Web gebräuchlichen Formate sind streamingfähig, das ist also kein Alleinstellungsmerkmal deines Algorithmus'. Aber danach hatte ich auch garnicht gefragt, sondern nach dem HTTP/2-Feature, welches du eigenen Angaben zufolge "mit anderen Mitteln" zu erklären versuchtest.

Mehrere Dateien in einem Req/ResponseZyklus ist das Feature. Wars das jetzt!?

Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm):

Nichts für Ungut, aber das sind nur Zahlen, was und wie du gebenchmarkt hast ist daraus nicht ersichtlich.

Das habe ich hier sehr ausführlich erklärt.

Aber die Mühe musst du dir wegen mir auch nicht machen, Perl ist ohnehin nicht meine Welt.

Diesen Thread zu lesen und die Technik zu zu verstehen offensichtlich auch nicht. Im Übrigen hat das alles mit Perl gar nichts zu tun, außer daß ich den Benchmark und meine DEMOs mit Perl gemacht habe.

MfG

[pl]

Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues. Du kannst das testen indem Du einen Low-Level-Client verwendest und die Request-Headers samt Bodies in ein einziges Socket schreibst. Beim letzten Request setzt Du dann Connection: CLose und kannst alle Responses aus ein und demselben Socket lesen.

Und nicht nur das, auch hierbei kannst Du die einzelnen Bodies unzerknittert voneinander trennen, egal ob sie chunked übertragen wurden oder am Stück: Sowohl chunked als auch am Stück werden die Längenangaben mitgeliefert, so daß jeder Body bytegenau wiederhergestellt werden kann.

Auf diese Art und Weise teste ich z.B. den Status meiner Domänen und kriege auf 350 HEAD Requests 350 Responses in wenigen Augenblicken, was ansonsten sehr viel länger dauern würde. Dieses Pipelining funktioniert sogar über Proxy. Mehr zum Parsen hier und da. MfG

[1unitedpower]

Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues.

Doch, Server-Push erlaubt es dem Server nämlich auf eine Anfrage gleich mehrere Antworten zu schicken, nicht nur HTTP-Bodies, sondern ganze Anworten (Header und Bodies). Keep-Alive tut das nicht, das erlaubt nur die darunter liegende TCP-Verbindung wiederzuverwenden.

[pl]

Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues.

Doch, Server-Push erlaubt es dem Server nämlich auf eine Anfrage gleich mehrere Antworten zu schicken, nicht nur HTTP-Bodies, sondern ganze Anworten (Header und Bodies). Keep-Alive tut das nicht, das erlaubt nur die darunter liegende TCP-Verbindung wiederzuverwenden.

Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

[1unitedpower]

Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

[pl]

Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

MfG

[Mitleser]

Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig. Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

[pl]

Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig. Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

Man kann mit Serverpush beliebige Inhalte senden. Die Frage ist nur, obs der Browser auch versteht und genau dafür ist HTTP/2 zuständig. MfG

PS: http://search.cpan.org/dist/CGI/lib/CGI/Push.pm

[Mitleser]

Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

Man kann mit Serverpush beliebige Inhalte senden. Die Frage ist nur, obs der Browser auch versteht

Du kannst auch z.B. via SSH ein passendes, eigenes Protokoll entwickeln. Solange Du dafür Sorge trägst, dass Deine Besucher sich den passenden Client besorgen (bzw. Du Apple davon überzeugst, dass analog in iOS zu implementieren), der damit umgehen kann, wird das funktionieren. Da stellt sich dann nur irgendwie die Frage der Relevanz einer solchen Lösung ;-) Aber glücklicherweise haben wir da ja schon was:

und genau dafür ist HTTP/2 zuständig

You got it.

Wobei "genau dafür" erneut unpräzise ist. HTTP/2 definiert mehrere Erweiterungen, das ist nur eine. Und ja: wenn Du deine eigenen Server und Clients schreibst, dann wirst Du jede einzelne Erweiterung von HTTP/2 abbilden können. Nur ob Du es schaffst, die auch unter das Volk zu bringen, ist irgendwie fraglich, oder? Schonn kommt da irgendwie wieder die Frage nach der Relevanz auf...