HTTP a été proposé à l’origine par Tim Berners-Lee, le pionnier du World Wide Web qui a conçu le protocole d’application avec la simplicité à l’esprit pour exécuter des fonctions de communication de données de haut niveau entre serveurs Web et clients.

La première version documentée de HTTP a été publiée en 1991 en tant que HTTP0.9, ce qui a conduit plus tard à l’introduction officielle et à la reconnaissance de HTTP1.0 en 1996. HTTP1.1 a suivi en 1997 et a depuis reçu peu d’améliorations itératives.

Au fil des années les sites web sont devenus de plus en plus sophistiqués : ils peuvent contenir des images et des vidéos lourdes, du code Javascript ou encore des feuilles de style (CSS). Parallèlement aux changements des contenus, le comportement des internautes a aussi évolué. En navigant sur Internet nous nous attendons à une certaine vitesse de chargement : ainsi, si un site web prend plus de quelques secondes à s’afficher, nous finissons souvent par abandonner et quitter la page.

Pour toutes ces raisons nous avons besoin d’un protocole adapté à la réalité actuelle. HTTP/2 relève ce défi.

Le débat HTTP/2 vs HTTP1 doit être précédé d’une brève introduction au terme Protocole fréquemment utilisé dans cette ressource. Un protocole est un ensemble de règles qui régissent les mécanismes de communication de données entre les clients (par exemple les navigateurs Web utilisés par les internautes pour demander des informations) et les serveurs (les machines contenant les informations demandées).

Les protocoles se composent généralement de trois parties principales : l’en-tête, la charge utile et le pied de page. L’en-tête placé avant la charge utile contient des informations telles que les adresses source et destination ainsi que d’autres détails (tels que la taille et le type) concernant la charge utile. La charge utile est l’information réelle transmise à l’aide du protocole. Le pied de page suit la charge utile et sert de champ de contrôle pour acheminer les demandes client-serveur aux destinataires prévus avec l’en-tête afin de s’assurer que les données utiles sont transmises sans erreur.

Le système est similaire à celui du service postal. La lettre (charge utile) est insérée dans une enveloppe (en-tête) portant l’adresse de destination et scellée avec de la colle et un timbre-poste (pied de page) avant son expédition. Sauf que la transmission de l’information numérique sous forme de 0 et de 1 n’est pas aussi simple et nécessite une innovation de nouvelle dimension en réponse aux progrès technologiques de plus en plus importants qui émergent avec la croissance explosive de l’utilisation d’Internet.

Le protocole HTTP composé à l’origine de commandes de base : GET, pour récupérer les informations du serveur et POST, pour fournir les informations demandées au client. Cet ensemble simple et apparemment ennuyeux de quelques commandes pour obtenir des données GET et POST une réponse a essentiellement formé la base pour construire d’autres protocoles réseau également. Le protocole est une nouvelle étape dans l’amélioration de l’expérience et de l’efficacité des utilisateurs d’Internet, ce qui nécessite l’implémentation de HTTP/2 pour améliorer la présence en ligne.

Depuis sa création au début des années 1990, HTTP n’a connu que quelques révisions majeures. La version la plus récente, HTTP1.1, a servi le cybermonde pendant plus de 15 ans. À l’ère actuelle de la mise à jour dynamique de l’information, des formats de contenu multimédia gourmands en ressources et de la tendance excessive à la performance sur le Web, les anciennes technologies de protocole font maintenant partie de l’histoire ancienne. Ces tendances nécessitent d’importants changements HTTP/2 pour améliorer l’expérience Internet.

L’objectif principal de la recherche et du développement d’une nouvelle version de HTTP s’articule autour de trois qualités rarement associées à un seul protocole réseau sans nécessiter de technologies réseau supplémentaires – simplicité, haute performance et robustesse. Ces objectifs sont atteints grâce à l’introduction de capacités qui réduisent la latence dans le traitement des requêtes du navigateur grâce à des techniques telles que le multiplexage, la compression, la hiérarchisation des requêtes et la poussée du serveur.

