Warum wird eine HTTP/2-Multiplex-Demo mit mehreren Verbindungen durchgeführt?

Question

In diesen Tagen evaluiere ich HTTP/2 (auf Nginx), als ein möglicher Kandidat für die Steigerung der Leistung meiner Anwendung.

Ich schaute auf this netter Akamai HTTP2 Demo. Von dieser Demo kann ich sehen, dass der "http2" -Teil viel schneller lädt, anscheinend dank HTTP2-Multiplexing-Funktion.

Also beschloss ich, ein wenig genauer hinzusehen. Ich habe die Chrome-Entwickler-Tools (Version 51) geöffnet und das Netzwerk-Fenster untersucht.

Ich erwartete, eine einzige Netzwerkverbindung zu sehen, die alle Anforderungen behandelt (z. B. Multiplexing).

Allerdings sehe ich mehrere Verbindungen ausgegeben, eine pro Bild Fliese:

Außerdem sehe ich, dass es eine Verzögerung ("abgewürgt") für fast jeden reques:

Ich erwartete, dass (im Gegensatz zu HTTP1) alle Anfragen parallel ohne Verzögerungen ausgegeben werden. Würde mir jemand helfen zu verstehen, was vor sich geht?

Answer 1

Was Sie sehen, sind nicht mehrere Verbindungen, eine pro Bildkachel, aber mehrere Anfragen, eine pro Bildkachel, auf einer einzigen TCP-Verbindung.

Die Tatsache, die gemultiplext werden, ist offensichtlich, weil eine große Anzahl von Anfragen (Zehner oder sogar Hunderte) gleichzeitig gesendet werden. Sehen Sie, wie die Anfragen vertikal ausgerichtet sind.

Vergleichen Sie dies mit einem HTTP/1.1-Profil, und Sie werden ein Ziggurat-ähnliches Profil sehen, da nur (normalerweise) 6 Anfragen gleichzeitig gesendet werden können. Siehe zum Beispiel diese Präsentation, die ich bei 39:54 gab.

Was Sie sehen, ist daher das erwartete Profil für ein Multiplex-Protokoll wie HTTP/2.

Die winzige "blockierte" Verzögerung, die für diese Anforderungen angezeigt wird, kann auf interne Implementierungsverzögerungen (z. B. Warteschlangen) sowie HTTP/2-Protokolldetails wie Ablaufsteuerung zurückzuführen sein.