HTTP/2 fichier télécharger est un peu plus lent que HTTP/1.1 pour deux raisons principales: les frais généraux de cadre et flow control.
Dans HTTP/1.1, si vous utilisez des téléchargements délimités Content-Length, les octets de contenu sont les seuls octets téléchargés. Dans HTTP/2, cependant, chaque trame DATA contient 9 octets supplémentaires pour l'en-tête de trame. À la taille d'image maximale normale de 16384 octets qui est un petit frais généraux, mais il est présent.
Le plus grand contributeur aux ralentissements possibles est le contrôle de flux HTTP/2. Le client doit s'assurer d'agrandir la fenêtre de contrôle de flux et de session par défaut, par défaut à 65535 octets. Le fonctionnement de HTTP/2 est que le serveur conserve une fenêtre send pour chaque session HTTP (session) et pour chaque flux de cette session. Lorsque le téléchargement commence, le serveur est autorisé à envoyer uniquement un nombre d'octets autorisé par la fenêtre d'envoi, pour ce flux ou cette session, selon la première éventualité. Ensuite, il doit attendre que le client envoie des trames WINDOW_UPDATE, qui réapprovisionnent le flux et les fenêtres de contrôle de flux de session, indiquant au serveur que le client est prêt à recevoir plus de données.
Pour les petites fenêtres telles que celles par défaut, ce mécanisme peut tuer les performances de téléchargement en raison de la latence réseau entre le client et le serveur, surtout s'il est implémenté naïvement. Le serveur sera bloqué la plupart du temps en attendant que le client envoie un WINDOW_UPDATE afin que le serveur puisse envoyer plus de données.
Le multiplexage joue un double rôle. Bien qu'il permette de lancer le téléchargement de plusieurs fichiers simultanément (peut-être beaucoup plus de fichiers que HTTP/1.1, ce qui peut être limité par le fait qu'il ne peut ouvrir qu'un nombre de connexions plus petit), il est également vrai que les données sont téléchargées contribue à réduire la fenêtre d'envoi de session. Chaque flux peut toujours avoir une fenêtre d'envoi non épuisée (et par conséquent il pourrait envoyer plus de données), mais la fenêtre de session est épuisée et donc le serveur doit bloquer. Les flux sont en concurrence les uns avec les autres pour consommer la fenêtre d'envoi de session. L'implémentation du serveur est également importante car elle doit entrelacer correctement les trames de plusieurs flux. Cela dit, il est toujours possible que HTTP/2 atteigne la parité avec HTTP/1.1, à condition que vous ayez une implémentation assez avancée du client et du serveur, et que vous ayez assez de boutons de réglage pour contrôler le paramètres critiques.
Idéalement, sur le client:
- capacité de contrôler la session et diffusez premières fenêtres de contrôle de flux
- une bonne mise en œuvre qui envoie
WINDOW_UPDATE cadres au serveur alors que le serveur télécharge encore, de sorte que la le serveur ne stagne jamais; cela peut nécessiter des fonctionnalités d'auto-réglage en fonction de la bandwidth-delay product (de façon similaire à ce que TCP ne)
Idéalement, sur le serveur:
- capacité à entrelacer correctement cadres de plusieurs cours d'eau de la même session (par exemple éviter de télécharger toutes les trames du premier flux, puis toutes les trames du second flux, etc., mais plutôt une trame du premier flux suivie d'une trame du second flux, puis encore une trame du premier flux, etc.
[Avertissement, je suis le mainteneur HTTP/2 de Jetty]
Jetty 9.4.x supporte toutes les fonctionnalités ci-dessus, puisque nous avons travaillé avec la communauté et les clients pour nous assurer que les téléchargements HTTP/2 sont aussi rapides que possible.
Nous avons implémenté un bon entrelacement sur le serveur, et les HttpClient et HTTP2Client de Jetty fournissent respectivement des API de haut niveau et de bas niveau pour traiter les requêtes HTTP et HTTP/2. Le contrôle de flux est implémenté dans BufferingFlowControlStrategy et permet de régler quand WINDOW_UPDATE trames sont envoyées (bien que pas encore dynamiquement). Les clients ont également des options pour configurer les fenêtres de contrôle de flux initiales. Tout dans Jetty est connectable, vous pouvez donc écrire des stratégies de contrôle de flux encore plus avancées.
Même si vous n'utilisez pas Java ou Jetty, assurez-vous de disséquer (ou d'écrire) les bibliothèques que vous utilisez sur le client et le serveur afin qu'elles offrent les fonctionnalités mentionnées ci-dessus.
Enfin, vous devez essayer et mesurer; Avec une implémentation et une configuration HTTP/2 appropriées, les effets de multiplexage devraient entrer en jeu, augmentant ainsi le parallélisme et réduisant l'utilisation des ressources sur le client et le serveur, de sorte que vous aurez un avantage sur HTTP/1.1.