Des mécanismes tels que le contrôle du flux, la mise à niveau et le traitement des erreurs fonctionnent en tant qu’améliorations du protocole HTTP pour les développeurs afin d’assurer la haute performance et la résilience des applications Web.

Le système collectif permet aux serveurs de répondre efficacement avec plus de contenu qu’initialement demandé par les clients, éliminant l’intervention de l’utilisateur pour demander continuellement des informations jusqu’à ce que le site soit entièrement chargé sur le navigateur. Par exemple, la fonction Server Push avec HTTP/2 permet aux serveurs de répondre avec le contenu complet d’une page autre que les informations déjà disponibles dans le cache du navigateur. La compression efficace des fichiers d’en-tête HTTP minimise le protocole pour améliorer les performances à chaque requête de navigateur et réponse du serveur.

Les modifications HTTP/2 sont conçues pour maintenir l’interopérabilité et la compatibilité avec HTTP1.1. On s’attend à ce que les avantages de HTTP/2 augmentent avec le temps grâce à des expériences en situation réelle, et sa capacité à résoudre les problèmes de performance en comparaison avec HTTP1.1 dans le monde réel aura un impact considérable sur son évolution sur le long terme.

Il est important de noter que la nouvelle version de HTTP est une extension de son prédécesseur et ne devrait pas remplacer HTTP1.1 de sitôt. L’implémentation de HTTP/2 n’activera pas la prise en charge automatique de tous les types de cryptage disponibles avec HTTP1.1, mais ouvrira certainement la porte à de meilleures alternatives ou à des mises à jour supplémentaires de compatibilité de cryptage dans un avenir proche. Cependant, les comparaisons de fonctionnalités telles que HTTP/2 vs HTTP1 et SPDY vs HTTP/2 présentent le dernier protocole d’application comme gagnant en termes de performances, de sécurité et de fiabilité.

HTTP1.1 se limitait au traitement d’une seule requête en suspens par connexion TCP, forçant les navigateurs à utiliser plusieurs connexions TCP pour traiter plusieurs requêtes simultanément.

Cependant, l’utilisation d’un trop grand nombre de connexions TCP en parallèle entraîne une congestion TCP qui entraîne une monopolisation injuste des ressources réseau. Les navigateurs Web qui utilisent plusieurs connexions pour traiter des requêtes supplémentaires occupent une plus grande part des ressources réseau disponibles, ce qui réduit les performances du réseau pour les autres utilisateurs.

L’émission de demandes multiples à partir du navigateur entraîne également la duplication des données sur les fils de transmission de données, ce qui nécessite à son tour des protocoles supplémentaires pour extraire les informations souhaitées sans erreurs au niveau des nœuds finaux.

L’industrie de l’Internet a naturellement été forcée de hacker ces contraintes avec des pratiques telles que le domain sharding, la concaténation, l’enchaînement de données et le sprinting, parmi d’autres. L’utilisation inefficace des connexions TCP sous-jacentes avec HTTP1.1 conduit également à une mauvaise priorisation des ressources, entraînant une dégradation exponentielle des performances à mesure que la complexité, la fonctionnalité et la portée des applications Web augmentent.

Le Web a évolué bien au-delà de la capacité des anciennes technologies de réseautage HTTP. Les qualités fondamentales de HTTP1.1 développées il y a plus d’une décennie ont ouvert la porte à plusieurs failles embarrassantes de sécurité et de performance.

Le Cookie Hack, par exemple, permet aux cybercriminels de réutiliser une session de travail précédente pour compromettre les mots de passe des comptes car HTTP1.1 ne permet pas d’identifier les points de terminaison de session. Tandis que les mêmes préoccupations de sécurité continueront d’obséder HTTP/2, le nouveau protocole d’application est conçu avec de meilleures capacités de sécurité telles que l’implémentation améliorée de nouvelles fonctionnalités TLS.

