L'auteur a sélectionné lesSociety of Women Engineers pour recevoir un don dans le cadre du programmeWrite for DOnations.
introduction
Le protocole de transfert hypertexte, ou HTTP, est un protocole d’application qui est le standard de facto pour la communication sur le World Wide Web depuis son invention en 1989. Depuis la publication de HTTP / 1.1 en 1997 jusqu'à récemment, peu de révisions du protocole ont été effectuées. Cependant, en 2015, une version repensée appelée HTTP / 2 est entrée en service. Elle proposait plusieurs méthodes pour réduire la latence, en particulier pour les plates-formes mobiles et les graphiques et vidéos gourmands en serveurs. HTTP/2 has since become increasingly popular, with some estimates suggesting that around a third of all websites in the world support it. Dans ce paysage en évolution, les développeurs Web peuvent tirer profit de la compréhension des différences techniques entre HTTP / 1.1 et HTTP / 2, leur permettant de prendre des décisions éclairées et efficaces concernant l'évolution des meilleures pratiques.
Après avoir lu cet article, vous comprendrez les principales différences entre HTTP / 1.1 et HTTP / 2, en vous concentrant sur les modifications techniques que HTTP / 2 a adoptées pour obtenir un protocole Web plus efficace.
Contexte
Pour contextualiser les modifications spécifiques apportées par HTTP / 2 à HTTP / 1.1, examinons d’abord le développement historique et le fonctionnement de base de chacun.
HTTP/1.1
Développé par Timothy Berners-Lee en 1989 en tant que norme de communication pour le World Wide Web, HTTP est un protocole d’application de niveau supérieur qui échange des informations entre un ordinateur client et un serveur Web local ou distant. Dans ce processus, un client envoie une requête textuelle à un serveur en appelant unmethod commeGET ouPOST. En réponse, le serveur envoie une ressource, telle qu'une page HTML, au client.
Par exemple, supposons que vous visitez un site Web du domainewww.example.com. Lorsque vous accédez à cette URL, le navigateur Web de votre ordinateur envoie une requête HTTP sous la forme d'un message textuel, similaire à celui présenté ici:
GET /index.html HTTP/1.1
Host: www.example.comCette requête utilise la méthodeGET, qui demande des données au serveur hôte répertorié aprèsHost:. En réponse à cette demande, le serveur Web deexample.comrenvoie une page HTML au client demandeur, en plus des images, feuilles de style ou autres ressources demandées dans le HTML. Notez que toutes les ressources ne sont pas renvoyées au client lors du premier appel de données. Les demandes et les réponses vont et viennent entre le serveur et le client jusqu'à ce que le navigateur Web ait reçu toutes les ressources nécessaires pour afficher le contenu de la page HTML sur votre écran.
Vous pouvez considérer cet échange de demandes et de réponses comme unapplication layer unique de la pile de protocoles Internet, assis au-dessus destransfer layer (généralement en utilisant le protocole de contrôle de transmission, ou TCP) etnetworking layers (en utilisant le protocole Internet ou IP):
Il y a beaucoup à discuter sur les niveaux les plus bas de cette pile, mais pour acquérir une compréhension de haut niveau de HTTP / 2, il vous suffit de connaître ce modèle de couche abstraite et où HTTP figure dans ce dernier.
Avec cette vue d’ensemble de base de HTTP / 1.1, nous pouvons maintenant passer en revue les premiers développements de HTTP / 2.
HTTP/2
HTTP/2 began as the SPDY protocol, developed primarily at Google with the intention of reducing web page load latency by using techniques such as compression, multiplexing, and prioritization. Ce protocole a servi de modèle pour HTTP / 2 lorsque le groupe de travail du protocole de transfert hypertexte httpbis desIETF (Internet Engineering Task Force) a élaboré le standard, aboutissant à la publication de HTTP / 2 en mai 2015. Depuis le début, de nombreux navigateurs ont pris en charge cet effort de normalisation, notamment Chrome, Opera, Internet Explorer et Safari. En partie grâce à la prise en charge de ce navigateur, le protocole a adopté un taux important depuis 2015, avec des taux particulièrement élevés parmi les nouveaux sites.
D'un point de vue technique, l'une des caractéristiques les plus importantes qui distinguent HTTP / 1.1 et HTTP / 2 est la couche de cadrage binaire, qui peut être considérée comme faisant partie de la couche d'application de la pile de protocoles Internet. Contrairement à HTTP / 1.1, qui conserve toutes les demandes et les réponses au format texte brut, HTTP / 2 utilise la couche de cadrage binaire pour encapsuler tous les messages au format binaire, tout en conservant la sémantique HTTP, telle que les verbes, les méthodes et les en-têtes. Une API au niveau de l’application créerait toujours des messages dans les formats HTTP classiques, mais la couche sous-jacente convertirait alors ces messages en binaire. Cela garantit que les applications Web créées avant HTTP / 2 peuvent continuer à fonctionner normalement lors de l'interaction avec le nouveau protocole.
La conversion des messages en binaire permet à HTTP / 2 d’essayer de nouvelles approches de remise des données non disponibles dans HTTP / 1.1, contraste qui est à la base des différences pratiques entre les deux protocoles. La section suivante examinera le modèle de livraison HTTP / 1.1, suivi des nouveaux modèles rendus possibles par HTTP / 2.
Modèles de livraison
Comme mentionné dans la section précédente, HTTP / 1.1 et HTTP / 2 partagent la sémantique, garantissant que les requêtes et réponses voyageant entre le serveur et le client dans les deux protocoles atteignent leurs destinations sous forme de messages au format traditionnel avec en-têtes et corps, en utilisant des méthodes familières commeGET etPOST. Cependant, alors que HTTP / 1.1 les transfère sous forme de messages en texte brut, HTTP / 2 les code en binaire, ce qui permet des possibilités de modèle de livraison très différentes. Dans cette section, nous examinerons d’abord brièvement la façon dont HTTP / 1.1 tente d’optimiser l’efficacité avec son modèle de livraison et les problèmes qui en découlent, puis les avantages de la couche de cadrage binaire de HTTP / 2 et une description de la hiérarchisation des priorités. demandes.
[[http-1-1 -—- pipelining-and-head-of-line-blocking]] === HTTP / 1.1 - Pipelining et Head-of-Line Blocking
La première réponse qu'un client reçoit sur une requête HTTPGET n'est souvent pas la page entièrement rendue. Au lieu de cela, il contient des liens vers des ressources supplémentaires requises par la page demandée. Le client découvre que le rendu complet de la page nécessite ces ressources supplémentaires du serveur uniquement après le téléchargement de la page. De ce fait, le client devra faire des demandes supplémentaires pour récupérer ces ressources. Dans HTTP / 1.0, le client devait rompre et refaire la connexion TCP à chaque nouvelle requête, ce qui était coûteux en temps et en ressources.
HTTP/1.1 takes care of this problem by introducing persistent connections and pipelining. Avec les connexions persistantes, HTTP / 1.1 suppose qu’une connexion TCP doit rester ouverte, sauf indication directe de la fermeture. Cela permet au client d’envoyer plusieurs demandes sur la même connexion sans attendre de réponse, ce qui améliore considérablement les performances de HTTP / 1.1 sur HTTP / 1.0.
Malheureusement, cette stratégie d'optimisation constitue un goulet d'étranglement naturel. Etant donné que plusieurs paquets de données ne peuvent pas se croiser lorsqu’ils se rendent à la même destination, il arrive parfois qu’une demande en tête de la file qui ne puisse pas extraire la ressource requise bloque toutes les demandes qui la suivent. Ceci est connu sous le nom dehead-of-line (HOL) blocking et constitue un problème important lors de l'optimisation de l'efficacité de la connexion dans HTTP / 1.1. L'ajout de connexions TCP parallèles distinctes pourrait résoudre ce problème, mais le nombre de connexions TCP simultanées possibles entre un client et un serveur est limité, et chaque nouvelle connexion nécessite des ressources importantes.
Ces problèmes étaient au cœur des préoccupations des développeurs HTTP / 2, qui ont proposé d’utiliser la couche de cadrage binaire susmentionnée pour résoudre ces problèmes, sujet que vous découvrirez plus en détail dans la section suivante.
[[http-2 -—- avantages-de-la-couche-de-cadrage-binaire]] === HTTP / 2 - Avantages de la couche de cadrage binaire
Dans HTTP / 2, la couche de cadrage binaire code les demandes / réponses et les découpe en paquets d’informations plus petits, ce qui augmente considérablement la flexibilité du transfert de données.
Voyons de plus près comment cela fonctionne. Contrairement à HTTP / 1.1, qui doit utiliser plusieurs connexions TCP pour atténuer les effets du blocage HOL, HTTP / 2 établit un seul objet de connexion entre les deux ordinateurs. Dans cette connexion, il y a plusieursstreams de données. Chaque flux est composé de plusieurs messages dans le format de requête / réponse habituel. Enfin, chacun de ces messages se divise en unités plus petites appeléesframes:
Au niveau le plus granulaire, le canal de communication consiste en un ensemble de trames codées en binaire, chacune étant étiquetée vers un flux particulier. Les étiquettes d’identification permettent à la connexion d’entrelacer ces trames pendant le transfert et de les réassembler à l’autre extrémité. Les requêtes et réponses entrelacées peuvent s'exécuter en parallèle sans bloquer les messages derrière elles, un processus appelémultiplexing. Le multiplexage résout le problème de blocage en tête de ligne dans HTTP / 1.1 en s'assurant qu'aucun message ne doit attendre la fin d'un autre message. Cela signifie également que les serveurs et les clients peuvent envoyer des demandes et des réponses simultanées, ce qui permet un meilleur contrôle et une gestion des connexions plus efficace.
Étant donné que le multiplexage permet au client de créer plusieurs flux en parallèle, ces derniers doivent uniquement utiliser une seule connexion TCP. Le fait d'avoir une seule connexion persistante par origine améliore HTTP / 1.1 en réduisant l'encombrement de la mémoire et du traitement sur l'ensemble du réseau. Cela se traduit par une meilleure utilisation de la bande passante et du réseau, réduisant ainsi le coût opérationnel global.
Une seule connexion TCP améliore également les performances du protocole HTTPS, car le client et le serveur peuvent réutiliser la même session sécurisée pour plusieurs demandes / réponses. En HTTPS, lors de la négociation TLS ou SSL, les deux parties conviennent de l’utilisation d’une clé unique tout au long de la session. Si la connexion est interrompue, une nouvelle session démarre, nécessitant une nouvelle clé générée pour une communication ultérieure. Ainsi, le maintien d'une connexion unique peut réduire considérablement les ressources requises pour les performances HTTPS. Notez que, bien que les spécifications HTTP / 2 ne rendent pas obligatoire l’utilisation de la couche TLS, de nombreux principaux navigateurs ne prennent en charge que HTTP / 2 avec HTTPS.
Bien que le multiplexage inhérent à la couche de cadrage binaire résolve certains problèmes de HTTP / 1.1, plusieurs flux en attente de la même ressource peuvent toujours entraîner des problèmes de performances. La conception de HTTP / 2 tient compte de cela, cependant, en utilisant la hiérarchisation des flux, un sujet que nous aborderons dans la section suivante.
[[http-2 -—- stream-priorityization]] === HTTP / 2 - Hiérarchisation des flux
La hiérarchisation des flux résout non seulement le problème possible de demandes en concurrence pour la même ressource, mais permet également aux développeurs de personnaliser le poids relatif des demandes afin d'optimiser les performances de l'application. Dans cette section, nous allons détailler le processus de cette hiérarchisation afin de mieux comprendre comment vous pouvez exploiter cette fonctionnalité de HTTP / 2.
Comme vous le savez maintenant, la couche de cadrage binaire organise les messages en flux de données parallèles. Lorsqu'un client envoie des demandes simultanées à un serveur, il peut hiérarchiser les réponses qu'il demande en attribuant un poids compris entre 1 et 256 à chaque flux. Le nombre le plus élevé indique une priorité plus élevée. En outre, le client indique également la dépendance de chaque flux par rapport à un autre flux en spécifiant l’ID du flux dont il dépend. Si l'identifiant parent est omis, le flux est considéré comme dépendant du flux racine. Ceci est illustré dans la figure suivante:
Dans l'illustration, le canal contient six flux, chacun avec un identifiant unique et associé à un poids spécifique. Le flux 1 n'a pas d'ID parent associé et est associé par défaut au noeud racine. Tous les autres flux ont un ID parent marqué. L'allocation des ressources pour chaque flux sera basée sur le poids qu'ils détiennent et les dépendances dont ils ont besoin. Les flux 5 et 6, par exemple, auxquels le même poids et le même flux parent ont été attribués, auront la même priorité pour l'allocation des ressources.
Le serveur utilise ces informations pour créer un arbre de dépendance, ce qui lui permet de déterminer l'ordre dans lequel les requêtes vont récupérer leurs données. Sur la base des flux de la figure précédente, l'arbre de dépendance sera le suivant:
Dans cet arbre de dépendance, le flux 1 dépend du flux racine et il n'y a pas d'autre flux dérivé de la racine. Par conséquent, toutes les ressources disponibles seront allouées au flux 1 avant les autres flux. Puisque l'arbre indique que le flux 2 dépend de l'achèvement du flux 1, le flux 2 ne sera pas poursuivi tant que la tâche du flux 1 n'est pas terminée. Voyons maintenant les flux 3 et 4. Ces deux flux dépendent du flux 2. Comme dans le cas du flux 1, le flux 2 obtiendra toutes les ressources disponibles avant les flux 3 et 4. Lorsque le flux 2 aura terminé sa tâche, les flux 3 et 4 obtiendront les ressources; ceux-ci sont divisés en un rapport de 2: 4, comme l'indiquent leurs pondérations, ce qui entraîne une part plus importante des ressources du flux 4. Enfin, lorsque le flux 3 sera terminé, les flux 5 et 6 obtiendront les ressources disponibles à parts égales. Cela peut se produire avant que le flux 4 ait terminé sa tâche, même si le flux 4 reçoit une plus grande quantité de ressources; les flux d'un niveau inférieur sont autorisés à démarrer dès que les flux dépendants d'un niveau supérieur sont terminés.
En tant que développeur d'applications, vous pouvez définir le poids de vos demandes en fonction de vos besoins. Par exemple, vous pouvez attribuer une priorité plus faible au chargement d’une image avec une résolution élevée après avoir fourni une image miniature sur la page Web. En fournissant cette fonction d’affectation du poids, HTTP / 2 permet aux développeurs de mieux contrôler le rendu des pages Web. Le protocole permet également au client de modifier les dépendances et de réaffecter les pondérations lors de l'exécution en réponse aux interactions de l'utilisateur. Cependant, il est important de noter qu'un serveur peut modifier seul les priorités attribuées si un flux donné ne peut accéder à une ressource spécifique.
Débordement de tampon
Dans toute connexion TCP entre deux ordinateurs, le client et le serveur disposent chacun d’une certaine quantité d’espace tampon pour contenir les demandes entrantes qui n’ont pas encore été traitées. Ces mémoires tampons offrent la possibilité de prendre en compte les demandes nombreuses ou particulièrement volumineuses, en plus des vitesses inégales des connexions en aval et en amont.
Il existe cependant des situations dans lesquelles un tampon n'est pas suffisant. Par exemple, le serveur peut envoyer une grande quantité de données à un rythme que l'application cliente ne peut pas gérer en raison d'une taille de mémoire tampon limitée ou d'une bande passante inférieure. De même, lorsqu'un client télécharge une image ou une vidéo de grande taille sur un serveur, la mémoire tampon du serveur risque de déborder, ce qui entraînera la perte de certains paquets supplémentaires.
Afin d'éviter tout débordement de mémoire tampon, un mécanisme de contrôle de flux doit empêcher l'expéditeur de submerger le destinataire de données. Cette section fournit un aperçu de la manière dont HTTP / 1.1 et HTTP / 2 utilisent différentes versions de ce mécanisme pour traiter le contrôle de flux en fonction de leurs différents modèles de livraison.
HTTP/1.1
Dans HTTP / 1.1, le contrôle de flux repose sur la connexion TCP sous-jacente. Lorsque cette connexion est établie, le client et le serveur établissent leurs tailles de mémoire tampon en utilisant leurs paramètres système par défaut. Si le tampon du récepteur est partiellement rempli de données, il indiquera à l'expéditeur sesreceive window, c'est-à-dire la quantité d'espace disponible qui reste dans son tampon. Cette fenêtre de réception est publiée dans un signal connu sous le nom deACK packet, qui est le paquet de données que le récepteur envoie pour accuser réception du signal d'ouverture. Si la taille de la fenêtre de réception annoncée est zéro, l'expéditeur n'enverra plus de données tant que le client n'aura pas effacé sa mémoire tampon interne, puis une demande de reprise de la transmission des données. Il est important de noter ici que l'utilisation de fenêtres de réception basées sur la connexion TCP sous-jacente peut uniquement implémenter le contrôle de flux à l'une ou l'autre des extrémités de la connexion.
Étant donné que HTTP / 1.1 s'appuie sur la couche de transport pour éviter le débordement de mémoire tampon, chaque nouvelle connexion TCP nécessite un mécanisme de contrôle de flux distinct. HTTP/2, however, multiplexes streams within a single TCP connection, and will have to implement flow control in a different manner.
HTTP/2
HTTP/2 multiplexes streams of data within a single TCP connection. En conséquence, les fenêtres de réception au niveau de la connexion TCP ne suffisent pas pour réguler la livraison de flux individuels. HTTP/2 solves this problem by allowing the client and server to implement their own flow controls, rather than relying on the transport layer. La couche application communique l'espace tampon disponible, permettant ainsi au client et au serveur de définir la fenêtre de réception au niveau des flux multiplexés. Ce contrôle de flux à échelle fine peut être modifié ou maintenu après la connexion initiale via une trameWINDOW_UPDATE.
Comme cette méthode contrôle le flux de données au niveau de la couche application, le mécanisme de contrôle de flux n'a pas besoin d'attendre qu'un signal atteigne sa destination finale avant d'ajuster la fenêtre de réception. Les nœuds intermédiaires peuvent utiliser les informations de paramètres de contrôle de flux pour déterminer leurs propres allocations de ressources et les modifier en conséquence. Ainsi, chaque serveur intermédiaire peut mettre en œuvre sa propre stratégie de ressources personnalisée, permettant une efficacité de connexion accrue.
Cette flexibilité dans le contrôle de flux peut être avantageuse lors de la création de stratégies de ressources appropriées. Par exemple, le client peut extraire le premier scan d'une image, l'afficher à l'utilisateur et lui permettre de l'aperçu tout en récupérant des ressources plus critiques. Une fois que le client aura récupéré ces ressources critiques, le navigateur reprendra la récupération de la partie restante de l'image. Le report de la mise en œuvre du contrôle de flux sur le client et le serveur peut ainsi améliorer les performances perçues des applications Web.
En termes de contrôle de flux et de priorisation de flux mentionné dans une section précédente, HTTP / 2 fournit un niveau de contrôle plus détaillé qui ouvre la possibilité d’une optimisation accrue. La section suivante expliquera une autre méthode unique au protocole qui peut améliorer une connexion de la même manière: prédire les demandes de ressources avecserver push.
Prédire les demandes de ressources
Dans une application Web typique, le client enverra une requêteGET et recevra une page en HTML, généralement la page d'index du site. Lors de l'examen du contenu de la page d'index, le client peut découvrir qu'il doit extraire des ressources supplémentaires, telles que des fichiers CSS et JavaScript, afin de restituer entièrement le rendu de la page. Le client détermine qu'il n'a besoin de ces ressources supplémentaires qu'après avoir reçu la réponse de sa demande initialeGET, et doit donc faire des demandes supplémentaires pour récupérer ces ressources et terminer l'assemblage de la page. Ces demandes supplémentaires augmentent en fin de compte le temps de chargement de la connexion.
Il existe toutefois des solutions à ce problème: puisque le serveur sait à l'avance que le client aura besoin de fichiers supplémentaires, le serveur peut économiser le temps du client en envoyant ces ressources au client avant qu'il ne les demande. HTTP/1.1 and HTTP/2 have different strategies of accomplishing this, each of which will be described in the next section.
[[http-1-1 -—- resource-inlining]] === HTTP / 1.1 - Resource Inlining
Dans HTTP / 1.1, si le développeur sait à l'avance de quelles ressources supplémentaires la machine cliente aura besoin pour rendre la page, il peut utiliser une technique appeléeresource inlining pour inclure la ressource requise directement dans le document HTML que le serveur envoie réponse à la demande initiale deGET. Par exemple, si un client a besoin d'un fichier CSS spécifique pour restituer une page, cette ligne fournira au client la ressource nécessaire avant de la demander, ce qui réduira le nombre total de demandes que le client doit envoyer.
Mais il existe quelques problèmes d’inclusion de ressources. L'inclusion de la ressource dans le document HTML est une solution viable pour les ressources textuelles plus petites, mais les fichiers plus volumineux dans des formats autres que le texte peuvent augmenter considérablement la taille du document HTML, ce qui peut finalement réduire la vitesse de connexion et annuler l'avantage initial d'utiliser cette technique. De plus, les ressources en ligne n'étant plus séparées du document HTML, le client ne dispose d'aucun mécanisme lui permettant de décliner les ressources qu'il possède déjà ou de placer une ressource dans son cache. Si plusieurs pages nécessitent la ressource, chaque nouveau document HTML aura la même ressource insérée dans son code, ce qui donnera des documents HTML plus volumineux et des temps de chargement plus longs que si la ressource était simplement mise en cache au début.
L’inconvénient majeur de l’inclusion de ressources est donc que le client ne peut pas séparer la ressource et le document. Un niveau de contrôle plus fin est nécessaire pour optimiser la connexion, un besoin que HTTP / 2 cherche à satisfaire avec la diffusion du serveur.
[[http-2 -—- server-push]] === HTTP / 2 - Server Push
Étant donné que HTTP / 2 permet plusieurs réponses simultanées à la demande initialeGET d'un client, un serveur peut envoyer une ressource à un client avec la page HTML demandée, en fournissant la ressource avant que le client ne la demande. Ce processus est appeléserver push. De cette manière, une connexion HTTP / 2 peut atteindre le même objectif d’inclusion de ressources tout en maintenant la séparation entre la ressource insérée et le document. Cela signifie que le client peut décider de mettre en cache ou de décliner la ressource insérée séparément du document HTML principal, ce qui corrige l'inconvénient majeur de l'inlineline.
Dans HTTP / 2, ce processus commence lorsque le serveur envoie une tramePUSH_PROMISE pour informer le client qu'il va pousser une ressource. Cette trame n'inclut que l'en-tête du message et permet au client de savoir à l'avance quelle ressource le serveur enverra. S'il a déjà mis la ressource en cache, le client peut refuser le push en envoyant une trameRST_STREAM en réponse. La tramePUSH_PROMISE évite également au client d'envoyer une demande en double au serveur, car il sait quelles ressources le serveur va pousser.
Il est important de noter ici que l’accent mis sur l’accès serveur est le contrôle du client. Si un client avait besoin d'ajuster la priorité du serveur push, voire de le désactiver, il pouvait à tout moment envoyer une trameSETTINGS pour modifier cette fonctionnalité HTTP / 2.
Bien que cette fonctionnalité ait beaucoup de potentiel, le serveur push n’est pas toujours la solution pour optimiser votre application Web. Par exemple, certains navigateurs Web ne peuvent pas toujours annuler les demandes envoyées, même si la ressource est déjà mise en cache sur le client. Si le client autorise par erreur le serveur à envoyer une ressource en double, le serveur Push peut utiliser la connexion inutilement. En fin de compte, le serveur push devrait être utilisé à la discrétion du développeur. Pour en savoir plus sur l'utilisation stratégique du serveur push et l'optimisation des applications Web, consultez lesPRPL pattern développés par Google. Pour en savoir plus sur les problèmes possibles avec le serveur push, consultez l'article de blog de Jake ArchibaldHTTP/2 push is tougher than I thought.
Compression
Une méthode courante d'optimisation des applications Web consiste à utiliser des algorithmes de compression pour réduire la taille des messages HTTP qui transitent entre le client et le serveur. HTTP/1.1 and HTTP/2 both use this strategy, but there are implementation problems in the former that prohibit compressing the entire message. La section suivante explique pourquoi, et comment HTTP / 2 peut apporter une solution.
HTTP/1.1
Des programmes commegzip ont longtemps été utilisés pour compresser les données envoyées dans les messages HTTP, notamment pour diminuer la taille des fichiers CSS et JavaScript. Le composant en-tête d'un message est toutefois toujours envoyé sous forme de texte brut. Bien que chaque en-tête soit relativement petit, le poids de ces données non compressées pèse de plus en plus lourd sur la connexion, à mesure que davantage de demandes sont émises, notamment en pénalisant les applications Web complexes, lourdes en API, qui nécessitent de nombreuses ressources différentes et donc de nombreuses demandes de ressources différentes. De plus, l'utilisation de cookies peut parfois rendre les en-têtes beaucoup plus volumineuses, ce qui augmente le besoin de compression.
Pour résoudre ce goulot d'étranglement, HTTP / 2 utilise la compression HPACK pour réduire la taille des en-têtes, un sujet traité plus en détail dans la section suivante.
HTTP/2
L'un des thèmes récurrents dans HTTP / 2 est sa capacité à utiliser la couche de cadrage binaire pour mieux contrôler les détails les plus fins. La même chose est vraie en ce qui concerne la compression d'en-tête. HTTP/2 can split headers from their data, resulting in a header frame and a data frame. Le programme de compression spécifique HTTP / 2HPACK peut ensuite compresser cette trame d'en-tête. Cet algorithme peut coder les métadonnées d'en-tête à l'aide du codage de Huffman, ce qui en diminue considérablement la taille. En outre, HPACK peut suivre les champs de métadonnées précédemment transmis et les compresser selon un index modifié dynamiquement et partagé entre le client et le serveur. Par exemple, prenons les deux demandes suivantes:
Demande n ° 1
method: GET
scheme: https
host: example.com
path: /academy
accept: /image/jpeg
user-agent: Mozilla/5.0 ...Demande n ° 2
method: GET
scheme: https
host: example.com
path: /academy/images
accept: /image/jpeg
user-agent: Mozilla/5.0 ...Les différents champs de ces requêtes, tels quemethod,scheme,host,accept etuser-agent, ont les mêmes valeurs; seul le champpath utilise une valeur différente. Par conséquent, lors de l'envoi deRequest #2, le client peut utiliser HPACK pour envoyer uniquement les valeurs indexées nécessaires pour reconstruire ces champs communs et encoder nouvellement le champpath. Les images d'en-tête résultantes seront les suivantes:
Cadre d'en-tête pour la demande n ° 1
method: GET
scheme: https
host: example.com
path: /academy
accept: /image/jpeg
user-agent: Mozilla/5.0 ...Cadre d'en-tête pour la demande n ° 2
path: /academy/imagesÀ l’aide de HPACK et d’autres méthodes de compression, HTTP / 2 offre une fonctionnalité supplémentaire qui peut réduire la latence client-serveur.
Conclusion
Comme vous pouvez le constater à partir de cette analyse point par point, HTTP / 2 diffère de HTTP / 1.1 à bien des égards, certaines fonctionnalités offrant des niveaux de contrôle plus importants pouvant être utilisés pour optimiser les performances des applications Web, tandis que d’autres améliorent simplement la protocole précédent. Maintenant que vous avez acquis une perspective de haut niveau sur les variations entre les deux protocoles, vous pouvez considérer comment des facteurs tels que le multiplexage, la hiérarchisation des flux, le contrôle de flux, la diffusion sur serveur et la compression dans HTTP / 2 affecteront le paysage changeant du développement Web. .
Si vous souhaitez voir une comparaison des performances entre HTTP / 1.1 et HTTP / 2, consultez ceGoogle demo qui compare les protocoles pour différentes latences. Notez que lorsque vous exécutez le test sur votre ordinateur, le temps de chargement d'une page peut varier en fonction de plusieurs facteurs, tels que la bande passante, les ressources client et serveur disponibles au moment du test, etc. Si vous souhaitez étudier les résultats de tests plus exhaustifs, consultez l'articleHTTP/2 – A Real-World Performance Test and Analysis. Enfin, si vous souhaitez découvrir comment créer une application Web moderne, vous pouvez suivre notre tutorielHow To Build a Modern Web Application to Manage Customer Information with Django and React on Ubuntu 18.04, ou configurer votre propre serveur HTTP / 2 avec notre tutorielHow To Set Up Nginx with HTTP/2 Support on Ubuntu 16.04.