en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Une introduction à HTTP / 2

Introduction

HTTP / 2 est la dernière révision du Protocole de transfert hypertexte ou HTTP [01], qui est utilisé par les navigateurs pour communiquer avec les serveurs Web. Dérivé de l'ancien SPDY [02] protocole, HTTP / 2 est la première nouvelle version de HTTP depuis la standardisation de HTTP / 1.1 dans RFC 2068 en 1997.

Il a été développé par le groupe de travail HTTP Internet Engineering Task Force (IETF) httpbis (où «bis» signifie «deux fois»), et publié en tant que RFC 7540 [03] en mai 2015.

Adoption HTTP / 2

HTTP / 2 a été de plus en plus adopté par les sites Web en activité depuis sa publication officielle. Le service d'enquête en ligne W3Techs [04] note que de septembre 2017 à septembre 2018, la prise en charge HTTP / 2 est passée de 16% à 30% de tous les sites Web surveillés.

De plus, les principaux navigateurs (par exemple Chrome, Firefox, Edge, etc.) fournissent déjà une prise en charge complète de HTTP / 2 [05]. (Certains ont même développé des implémentations expérimentales avant que HTTP / 2 ne soit accepté comme standard.)

Cette adoption généralisée signifie que HTTP / 2 a le potentiel de devenir le protocole de communication de facto du Web.

Motivation derrière HTTP / 2

Httpbis'charte [06] mentionne plusieurs composants de HTTP / 1.1 qui pourraient être améliorés comme motivation pour HTTP / 2. Cependant, l'objectif principal du groupe était de diminuer la latence perçue par l'utilisateur final.

Pour ce faire, httpbis envisagé de minimiser la surcharge de bande passante via la compression d'en-tête et des techniques agressives de prélecture (par exemple, poussée du serveur), tout en essayant en même temps de résoudre systématiquement les problèmes de performances connus tels que l'encombrement des connexions et le problème de blocage de la tête de ligne [07].

De plus, HTTP / 2 devait être rétrocompatible, ce qui signifiait qu'il devait utiliser les mêmes verbes de méthode, codes d'état, URI et (la plupart) champs d'en-tête trouvés dans HTTP / 1.1. HTTP / 2 devait également être conçu pour prendre en charge les cas d'utilisation HTTP courants, tels que les navigateurs Web de bureau et mobiles, les interfaces de programmation, les proxys et les pare-feu.

Pour maintenir cette compatibilité, le groupe de travail a développé un mécanisme de négociation de protocole qui permettrait aux clients et aux serveurs de choisir parmi les protocoles HTTP / 1.1, HTTP / 2 ou même non HTTP.

Alors, quoi de neuf dans HTTP / 2?

HTTP / 2 utilise toujours les mêmes schémas d'URI et numéros de port que ceux utilisés dans HTTP / 1.1 (c'est-à-dire le port 80 pour http URI et port 443 pour https URI), mais beaucoup de choses se font différemment sous le capot.

Le changement le plus fondamental est l'introduction de cadres comme unité de données de base de HTTP / 2.

HTTP / 1.1 utilise traditionnellement paquets pour représenter les données du réseau. Un client construit un paquet de requête avec un verbe de méthode (par exemple GET or POST), en ajoutant une liste d'en-têtes décrivant la connexion et un corps contenant les données d'application.

Lors de la réception d'un paquet de demande, un serveur HTTP / 1.1 répond avec un paquet de réponse similaire contenant les informations demandées. Par conséquent, chaque cycle de demande et de réponse nécessite une nouvelle connexion.

Inversement, les clients HTTP / 2 établissent une connexion réseau unique avec le serveur, qu'ils utilisent pour toutes les communications réseau ultérieures. Les en-têtes, les données utilisateur, les messages d'erreur et toutes ces informations sont regroupés dans des structures de données binaires distinctes appelées trames, avant d'être transmises sur le réseau.

Cela semble être un petit changement, mais il a des implications importantes.

Compression d'en-tête

Un grand avantage de l'utilisation de trames est que les en-têtes HTTP / 2 sont regroupés dans un HEADER cadre, qui peut être compressé en utilisant des méthodes de compression normales. Les en-têtes doivent être transférés avant toute donnée, de sorte que la compression d'en-tête peut réduire la surcharge de bande passante imposée par HTTP / 2.

La compression d'en-tête, ainsi que les fonctionnalités HTTP améliorant les performances suivantes, peuvent être particulièrement utiles dans les applications mobiles ou Internet des objets (IOT), où une utilisation minimale du réseau est requise.

Flux et multiplexage

Une séquence indépendante de trames sémantiquement pertinentes est appelée courant. Les flux se voient attribuer un identifiant unique par le point d'extrémité (c'est-à-dire le client ou le serveur) qui les a créés, afin que d'autres points d'extrémité puissent les distinguer.