Les séquences bidirectionnelles de trames de format texte envoyées via le protocole HTTP/2 échangées entre le serveur et le client sont appelées « flux ». Les itérations précédentes du protocole HTTP ne permettaient de transmettre qu’un seul flux à la fois avec un certain délai entre chaque transmission de flux.

Recevoir des tonnes de contenu multimédia via des flux individuels envoyés un par un est à la fois inefficace et consommateur de ressources. Les changements HTTP/2 ont permis d’établir une nouvelle couche de trames binaires pour répondre à ces préoccupations.

Cette couche permet au client et au serveur de désagréger la charge utile HTTP en petites séquences de trames entrelacées indépendantes et gérables. Ces informations sont ensuite rassemblées à l’autre extrémité.

Les formats de trames binaires permettent l’échange de plusieurs séquences bidirectionnelles indépendantes, ouvertes simultanément, sans latence entre les flux successifs. Cette approche présente une série d’avantages de HTTP/2 expliqués ci-dessous :

• Les demandes et les réponses parallèles multiplexées ne se bloquent pas l’une l’autre.
• Une seule connexion TCP est utilisée pour assurer une utilisation efficace des ressources réseau malgré la transmission de plusieurs flux de données.
• Pas besoin d’appliquer des hacks d’optimisation inutiles – tels que les sprites d’images, la concaténation et le domain sharding, entre autres – qui compromettent d’autres domaines de performance du réseau.
• Temps de latence réduit, performances web plus rapides, meilleur classement dans les moteurs de recherche.
• Réduction des coûts d’exploitation et d’investissement des ressources réseau et informatiques.

Avec cette capacité, les paquets de données provenant de plusieurs flux sont essentiellement mélangés et transmis via une seule connexion TCP. Ces paquets sont ensuite divisés à l’extrémité réceptrice et présentés sous forme de flux de données individuels. La transmission simultanée de plusieurs requêtes parallèles à l’aide de la version HTTP 1.1 ou d’une version antérieure nécessitait plusieurs connexions TCP, ce qui, par nature, entrave les performances globales du réseau malgré la transmission de flux de données plus importants à des vitesses plus élevées.

Cette capacité permet au serveur d’envoyer au client des informations supplémentaires pouvant être mises en cache qui ne sont pas demandées mais qui sont prévues dans les demandes futures. Par exemple, si le client demande la ressource X et qu’il est entendu que la ressource Y est référencée avec le fichier demandé, le serveur peut choisir de pousser Y avec X au lieu d’attendre une requête client appropriée.

Le client place la ressource Y poussée dans son cache pour une utilisation ultérieure. Ce mécanisme permet d’éviter un aller-retour entre la requête et la réponse et réduit la latence du réseau. Server Push a été initialement introduit dans le protocole SPDY de Google. Les identificateurs de flux contenant des pseudo-en-têtes tels que :path permettent au serveur d’initier le Push pour des informations qui doivent être cachables. Le client doit explicitement autoriser le serveur à mettre en cache les ressources avec HTTP/2 ou à terminer les flux poussés avec un identifiant de flux spécifique.

D’autres changements HTTP/2 tels que Server Push mettent à jour ou invalident de manière proactive le cache du client et est également connu comme « Cache Push ». Les conséquences à long terme sont centrées sur la capacité des serveurs à identifier les ressources que le client ne veut pas réellement.

L’implémentation HTTP/2 présente des performances significatives pour des ressources poussées, avec d’autres avantages de HTTP/2 expliqués ci-dessous :

• Le client économise les ressources poussées dans le cache.
• Le client peut réutiliser ces ressources mises en cache sur différentes pages.
• Le serveur peut multiplexer les ressources poussées avec les informations demandées à l’origine dans la même connexion TCP.
• Le serveur peut prioriser les ressources poussées – un différentiateur de performance clé dans HTTP/2 vs HTTP1.
• Le client peut refuser les ressources poussées pour maintenir un référentiel efficace des ressources mises en cache ou désactiver complètement Server Push.
• Le client peut également limiter le nombre de flux poussés multiplexés simultanément.

