HTTP/2-Datei-Download ist ein wenig langsamer als HTTP/1.1 für zwei Hauptgründe: Frame-Overhead und flow control.
In HTTP/1.1, wenn Sie Content-Length begrenzte Downloads verwenden, sind die Bytes, die nur heruntergeladen werden, die Inhaltsbytes. In HTTP/2 jedoch trägt jeder DATA Rahmen 9 zusätzliche Bytes für den Frame-Header. Bei der normalen maximalen Framegröße von 16384 Bytes ist das ein kleiner Overhead, aber es ist vorhanden.
Der größere Beitrag zu möglichen Verzögerungen ist die HTTP/2-Flusskontrolle. Der Client muss sicherstellen, dass die Fenster für die Standardsitzung und die Stream-Flusssteuerung standardmäßig um jeweils 65535 Byte erweitert werden.
Die Funktionsweise von HTTP/2 ist, dass der Server ein Sendefenster für jede HTTP/2-Sitzung (Verbindung) und für jeden Stream in dieser Sitzung hält. Wenn der Download beginnt, darf der Server nur eine bestimmte Anzahl von Bytes senden, die das Sendefenster für diesen Stream oder diese Sitzung erlaubt, je nachdem, welcher zuerst erschöpft ist. Dann muss es darauf warten, dass der Client WINDOW_UPDATE Frames sendet, die sowohl die Stream- als auch die Sitzungsflusssteuerungsfenster auffüllen und dem Server mitteilen, dass der Client bereit ist, weitere Daten zu empfangen.
Bei kleinen Fenstern wie den Standardfenstern kann dieser Mechanismus die Downloadleistung aufgrund der Netzwerklatenz zwischen Client und Server beeinträchtigen, insbesondere wenn diese naiv implementiert wird. Der Server wird die meiste Zeit blockiert, während er darauf wartet, dass der Client eine WINDOW_UPDATE sendet, damit der Server mehr Daten senden kann.
Multiplexing spielt eine doppelte Rolle. Während es möglich ist, den Download von vielen Dateien gleichzeitig zu starten (möglicherweise viel mehr Dateien als HTTP/1.1, kann dies durch die Tatsache begrenzt sein, dass es nur eine kleinere Anzahl von Verbindungen öffnen kann), ist es auch wahr, dass Daten für jeden Strom heruntergeladen werden trägt dazu bei, das Sendefenster der Sitzung zu reduzieren. Jeder Stream kann immer noch ein nicht erschöpftes Sendefenster haben (und daher könnte er mehr Daten senden), aber das Sitzungsfenster ist erschöpft und der Server muss stehen bleiben. Die Streams konkurrieren miteinander, um das Session-Sende-Fenster zu konsumieren. Die Serverimplementierung ist ebenfalls wichtig, da Frames aus mehreren Streams korrekt verschachtelt werden müssen.
Trotzdem ist es für HTTP/2 immer noch möglich, die Parität mit HTTP/1.1 zu erreichen, vorausgesetzt, Sie haben eine ziemlich fortgeschrittene Implementierung sowohl des Clients als auch des Servers, und Sie haben genug Tuning-Regler kritische Parameter.
Idealerweise auf dem Client:
- Fähigkeit, die Sitzung zu steuern und Steuer anfängliche Fließ Fenster streamen
- eine gute Implementierung, die
WINDOW_UPDATE Frames an den Server sendet, während der Server noch heruntergeladen wird, so dass die Server bleibt nie stehen; dies kann auf der bandwidth-delay product je Self-Tuning-Funktionen erfordern (ähnlich wie TCP tut)
Idealerweise auf dem Server:
- Fähigkeit richtig zu Rahmen aus mehreren Streams von der gleichen Sitzung verschachteln (zB Vermeiden Sie, alle Frames des ersten Streams herunterzuladen, dann alle Frames des zweiten Streams usw., sondern ein Frame des ersten Streams, gefolgt von einem Frame des zweiten Streams, dann wieder einem Frame des ersten Streams usw.)
[Disclaimer, I bin der HTTP/2 Betreuer des Jetty]
Jetty 9.4.x unterstützt alle oben genannten Funktionen, da wir mit der Gemeinde und Kunden gearbeitet haben, um sicherzustellen, dass HTTP/2 downloads so schnell wie möglich sind.
Wir haben das richtige Interleaving auf dem Server implementiert, und Jettys HttpClient und HTTP2Client bieten High- und Low-Level-APIs für HTTP- und HTTP/2-Anfragen. Die Flusssteuerung ist in BufferingFlowControlStrategy implementiert und ermöglicht es zu tunen, wenn WINDOW_UPDATE Frames gesendet werden (obwohl noch nicht dynamisch). Die Clients verfügen auch über Optionen zum Konfigurieren der anfänglichen Ablaufsteuerungsfenster. Alles in Jetty ist steckbar, so dass Sie vielleicht noch mehr fortgeschrittene Strategien zur Flusskontrolle schreiben können.
Auch wenn Sie weder Java noch Jetty verwenden, stellen Sie sicher, dass Sie die Bibliotheken, die Sie sowohl auf dem Client als auch auf dem Server verwenden, zerlegen (oder schreiben), damit sie die oben genannten Funktionen bereitstellen.
Schließlich müssen Sie versuchen und messen; Bei einer korrekten HTTP/2-Implementierung und -Konfiguration sollten die Multiplexing-Effekte ins Spiel kommen, wodurch die Parallelität erhöht und die Ressourcennutzung sowohl auf dem Client als auch auf dem Server reduziert wird, so dass Sie einen Vorteil gegenüber HTTP/1.1 haben.