Les points de terminaison peuvent entrelacer des trames de plusieurs flux sur la même connexion HTTP / 2, permettant à une seule connexion réseau de prendre en charge plusieurs flux ouverts simultanément. Ce processus est appelé multiplexage [08].

La réutilisation de la même connexion atténue les problèmes tels que l'encombrement des connexions et le problème HoL mentionné précédemment, et offre de meilleures performances et une expérience utilisateur plus fluide que les versions HTTP précédentes.

Dépendance et hiérarchisation des flux

La gestion de plusieurs flux simultanés signifie que certains flux seront traités avant d'autres. HTTP / 2 permet au développeur (ou administrateur) d'affiner ce comportement avec une fonctionnalité appelée dépendance de flux.

Un flux peut dépendre du transfert complet d'un autre flux avant d'être traité. Par exemple, sur un site où le contenu principal d'une page Web doit être chargé avant toute recommandation de contenu similaire, HTTP / 2 permet de créer le flux de recommandations en fonction du flux de contenu principal.

HTTP / 2 prend également en charge priorisation des flux. Autrement dit, chaque flux peut se voir attribuer une priorité pour suggérer l'urgence avec laquelle les points d'extrémité doivent allouer des ressources pour gérer les trames du flux.

La hiérarchisation et la dépendance au flux aident les développeurs et les propriétaires de sites Web à optimiser l'utilisation du réseau de leur site, ce qui peut considérablement améliorer l'expérience utilisateur de leur site.

Serveur Push

Enfin, HTTP / 2 peut améliorer les performances d'un site Web en fournissant une fonctionnalité «push». Un serveur Web HTTP / 2 peut répondre avec des données pour plus de requêtes que ce que le client a demandé à l'origine. Cela permet au serveur de fournir des données dont il sait qu'un navigateur Web aura besoin pour afficher une page, sans attendre que le navigateur examine la première réponse, et donc sans la surcharge d'un cycle de demande supplémentaire.

La poussée du serveur donne aux développeurs un contrôle complet sur le nombre de requêtes requises pour qu'un navigateur affiche leur site Web. Lorsqu'elle est utilisée correctement, cette fonction peut réduire la surcharge du réseau.

Naturellement, une mauvaise utilisation de la fonction push peut également gaspiller plus de bande passante qu'il n'est réellement nécessaire. Pour cette raison, HTTP / 2 permet à un client de demander que la poussée du serveur soit désactivée lors de la première négociation d'une connexion.

Sécurité HTTP / 2

Si vous avez lu jusqu'à présent, il devrait être clair que les développeurs de HTTP / 2 se sont vraiment efforcés d'améliorer les performances. Cependant, il convient de noter que HTTP / 2 peut également aider à améliorer la sécurité globale des utilisateurs du navigateur.

Plus précisément, HTTP / 2 est défini à la fois pour les URI HTTP (c'est-à-dire sans chiffrement) et les URI HTTPS (sur TLS chaînes cryptées). Bien que la norme elle-même ne nécessite pas l'utilisation du cryptage, toutes les principales implémentations de navigateur (par exemple Firefox [09], Chrome, Safari, Opera, IE, Edge) ont décidé de uniquement. supporte HTTP / 2 sur TLS.

En fait, les navigateurs font la distinction entre HTTP / 2 en texte clair et HTTP / 2 sur crypté TLS comme deux protocoles différents. HTTP / 2 chiffré est appelé h2 et en texte clair h2c. Au moment d'écrire ces lignes, aucun des principaux navigateurs ne prend en charge h2c , Ce qui signifie que TLS le chiffrement est obligatoire pour qu'un site Web puisse profiter des autres avantages de HTTP / 2. Par conséquent, lorsque HTTP / 2 devient le protocole de réseau Web par défaut, les propriétaires de sites Web hérités qui n'ont pas encore mis à niveau vers SSL /TLS, sera fortement motivé pour finalement le faire.

Conclusion

L'adoption généralisée de HTTP / 2 entraînera un Web nouveau et amélioré. Il est plus rapide, nécessite moins de bande passante et aide les sites Web à rester sécurisés. Son adoption généralisée rendra l'expérience utilisateur Web plus fluide et plus sûre.

Obtenez un certificat aujourd'hui et rejoignez-nous à l'avenir.

Références

  1. Protocole HTTP
  2. Protocole SPDY
  3. Spécification HTTP / 2
  4. Enquête d'adoption HTTP / 3 de W2Techs
  5. Adoption HTTP / 2 dans les navigateurs
  6. Charte httpbis
  7. Blocage HOL
  8. Multiplexage
  9. Firefox sur HTTP / 2

Articles Relatifs

Abonnez-vous à la newsletter SSL.com

Qu'est-ce que SSL /TLS?

Regardez la video

Abonnez-vous à la newsletter SSL.com

Ne manquez pas les nouveaux articles et mises à jour de SSL.com