Des capacités de Push similaires sont déjà disponibles avec des techniques sous-optimales telles que Inlining to Push server responses, tandis que Server Push présente une solution au niveau du protocole pour éviter les complexités avec des hacks d’optimisation secondaires aux capacités de base du protocole de l’application elle-même.

Le HTTP/2 multiplexe et priorise le flux de données poussé pour assurer de meilleures performances de transmission comme c’est le cas avec d’autres flux de données en réponse à une requête. En tant que mécanisme de sécurité intégré, le serveur doit être autorisé à pousser les ressources au préalable.

La dernière version HTTP a considérablement évolué en termes de capacités et d’attributs, comme le passage d’un protocole texte à un protocole binaire. HTTP1.x est utilisé pour traiter les commandes texte afin de compléter les cycles requête-réponse. HTTP/2 utilisera des commandes binaires (en 1s et 0s) pour exécuter les mêmes tâches. Cet attribut facilite les complications liées au framing et simplifie la mise en œuvre des commandes qui ont été mélangées de façon confuse en raison de commandes contenant du texte et des espaces facultatifs.

Bien qu’il faille probablement plus d’efforts pour lire les commandes binaires que les commandes texte comparées, il est plus facile pour le réseau de générer et d’analyser les trames disponibles en binaire. La sémantique reste inchangée.

Les navigateurs utilisant l’implémentation HTTP/2 convertiront les mêmes commandes texte en binaire avant de les transmettre sur le réseau. La couche de framing binaire n’est pas rétrocompatible avec les clients et serveurs HTTP1.x et constitue un facteur clé de performance par rapport à SPDY et HTTP1.x. L’utilisation de commandes binaires permet aux entreprises Internet et aux entreprises en ligne de bénéficier d’avantages commerciaux clés, comme expliqué plus bas avec les avantages HTTP/2 :

• Faible surcharge dans l’analyse des données – une proposition de valeur critique dans HTTP/2 vs HTTP1.
• Moins sujet aux erreurs.
• Réduction de l’encombrement du réseau.
• Utilisation efficace des ressources du réseau.
• Éliminer les problèmes de sécurité associés à la nature textuelle de HTTP1.x tels que les attaques par fractionnement de réponse.
• Permet d’autres fonctionnalités du HTTP/2, notamment la compression, le multiplexage, la hiérarchisation, le contrôle du flux et le traitement efficace du TLS.
• Représentation compacte des commandes pour faciliter le traitement et la mise en œuvre.
• Efficace et robuste en termes de traitement des données entre le client et le serveur.
• Réduction de la latence du réseau et amélioration du débit.

L’implémentation HTTP/2 permet au client de donner la préférence à des flux de données particuliers. Bien que le serveur ne soit pas tenu de suivre ces instructions du client, le mécanisme permet au serveur d’optimiser l’allocation des ressources réseau en fonction des besoins de l’utilisateur final.

La priorisation des flux fonctionne en fonction des dépendances et du poids attribué à chaque flux. Bien que tous les flux soient intrinsèquement dépendants les uns des autres, à l’exception des flux dépendants, on leur attribue également une pondération entre 1 et 256. Les détails des mécanismes de priorisation des flux font encore l’objet de débats.

Dans le monde réel cependant, le serveur a rarement le contrôle sur les ressources telles que le CPU et les connexions de base de données. La complexité de la mise en œuvre elle-même empêche les serveurs de répondre aux requêtes de priorité de flux. La recherche et le développement dans ce domaine sont particulièrement importants pour le succès à long terme de HTTP/2 car le protocole est capable de traiter plusieurs flux de données avec une seule connexion TCP.

