Hi Urs
Wie versprochen die Analyse von Fefe zu HTTP/2 was hältst du davon? https://blog.fefe.de/?ts=aa031bbb
Gruss Michel
On 2015-06-11, Michel Ketterle wrote:
Wie versprochen die Analyse von Fefe zu HTTP/2 was hältst du davon? https://blog.fefe.de/?ts=aa031bbb
Hierzu eventuell auch interessant:
http://queue.acm.org/detail.cfm?id=2716278
On Fri, 12 Jun 2015 12:28:36 +0200 Elias Diem pub@webconect.ch wrote:
On 2015-06-11, Michel Ketterle wrote:
Wie versprochen die Analyse von Fefe zu HTTP/2 was hältst du davon? https://blog.fefe.de/?ts=aa031bbb
Hierzu eventuell auch interessant:
Ich würde noch hinzufügen, dass in meinen Augen das wirkliche Grund warum der Header-Bloat, den Fefe (m.E. völlig zu Recht) kritisiert, ein Problem ist, nicht in der Verschwendung von Übertragungs-Bandbreite, sondern in der resultierenden zusätzlichen Komplexität liegt. Die Idee, die Header nun zu komprimieren nützt im Hinblick darauf gar nichts, ganz im Gegenteil!
Herzliche Grüsse, Norbert
Hallo, leider fällt es mir schwer, bei dem Schreibstiel den Inhalt ernst zu nehmen. Ich versuche es trotzdem, meine Informationen habe ich von [1] und natürlich [2].
Das zu viel Header Information übertragen werden löst HTTP/2 vielleicht nicht, aber macht es wohl auch nicht schlimmer.
Nach [1] ist die jetzige Situation folgendermassen: Ein Klient muss jenste Dateien herunterladen (Bilder, CSS, Javascripte). Um dies schneller zu machen (die Anfrage-Antwort-Anfrage Schleife durchbrechen), macht er mehrere parallele Verbindungen auf. Die Anzahl ist jedoch stark begrenzt. Eine Abhilfe ist, mehrere Bilder auf eins zu packen und per CSS jeweils nur den relevanten Teil anzuzeigen oder aber die Dateien auf verschiedene domains verteilen, weil nur die Anzahl Verbindungen zu derselben Domain begrenzt sind. Eventuell gibt es noch weitere Tricks, aber es ist auf jeden Fall ein gebastel.
Hier schafft das Multiplexing Abhilfe weil der Klient alle Anfragen auf einmal schicken kann und die Daten in der Reihenfolge kommen, wie sie der Server bereitstellen kann. Um es noch mehr zu beschleunigen kann der Server/Webseitenbetreiber Dateien ausliefern bevor der Klient überhaupt weiss, das er sie will.
Ein Punkt den fefe nicht anspricht ist, dass Inhalte und soweit ich mich erinnern kann auch Header binär wie auch komprimiert Übertragen werden (können). Dies spart noch etwas Bandbreite und macht es einfacher, den Header zu parsen.
Was fefe gescheiter kritisieren würde ist die nicht obligatorische Verschlüsselung, denn dieser Punkt stammt angeblich von den erwarteten Stellen.
Auch wenn alles zutrifft was fefe schreibt entnehme ich dem Text dennoch, dass es mit HTTP/2 schneller funktionieren wird weil die Techniken dann obligatorisch implementiert werden müssen.
Grüsse Urs
[1] https://fosdem.org/2015/schedule/event/http2_right_now/ [2] http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP.2F2
Am Donnerstag, den 11.06.2015, 23:52 +0200 schrieb Michel Ketterle:
Hi Urs
Wie versprochen die Analyse von Fefe zu HTTP/2 was hältst du davon? https://blog.fefe.de/?ts=aa031bbb
Gruss Michel _______________________________________________ Zurich mailing list Zurich@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/zurich