Vous n'avez peut-être pas encore entendu parler de HTTP/2, mais il s'agit de la mise à jour la plus récente de HTTP. La nouvelle norme de protocole introduit de nouveaux concepts et rend la communication entre les serveurs et les applications plus rapide et plus efficace.
HyperText Transfer Protocol Version 2, ou HTTP/2, est la première mise à jour majeure de HTTP en 15 ans.
La norme de protocole précédente, HTTP/1.1, est utilisée depuis 1997 et utilise un mélange de solutions de contournement maladroites pour améliorer les limitations de HTTP.
Il est basé sur SPDY ("speedy"), une expérience open source lancée par Google pour résoudre certains des problèmes et limitations de HTTP/1.1
L'Internet Engineering Task Force (IETF) spécifie les changements comme celui-ci dans la version 2 du protocole de transfert hypertexte, brouillon 17 :
« HTTP/2 permet une utilisation plus efficace des ressources réseau et une perception réduite de la latence en introduisant la compression des champs d'en-tête et en permettant plusieurs échanges simultanés sur la même connexion [...]
"Il permet également de hiérarchiser les demandes, permettant aux demandes plus importantes de se terminer plus rapidement, améliorant encore les performances."
"HTTP/2 permet également un traitement plus efficace des messages grâce à l'utilisation du cadrage de message binaire."
"Cette spécification est une alternative à la syntaxe de message HTTP/1.1, mais n'est pas obsolète. La sémantique existante de HTTP reste inchangée."
En 2012, la plupart des navigateurs modernes et de nombreux sites populaires (Google, Twitter, Facebook, etc.) prenaient déjà en charge SPDY. Alors que la popularité de SPDY augmentait, le groupe de travail HTTP (HTTP-WG) a commencé à travailler sur la mise à jour de la norme HTTP.
À partir de ce moment, SPDY est devenu la base et la branche expérimentale des nouvelles fonctionnalités de HTTP/2. À l'époque, nous avons examiné comment SPDY peut améliorer la navigation. Depuis lors, la norme version 2 a été rédigée, approuvée et publiée.
De nombreuses fonctionnalités de SPDY ont été intégrées à HTTP/2, et Google a finalement cessé de prendre en charge ce protocole au début de 2016.
La plupart des navigateurs ont finalement cessé de prendre en charge SPDY, et comme il n'y a pas d'alternative, HTTP/2 devient la norme de facto.
Bien que la norme de protocole HTTP/2 ne soit pas strictement rétrocompatible avec HTTP/1, la compatibilité peut être obtenue via la traduction. Un client HTTP/1.1 uniquement ne comprendra pas un serveur HTTP/2 uniquement et vice versa, c'est pourquoi la nouvelle version du protocole est HTTP/2 et non HTTP/1.2.
Cela dit, une partie importante du travail fourni par HTTP-WG consiste à s'assurer que HTTP/1 et HTTP/2 peuvent être traduits dans les deux sens sans aucune perte d'informations.
Tous les nouveaux mécanismes ou fonctionnalités introduits seront également indépendants de la version et rétrocompatibles avec le Web existant.
HTTP/2 n'est pas vraiment quelque chose qu'un utilisateur peut implémenter, mais il y a des choses que nous pouvons faire pour affecter notre vitesse de navigation. Croyez-vous que l'un de ces mythes courants accélère votre vitesse Internet ?
HTTP/2 est livré avec d'excellentes mises à jour de la norme HTTP. Certains des plus importants sont le cadrage binaire, le multiplexage, la hiérarchisation des flux, le contrôle de flux et la poussée du serveur.
Suite à la mise à jour vers HTTP2/, la communication du protocole HTTP est scindée en un échange de trames codées en binaire. Ces trames sont mappées aux messages qui appartiennent à un flux particulier. Les flux sont ensuite multiplexés (tissés ensemble dans un sens) dans une seule connexion TCP.
La nouvelle couche de cadrage binaire introduit une nouvelle terminologie ; Flux, messages et trames.
Cela nous permet d'utiliser une seule connexion TCP, pour ce qui en nécessitait auparavant plusieurs.
HTTP/1.1 garantit qu'une seule réponse peut être fournie à la fois par connexion. Et le navigateur ouvrira des connexions TCP supplémentaires si le client souhaite effectuer plusieurs requêtes parallèles.
HTTP/2 supprime cette limitation de HTTP/1.1 et permet le multiplexage complet des demandes et des réponses. Cela signifie que le client et le serveur peuvent décomposer un message HTTP en trames indépendantes, qui sont ensuite entrelacées et réassemblées à l'autre extrémité.
Dans l'ensemble, il s'agit de l'amélioration la plus importante de HTTP/2, car elle éliminera en partie le besoin de connexions multiples. Cela introduira à son tour de nombreux avantages en termes de performances pour toutes les technologies Web.
Le nombre réduit de connexions signifie moins de poignées de main Transport Layer Security (TLS), une meilleure réutilisation des sessions et une réduction globale des besoins en ressources client et serveur. Cela rend les applications plus rapides, plus simples et moins chères à déployer.
Les sites Web comportant de nombreux éléments externes (images ou scripts) bénéficieront des gains de performances les plus importants grâce au multiplexage HTTP/2.
D'autres améliorations des flux multiplexés sont apportées avec des dépendances de poids et de flux. HTTP/2 nous permet de donner à chaque flux un poids (une valeur comprise entre 1 et 256) et de le rendre explicitement dépendant d'un autre flux.
Cette combinaison de dépendance et de poids conduit à la création d'un arbre de priorisation, qui indique au serveur comment le client préférerait recevoir des réponses.
Le serveur utilisera les informations de l'arbre de hiérarchisation pour contrôler l'allocation du processeur, de la mémoire et d'autres ressources, ainsi que l'allocation de la bande passante pour s'assurer que le client reçoit la livraison optimale des réponses de haute priorité.
Les problèmes de contrôle de flux dans HTTP/2 sont similaires à HTTP/1.1. Cependant, étant donné que les flux HTTP/2 sont multiplexés au sein d'une seule connexion TCP, le fonctionnement du contrôle de flux dans HTTP/1.1 n'est plus efficace.
En bref, le contrôle de flux est nécessaire pour empêcher les flux d'interférer les uns avec les autres et de provoquer un blocage. Cela rend le multiplexage possible. HTTP/2 permet d'utiliser une variété d'algorithmes de contrôle de flux, sans nécessiter de modifications de protocole.
Aucun algorithme de contrôle de flux n'est spécifié dans HTTP/2. Au lieu de cela, un ensemble de blocs de construction a été fourni pour aider les clients et les serveurs à appliquer leur propre contrôle de flux.
Vous pouvez trouver les spécificités de ces blocs de construction dans la section "Contrôle de flux" du brouillon Internet HTTP/2.
Votre navigateur demandera et recevra normalement un document HTML d'un serveur lors de la première visite d'une page. Le serveur doit ensuite attendre que le navigateur analyse le document HTML et envoie une demande pour les éléments intégrés (CSS, JavaScript, images, etc.).
Dans HTTP/1.1, le serveur ne peut pas envoyer ces éléments tant que le navigateur ne les demande pas, et chaque élément nécessite une requête distincte (c'est-à-dire plusieurs poignées de main et connexions).
Le push du serveur réduira la latence en permettant au serveur d'envoyer ces ressources sans invite, car il sait déjà que le client en aura besoin. Ainsi, dans l'exemple ci-dessus, le serveur poussera CSS, JavaScript (un langage de script courant dans les pages Web) et des images vers le navigateur pour afficher la page plus rapidement.
Fondamentalement, le push du serveur permet à un serveur d'envoyer plusieurs réponses pour une seule requête client.
Bien que manuellement, c'est l'effet que nous obtenons actuellement en incorporant CSS ou JS dans nos documents HTML --- nous poussons la ressource en ligne vers le client sans attendre que le client la demande.
Il s'agit d'un grand pas en avant par rapport à la norme HTTP actuelle de flux de travail strict de requête-réponse individuelle.
SPDY avait une politique légèrement plus stricte en matière de sécurité et exigeait un cryptage SSL pour toutes les connexions. HTTPS/2 ne nécessite pas de cryptage, mais de nombreux services ne serviront pas HTTP/2 sans SSL.
Tous les principaux navigateurs prennent en charge HTTP/2, mais aucun d'entre eux ne le prendra en charge sans chiffrement. Le site Web de CanIUs offre un excellent aperçu du tableau sur la prise en charge actuelle du navigateur pour HTTP/2, comme indiqué ci-dessus.
La rétrocompatibilité et les traductions entre HTTP/1.1 et HTTP/2 ralentiront la vitesse de chargement des pages.
Il n'y a aucune raison réelle pour laquelle le chiffrement ne devrait pas être une configuration par défaut ou obligatoire à ce jour. Si vous disposez déjà d'un certificat SSL sur votre site, vous pouvez améliorer la sécurité de votre site Web HTTPS en activant le HSTS.
HTTP/2 a été proposé comme standard à la mi-2015, et la plupart des navigateurs l'ont pris en charge à la fin de cette année. HTTP/2 affecte déjà le fonctionnement d'Internet et la manière dont les applications et les serveurs communiquent.
Il n'y a aucune exigence pour forcer l'utilisation de HTTP/2, mais jusqu'à présent, cela ne présente que des avantages et aucun inconvénient. C'est aussi un changement assez mineur du point de vue de l'utilisateur, que les gens ne remarqueront pas vraiment.
Selon W3Tech, 31,7 % des 10 millions de sites Web les plus importants prennent actuellement en charge HTTP/2. Pour la plupart d'entre vous, le moyen le plus rapide d'activer HTTP/2 sur votre site Web consiste à utiliser le CDN de Cloudflare.
La prochaine norme proposée (HTTP/3) est déjà en préparation et est basée sur QUIC, un autre projet expérimental de Google. En octobre de cette année, le groupe de travail HTTP de l'IETF et le groupe de travail QUIC ont officiellement demandé à QUIC de devenir la nouvelle norme mondiale et de le renommer HTTP/3.
Si vous êtes curieux, Akamai.com dispose d'un outil rapide pour vérifier si votre navigateur prend en charge HTTP/2. Si ce n'est pas le cas, envisagez peut-être de changer de navigateur.