Cette capacité peut conduire à l’arrivée simultanée de requêtes serveur qui diffèrent en fait en termes de priorité du point de vue de l’utilisateur final. Le fait de retarder les requêtes de traitement de flux de données sur une base aléatoire nuit à l’efficacité et à l’expérience de l’utilisateur final promises par les changements HTTP/2. En même temps, un mécanisme intelligent et largement adopté de priorisation des flux présente les avantages de HTTP/2 expliqués comme suit :

• Utilisation efficace des ressources du réseau.
• Réduction du temps de livraison des requêtes de contenu primaire.
• Amélioration de la vitesse de chargement des pages et de l’expérience de l’utilisateur final.
• Optimisation de la communication de données entre le client et le serveur.
• Réduction de l’effet négatif des problèmes de latence du réseau.

Offrir une expérience utilisateur haut de gamme exige des sites riches en contenu et en graphismes. Le protocole d’application HTTP est sans état, ce qui signifie que chaque requête client doit inclure autant d’informations dont le serveur a besoin pour effectuer l’opération souhaitée. Ce mécanisme fait en sorte que les flux de données transportent de multiples trames répétitives d’information de sorte que le serveur lui-même n’a pas à stocker l’information provenant des demandes précédentes des clients.

Dans le cas de sites proposant du contenu riche en médias, les clients poussent de multiples en-têtes d’images presque identiques, ce qui entraîne une latence et une consommation inutile de ressources réseau limitées. Une combinaison priorisée de flux de données ne peut atteindre les normes de performance souhaitées en matière de parallélisme sans optimiser ce mécanisme.

L’implémentation de HTTP/2 répond à ces préoccupations avec la possibilité de compresser un grand nombre de trames d’en-tête redondantes. Il utilise la spécification HPACK comme une approche simple et sécurisée de la compression d’en-tête. Le client et le serveur maintiennent une liste des en-têtes utilisés dans les requêtes client-serveur précédentes.

HPACK compresse la valeur individuelle de chaque en-tête avant qu’elle ne soit transférée au serveur, qui recherche ensuite les informations codées dans la liste des valeurs d’en-tête précédemment transférées pour reconstruire les informations complètes de l’en-tête. La compression d’en-tête HPACK pour l’implémentation HTTP/2 présente d’immenses avantages en termes de performances, y compris certains avantages de HTTP/2 expliqués ci-dessous :

• Priorisation efficace de flux.
• Utilisation efficace des mécanismes de multiplexage.
• Réduction des ressources – l’un des premiers sujets de préoccupation dans les débats sur HTTP/2 vs HTTP1 et HTTP/2 vs SPDY.
• Encode les gros en-têtes ainsi que les en-têtes couramment utilisés, ce qui élimine le besoin d’envoyer la trame d’en-tête complète elle-même. La taille de transfert individuelle de chaque flux de données se réduit rapidement.
• Non vulnérable aux attaques de sécurité telles que CRIME qui exploite les flux de données avec des en-têtes compressés.

HTTPS est utilisé pour établir un réseau ultra-sécurisé reliant les ordinateurs, les machines et les serveurs afin de traiter les informations sensibles des entreprises et des consommateurs. Les banques qui traitent les transactions financières et les établissements de santé qui conservent les dossiers des patients sont les principales cibles des infractions cybercriminelles. HTTPS fonctionne comme une couche efficace contre les menaces persistantes de cybercriminalité, bien que ce ne soit pas le seul déploiement de sécurité utilisé pour repousser les cyberattaques sophistiquées contre les réseaux d’entreprise de grande valeur.

La prise en charge HTTP/2 du navigateur inclut le cryptage HTTPS et complète en fait les performances de sécurité globales des déploiements HTTPS. Des caractéristiques telles que la réduction des poignées de main (handshake) TLS, la faible consommation de ressources côté client et côté serveur et l’amélioration des capacités de réutilisation des sessions Web existantes tout en éliminant les vulnérabilités associées à HTTP1.x font du HTTP/2 un outil clé pour sécuriser les communications numériques dans les environnements réseau sensibles.

HTTPS n’est pas limité aux organisations de haut niveau et la cybersécurité est tout aussi précieuse pour les propriétaires d’entreprises en ligne, les blogueurs occasionnels, les marchands en ligne et même les utilisateurs de réseaux sociaux. Le HTTP/2 nécessite la version TLS la plus récente et la plus sécurisée et toutes les communautés en ligne, les propriétaires d’entreprises et les webmasters doivent s’assurer que leurs sites utilisent HTTPS par défaut.

Les processus habituels de mise en place de HTTPS incluent l’utilisation de plans d’hébergement Web, l’achat, l’activation et l’installation d’un certificat de sécurité et enfin la mise à jour du site pour utiliser HTTPS.

L’industrie de l’Internet a dû remplacer le HTTP1.x vieillissant par une alternative prometteuse pour l’utilisateur moyen. Du point de vue des entreprises en ligne et des consommateurs sur Internet, le Web devient de plus en plus lent à mesure qu’il est rempli de volumes croissants de contenu riche en médias non pertinents. pour que les entreprises en ligne atteignent efficacement leur marché cible et pour que les internautes puissent accéder plus rapidement à un meilleur contenu, des changements HTTP/2 sont mis au point pour améliorer l’efficacité des communications entre clients et serveurs de données. Et en plus de cela, le web est plus situationnel que jamais.

La vitesse Internet n’est pas la même sur tous les réseaux et dans tous les lieux géographiques. La base d’utilisateurs de plus en plus mobile exige un Internet haute performance transparent et performant pour tous les appareils, même si les réseaux cellulaires encombrés ne peuvent concurrencer l’Internet haut débit. Une mise en réseau et un mécanisme de communication de données entièrement remaniés et remaniés sous la forme HTTP/2 se sont révélés être une solution viable présentant les avantages significatifs suivants.

Le terme résume tous les avantages des modifications HTTP/2. Les résultats du benchmark HTTP/2 (voir le chapitre : Comparaison des performances de HTTPS, SPDY et HTTP/2) montrent les améliorations des performances de HTTP/2 par rapport à ses prédécesseurs et alternatives.

La capacité du protocole à envoyer et recevoir plus de données par cycle de communication client-serveur n’est pas un hack d’optimisation mais un avantage HTTP/2 réel, réalisable et pratique en termes de performance. L’analogie est similaire à l’idée des trains à tubes sous vide (Vactrain) par rapport au chemin de fer standard : l’élimination de la résistance à l’air des tunnels Vactrain permet au véhicule de voyager plus vite et de transporter plus de passagers en utilisant mieux les canaux disponibles sans avoir à se concentrer sur l’installation de moteurs plus gros, réduire son poids et rendre le véhicule plus aérodynamique.

Des technologies telles que le multiplexage créent de l’espace supplémentaire pour transporter et transmettre plus de données simultanément – comme les compartiments de sièges à plusieurs étages dans l’avion d’Airbus.

Et que se passe-t-il lorsque le mécanisme de communication de données élimine tous les obstacles à l’amélioration des performances ? Le sous-produit de la performance supérieure de site inclut la satisfaction accrue de client, l’optimisation meilleure des moteurs de recherche, la productivité élevée et l’utilisation de ressource, l’augmentation de base d’utilisateur, de meilleurs chiffres de ventes et beaucoup plus.

Heureusement, l’adoption du HTTP/2 est beaucoup plus pratique que la création de chambres sous vide pour les grandes locomotives à plusieurs étages.

Les avantages de HTTP/2 vont au-delà de la performance puisque l’algorithme HPACK permet à HTTP/2 de contourner les menaces de sécurité courantes ciblant les protocoles de couche d’application texte. HTTP/2 contient des commandes en binaire et permet la compression des métadonnées d’en-tête HTTP en suivant une approche « Security by Obscurity » pour protéger les données sensibles transmises entre clients et serveurs. Le protocole prend également en charge le cryptage et nécessite une version améliorée de Transport Layer Security (TLS1.2) pour une meilleure protection des données.