Explication de http2. Utilisation plus efficace du réseau. Bloquer le début de la file d'attente

Nous avons implémenté le support HTTP/2 sur les nouveaux serveurs.HTTP est un protocole, qui régit les communications entre votre serveur et les navigateurs des visiteurs de votre site.HTTP/2 est la première mise à jour du protocole depuis 1999. Et cela nous promet que les sites Web deviendront beaucoup plus rapides pour tout le monde.À quel point le protocole HTTP/2 est-il plus rapide que HTTP/1.1, vous pouvez le voir

Quelles sont les capacités du nouveau protocole ?

HTTP/2 offre des capacités et des avantages supérieurs à ceux de la version précédente.L'essentiel est que les sites se chargent beaucoup plus rapidement.Ceci est réalisé grâce à un certain nombre d’innovations :

Multiplexage

Grâce au multiplexage dans le protocole HTTP/2, toutes les données sont transmises via une seule connexion TCP.Alors qu'en HTTP/1.1, pour recevoir chaque élément qui compose une page Web, vous devez créer une connexion distincte. Étant donné qu’il ne pouvait y avoir qu’environ 6 connexions de ce type à la fois, cela ralentissait considérablement le chargement des pages.

Le multiplexage permet au navigateur d'effectuer plusieurs requêtes au sein d'une seule connexion TCP

Priorité

Pendant le développement HTTP/2 a également pris en compte la nécessité de fournir une vitesse de chargement visuelle des pages à l'utilisateur. Attribuez une priorité de chargement à chaque thread.Par exemple, si votre page Web est assez longue, vous souhaiterez peut-être d'abord charger le contenu en haut de la page.

Compression d'en-tête

Une page Web moderne se compose de nombreux éléments : images, JS, CSS et autres. Le navigateur envoie un en-tête HTTP dans la requête pour télécharger chacun de ces éléments. Lors de l'envoi des éléments demandés, le serveur leur ajoute également un en-tête. Ainsi, le canal réseau est également utilisé pour transmettre une grande quantité d’informations de service.

En HTTP/2, les en-têtes sont transmis sous forme compressée. Cela réduit la quantité d'informations échangées entre le serveur et le navigateur. Un algorithme HPACK spécial a été développé pour éliminer les vulnérabilités connues permettant d'intercepter des informations.

Poussée du serveur

Il s'agit d'une autre fonctionnalité puissante du protocole HTTP/2. Désormais, le serveur, en réponse à la demande, peut envoyer des éléments supplémentaires dont le navigateur aura besoin. Par exemple, désormais, lors de la demande d'une page, le serveur peut, en plus de la page elle-même, envoyer immédiatement les fichiers JavaScript et CSS nécessaires à son affichage.

SSL et cryptage

Les développeurs du protocole HTTP/2 ne l'ont fondamentalement implémenté que pour des connexions sécurisées. Ainsi, si vous souhaitez passer au protocole HTTP/2, vous aurez besoin d’un certificat SSL commercial.

Si vous souhaitez tester les capacités du nouveau protocole, nous proposons test pendant un mois. De plus, lors de la commande de nouveaux tarifs Pro, nous fournissons pour une durée d'un an.

Tous nos autres clients ont la possibilité d'acheter jusqu'à fin mars 2016

Comment passer à HTTP/2 ?

Nous pensons que la transition vers le protocole HTTP/2 accélérera considérablement le chargement des sites Web pour la plupart de nos clients, et réduira également considérablement la charge sur les serveurs.

Si vous souhaitez que votre site fonctionne avec le protocole HTTP/2, faites-le-nous savoir àet nous le déplacerons vers un serveur prenant en charge HTTP/2.

« …nous ne modifions pas toutes les méthodes HTTP, les codes d'état et la plupart des en-têtes restent les mêmes. Nous venons de le repenser dans une optique d'augmentation de l'efficacité d'utilisation, pour qu'il soit plus doux par rapport à Internet..."

Il est important de noter que la nouvelle version de HTTP est une extension de son prédécesseur et qu’il est peu probable qu’elle remplace HTTP 1.1 dans un avenir proche. L'implémentation de HTTP/2 ne prend pas automatiquement en charge tous les types de chiffrement disponibles dans HTTP 1.1, mais elle encourage certainement l'utilisation d'alternatives plus intéressantes, ou des mises à jour supplémentaires de compatibilité de chiffrement dans un avenir proche. Cependant, dans les comparaisons « HTTP/2 vs HTTP 1 » et « SPDY vs HTTP/2 », le héros de cet article sort vainqueur en termes de performances, de sécurité et de fiabilité.

Quel était le problème avec HTTP 1.1 ?

HTTP 1.1 ne permet de traiter qu'une seule requête entrante par connexion TCP, le navigateur doit donc établir plusieurs connexions pour traiter plusieurs requêtes simultanément.

Mais l’utilisation parallèle de plusieurs connexions conduit à une congestion TCP, d’où une monopolisation injuste des ressources réseau. Les navigateurs utilisant plusieurs connexions pour gérer des requêtes supplémentaires occupent la part du lion des ressources réseau disponibles, ce qui entraîne de mauvaises performances réseau pour les autres utilisateurs.

Les navigateurs envoyant de nombreuses requêtes entraînent une duplication des données dans les réseaux de transmission, ce qui, à son tour, nécessite l'utilisation de protocoles supplémentaires permettant de récupérer avec précision les informations requises aux nœuds finaux.

L'industrie des réseaux a en fait dû contourner ces limitations en utilisant des techniques telles que le partage de domaine, la concaténation, l'intégration de données et le spriting, ainsi que plusieurs autres. L'utilisation inefficace par HTTP 1.1 des connexions TCP sous-jacentes entraîne une mauvaise hiérarchisation des ressources, ce qui entraîne une dégradation exponentielle des performances à mesure que les applications Web gagnent en complexité, en fonctionnalités et en taille.

Le réseau en développement ne manque plus des capacités des technologies HTTP. Développées il y a de nombreuses années, les fonctionnalités clés de HTTP 1.1 permettent plusieurs failles désagréables qui dégradent la sécurité et les performances des sites Web et des applications.

Par exemple, avec Cookie Hack, les attaquants peuvent réutiliser une session de travail précédente pour obtenir un accès non autorisé au mot de passe d'un utilisateur. La raison est que HTTP 1.1 ne fournit pas d'outils d'authentification de bout en bout. Réalisant que des failles similaires seraient recherchées dans HTTP/2, ses développeurs ont tenté d'améliorer la sécurité du protocole grâce à une meilleure implémentation de nouvelles fonctionnalités TLS.

Fonctionnalités de HTTP/2

Flux multiplexés

Une séquence de blocs de texte échangés entre le client et le serveur via HTTP/2 est appelée « flux ». Dans les premières versions de HTTP, vous ne pouviez diffuser qu'un seul flux à la fois, avec un léger délai entre les différents flux. Il était trop inefficace et trop gourmand en ressources pour transmettre de grands volumes de contenu médiatique de cette manière. Pour résoudre ce problème, HTTP/2 utilise une nouvelle couche de trames binaires.

Cette couche vous permet de transformer les données transférées du serveur vers le client en une séquence gérable de petites trames indépendantes. Et dès réception de l'ensemble des trames, le client peut restaurer les données transmises dans leur forme originale. Ce schéma fonctionne également lors de la transmission dans la direction opposée - du client au serveur.

Les formats de trames binaires permettent l'échange simultané de plusieurs séquences indépendantes transmises dans les deux sens, sans aucun délai entre les flux. Cette approche offre de nombreux avantages :

• Les demandes et réponses multiplexées en parallèle ne se bloquent pas.
• Malgré la transmission de plusieurs flux de données, une seule connexion TCP est utilisée pour optimiser l'utilisation des ressources du réseau.
• Fini les hacks d'optimisation comme les sprites, la concaténation, la fragmentation de domaine et autres qui ont un impact négatif sur d'autres domaines des performances du réseau.
• Les latences sont plus faibles, les performances du réseau sont plus élevées et les classements sont meilleurs dans les moteurs de recherche.
• Les ressources réseau et informatiques réduisent les coûts d’exploitation et les investissements en capital.

Grâce à la fonctionnalité décrite, les paquets de données provenant de différents flux sont mélangés via une seule connexion TCP. Au point final, ces paquets sont ensuite séparés et présentés sous forme de flux de données distincts. Dans HTTP 1.1 et versions antérieures, le même nombre de connexions TCP devrait être établi pour transmettre plusieurs requêtes en parallèle, ce qui constitue un goulot d'étranglement en termes de performances globales du réseau, malgré le fait qu'un plus grand nombre de flux de données peuvent être transmis rapidement.

Envoi de données initié par le serveur (Server Push)

Cette fonctionnalité permet au serveur d'envoyer au client des informations supplémentaires mises en cache que le client n'a pas demandées mais qui pourraient être nécessaires dans des demandes futures. Par exemple, si un client demande la ressource X, qui fait référence à la ressource Y, le serveur peut envoyer Y avec X sans attendre une demande supplémentaire du client.

La ressource Y reçue du serveur est mise en cache sur le client pour une utilisation ultérieure. Ce mécanisme enregistre les cycles requête-réponse et réduit la latence du réseau. Server Push est apparu à l'origine dans le protocole SPDY. Les ID de thread contenant des pseudo-en-têtes tels que : path amènent le serveur à envoyer des informations supplémentaires qui doivent être mises en cache. Le client doit soit autoriser explicitement le serveur à se servir des ressources mises en cache via HTTP/2, soit abandonner les threads lancés qui ont un identifiant spécial.

Une autre fonctionnalité HTTP/2, connue sous le nom de Cache Push, vous permet de mettre à jour ou d'invalider de manière proactive le cache sur le client. Dans ce cas, le serveur est capable de déterminer les ressources dont le client peut avoir besoin et qu'il n'a pas réellement demandées.

L'implémentation HTTP/2 démontre des performances élevées lorsque vous travaillez avec des ressources transférées de manière proactive :

• Les ressources initiées sont stockées dans le cache du client.
• Le client peut réutiliser ces ressources sur différentes pages.
• Le serveur peut multiplexer les ressources transmises de manière proactive ainsi que les informations demandées au sein de la même connexion TCP.
• Le serveur peut prioriser les ressources transférées de manière proactive. C'est la principale différence en termes de performances entre HTTP/2 et HTTP 1.
• Le client peut rejeter les ressources poussées de manière proactive pour maintenir l'efficacité du référentiel, ou peut désactiver complètement Server Push.
• Le client peut également limiter le nombre de flux de données multiplexés simultanément et transmis de manière proactive.

Des techniques sous-optimales comme Inlining utilisent également la fonctionnalité push pour forcer le serveur à répondre aux demandes. Dans le même temps, Server Push est une solution au niveau du protocole qui permet d'éviter de s'embêter avec des hacks d'optimisation.

HTTP/2 multiplexe et hiérarchise le flux de données proactif pour améliorer les performances, tout comme les autres flux de requêtes-réponses. Il existe un mécanisme de sécurité intégré selon lequel le serveur doit être autorisé à l'avance pour un transfert proactif ultérieur de ressources.

Protocole binaire

La dernière version de HTTP a subi des changements importants en termes de capacités et démontre la transformation d'un protocole textuel en un protocole binaire. HTTP 1.x traite les commandes de texte pour terminer les cycles demande-réponse. HTTP/2 résout les mêmes problèmes en utilisant des commandes binaires (composées de uns et de zéros). Cela facilite le travail avec les cadres et facilite l'implémentation de commandes qui pourraient prêter à confusion car elles sont constituées de texte et d'espaces facultatifs.

Les commandes binaires seront plus difficiles à lire que les commandes texte similaires, mais il sera plus facile pour le réseau de les générer et d'analyser les trames. La sémantique reste inchangée. Les navigateurs utilisant HTTP/2 convertissent les commandes texte en commandes binaires avant de les envoyer au réseau. La couche binaire des frames n'est pas rétrocompatible avec les clients et les serveurs utilisant HTTP 1.x. Il s'agit d'un facteur clé pour offrir des gains de performances significatifs par rapport à SPDY et HTTP 1.x. Quels avantages l'utilisation de commandes binaires apporte-t-elle aux sociétés Internet et aux services en ligne :

• La faible surcharge d'analyse des données constitue un avantage essentiel de HTTP/2 par rapport à HTTP 1.
• Moins de risques d'erreurs.
• Résout les problèmes de sécurité tels que les attaques par fractionnement de réponse qui découlent de la nature textuelle de HTTP 1.x.
• D'autres fonctionnalités HTTP/2 sont implémentées, notamment la compression, le multiplexage, la priorisation, le contrôle de flux et la gestion TLS efficace.
• La compacité des commandes simplifie leur traitement et leur mise en œuvre.
• Une plus grande efficacité et résilience aux pannes lors du traitement des données transférées entre le client et le serveur.
• Latence réseau réduite et débit accru.

Priorisation des threads

HTTP/2 permet au client de donner la préférence à des flux de données spécifiques. Bien que le serveur ne soit pas obligé de suivre de telles instructions client, ce mécanisme aide néanmoins le serveur à optimiser l'allocation des ressources réseau en fonction des exigences des utilisateurs finaux.

La priorisation est réalisée en attribuant des dépendances et un poids à chaque thread. Bien que tous les threads dépendent déjà les uns des autres, ils ajoutent également une attribution de poids comprise entre 1 et 256. Les détails du mécanisme de priorisation sont toujours en cours de discussion. Cependant, dans le monde réel, le serveur gère rarement les ressources telles que les connexions au processeur et aux bases de données. La complexité de la mise en œuvre empêche à elle seule les serveurs de répondre aux demandes de priorisation des threads. La poursuite des travaux dans cette direction est particulièrement importante pour le succès à long terme de HTTP/2, car le protocole permet de traiter plusieurs flux au sein d'une seule connexion TCP.

La priorisation permettra de séparer les requêtes arrivant simultanément sur le serveur en fonction des besoins des utilisateurs finaux. Et le traitement des flux de données dans un ordre aléatoire ne fait que nuire à l'efficacité et à la commodité de HTTP/2. Dans le même temps, un mécanisme de priorisation des threads bien pensé et répandu nous apportera les avantages suivants :

• Utilisation efficace des ressources du réseau.
• Délai de livraison réduit pour les demandes de contenu principal.
• Augmentation de la vitesse de chargement des pages.
• Optimisation du transfert de données entre client et serveur.
• Réduire l’effet négatif des retards du réseau.

Compression d'en-tête avec état

Pour laisser la meilleure impression aux utilisateurs, les sites Web modernes doivent être riches en contenu et en graphiques. HTTP est un protocole sans état, ce qui signifie que chaque requête client doit contenir autant d'informations que possible dont le serveur a besoin pour effectuer l'opération correspondante. En conséquence, les flux de données contiennent de nombreuses trames répétitives car le serveur n'a pas besoin de stocker les informations des requêtes client précédentes.

Si un site Web contient beaucoup de contenu multimédia, le client envoie un ensemble de trames presque identiques avec des en-têtes, ce qui augmente la latence et conduit à une consommation excessive de ressources réseau infinies. Sans optimiser davantage la combinaison de flux de données prioritaires, nous ne serons pas en mesure d’atteindre les normes de performances de concurrence souhaitées.

HTTP/2 résout ce problème en compressant un grand nombre de trames d'en-tête redondantes. La compression est effectuée à l'aide de l'algorithme HPACK, qui est une méthode simple et sécurisée. Le client et le serveur conservent une liste d'en-têtes utilisés dans les requêtes précédentes.

HPACK compresse la valeur de chaque en-tête avant de l'envoyer au serveur, qui recherche ensuite les informations cryptées dans une liste de valeurs précédemment reçues pour récupérer les données complètes de l'en-tête. La compression HPACK offre des avantages incroyables en termes de performances et fournit également :

• Hiérarchisation efficace des threads.
• Utilisation efficace des mécanismes de multiplexage.
• Réduit les frais généraux lors de l’utilisation des ressources. C'est l'un des premiers problèmes abordés lors de la comparaison de HTTP/2 avec HTTP 1 et SPDY.
• Encodage des en-têtes volumineux et fréquemment utilisés afin que vous n'ayez pas à envoyer la trame entière avec l'en-tête. La taille transmise de chaque flux diminue rapidement.
• Résistant aux attaques telles que CRIME - exploits de flux de données avec en-têtes compressés.

Différences entre HTTP 1.x et SPDY

La sémantique de base d'une application HTTP reste inchangée dans la dernière itération de HTTP/2, y compris les codes d'état, les URI, les techniques et les fichiers d'en-tête. HTTP/2 est basé sur SPDY, l'alternative de Google à HTTP 1.x. Les principales différences résident dans les mécanismes de traitement des requêtes client-serveur. Le tableau montre les principales différences entre HTTP 1.x, SPDY et HTTP/2 :

HTTP1.x	SPDY	HTTP2
	SSL requis.	SSL n'est pas obligatoire, mais recommandé.
Cryptage lent.	Cryptage rapide.	Le cryptage est devenu encore plus rapide.
Une requête client-serveur par connexion TCP.	De nombreuses requêtes client-serveur par connexion TCP. Ils sont effectués simultanément sur un seul hôte.	Multiplexage multi-hôtes. Implémenté sur plusieurs hôtes en une seule instance.
Pas de compression d'en-tête.	La compression d'en-tête a été introduite.	Des algorithmes de compression d'en-tête améliorés sont utilisés pour améliorer les performances et la sécurité.
Aucune priorisation des threads.	La priorisation des threads a été introduite.	Mécanismes de priorisation des threads améliorés.

Comment HTTP/2 fonctionne avec HTTPS

HTTPS est utilisé pour établir une connexion réseau hautement sécurisée, qui joue un rôle majeur dans le traitement des informations sensibles sur les entreprises et les utilisateurs. Les principales cibles des attaquants sont les banques qui traitent les transactions financières et les établissements de santé qui accumulent des dossiers médicaux. HTTPS agit comme une couche de protection contre les cybermenaces persistantes, même si repousser les attaques sophistiquées ciblant les réseaux d’entreprise de valeur n’est pas seulement une question de sécurité.

La prise en charge du navigateur pour HTTP/2 inclut le cryptage HTTPS et améliore réellement les performances globales de sécurité lorsque vous travaillez avec HTTPS. Les principales fonctionnalités de HTTP/2 pour garantir la sécurité des communications numériques dans les environnements réseau sensibles sont :

• moins de poignées de main TLS,
• moins de consommation de ressources côté client et côté serveur,
• Capacité améliorée de réutiliser les sessions Web existantes, mais sans les vulnérabilités de HTTP 1.x.

HTTPS n'est pas seulement utilisé dans des entreprises renommées et pour assurer la cybersécurité. Ce protocole est également utile aux propriétaires de services en ligne, aux blogueurs ordinaires, aux boutiques en ligne et même aux utilisateurs de réseaux sociaux. HTTP/2 nécessite la version la plus récente et la plus sécurisée de TLS. Toutes les communautés en ligne, propriétaires d'entreprise et webmasters doivent donc s'assurer que leurs sites utilisent HTTPS par défaut.

Les procédures courantes de configuration de HTTPS incluent l'utilisation de plans d'hébergement Web, l'achat, l'activation et l'installation de certificats de sécurité, ainsi que la mise à jour du site lui-même afin qu'il puisse utiliser HTTPS.

Principaux avantages du HTTP/2

L'industrie des réseaux doit remplacer le HTTP 1.x obsolète par un autre protocole qui profitera aux utilisateurs moyens. La transition de HTTP 1.x vers HTTP/2 repose presque entièrement sur la maximisation du potentiel d’avantages technologiques pour répondre aux attentes modernes.

Du point de vue des e-commerçants et des internautes, plus il y a de contenus peu pertinents et riches en médias sur Internet, plus il est lent.

HTTP/2 a été créé en tenant compte de l'efficacité accrue de l'échange de données client-serveur, qui permet aux hommes d'affaires d'augmenter la couverture de leurs segments de marché et aux utilisateurs d'accéder rapidement à un contenu de qualité. Entre autres choses, le Web est aujourd’hui plus situationnel que jamais.

Les vitesses d'accès à Internet varient en fonction des réseaux spécifiques et des emplacements géographiques. La part des utilisateurs mobiles augmente rapidement, ce qui nécessite de garantir des vitesses Internet suffisamment élevées sur les appareils mobiles, quel que soit leur format, même si les réseaux cellulaires surchargés ne sont pas en mesure de rivaliser avec l'accès haut débit. La solution complète à ce problème est HTTP/2, qui est une combinaison de mécanismes de mise en réseau et de transfert de données entièrement révisés et repensés. Quels sont les principaux avantages du HTTP/2 ?

Performances du réseau

Ce concept reflète l'effet cumulatif de toutes les innovations HTTP/2. Les résultats du benchmark (voir chapitre « Comparaison des performances de HTTPS, SPDY et HTTP/2 ») montrent une augmentation des performances lors de l'utilisation de HTTP/2 par rapport à ses prédécesseurs et solutions alternatives.

La capacité du protocole à envoyer et recevoir davantage de données à chaque cycle de communication client-serveur n'est pas un hack d'optimisation, mais un avantage réel, accessible et pratique de HTTP/2. Une analogie consiste à comparer un train à vide à un train conventionnel : l’absence de friction et de résistance de l’air permet au véhicule de se déplacer plus rapidement, de transporter plus de passagers et de mieux utiliser les canaux disponibles sans installer de moteurs plus puissants. Le poids du train est également réduit et son aérodynamisme est amélioré.

Des technologies telles que le multiplexage permettent de transmettre davantage de données en même temps. Comme un gros avion de ligne, avec plusieurs étages remplis de sièges.

Que se passe-t-il lorsque les mécanismes de transfert de données suppriment tous les obstacles aux performances du réseau ? La vitesse élevée d'un site Web a des effets secondaires : les utilisateurs en profitent davantage, l'optimisation des services de recherche s'améliore, les ressources sont utilisées plus efficacement, l'audience et les volumes de ventes augmentent, et bien plus encore.

Heureusement, la mise en œuvre de HTTP/2 est incomparablement plus pratique que la création de tunnels sous vide pour les grands trains de voyageurs.

Performances du réseau mobile

Chaque jour, des millions d’utilisateurs accèdent à Internet depuis leurs appareils mobiles. Nous vivons dans « l’ère post-PC », avec de nombreuses personnes utilisant les smartphones comme principal appareil pour accéder aux services en ligne et effectuer la plupart des tâches informatiques courantes en déplacement, plutôt que de rester assises devant des écrans de bureau pendant de longues périodes.

HTTP/2 a été conçu en tenant compte des tendances modernes en matière d'utilisation du réseau. La tâche consistant à niveler la petite bande passante de l'Internet mobile est bien résolue en réduisant la latence grâce au multiplexage et à la compression d'en-tête. Grâce à la nouvelle version du protocole, les performances et la sécurité de l'échange de données sur les appareils mobiles atteignent le niveau caractéristique des ordinateurs de bureau. Cela a immédiatement un effet positif sur la capacité d’une entreprise en ligne à atteindre un public potentiel.

Internet est moins cher

Depuis la création du World Wide Web, le coût d’utilisation d’Internet a rapidement diminué. Les principaux objectifs du développement des technologies de réseau ont toujours été d'élargir l'accès et d'augmenter sa vitesse. Toutefois, les réductions de prix semblent être au point mort, notamment à la lumière des allégations de monopole des opérateurs de télécommunications.

Un débit accru et une efficacité accrue de l'échange de données lors de la mise en œuvre de HTTP/2 permettront aux fournisseurs de réduire les coûts d'exploitation sans réduire la vitesse d'accès. À son tour, la réduction des coûts d'exploitation permettra aux fournisseurs de se promouvoir plus activement dans le segment des prix bas, ainsi que d'offrir des vitesses d'accès plus élevées dans le cadre des tarifs existants.

Couverture étendue

Les régions densément peuplées d’Asie et d’Afrique n’ont toujours pas accès à Internet à des vitesses acceptables. Les prestataires tentent d'extraire un maximum de profits en proposant leurs services uniquement dans les grandes villes et les zones développées. Grâce aux avantages de HTTP/2, il sera possible de réduire la charge sur les réseaux en allouant une partie des ressources et de la bande passante aux habitants des zones reculées et moins développées.

Richesse des médias

Aujourd'hui, les internautes exigent pratiquement des contenus et des services multimédias riches avec un chargement instantané des pages. Dans le même temps, pour être compétitifs, les propriétaires de sites Web doivent régulièrement mettre à jour leur contenu. Le coût de l'infrastructure correspondante n'est pas toujours abordable pour les startups Internet, même si elles utilisent des services d'abonnement cloud. Les avantages et les fonctionnalités technologiques de HTTP/2 ne contribueront probablement pas à réduire considérablement la taille des fichiers, mais ils supprimeront quelques octets de la surcharge lors du transfert de contenu multimédia « lourd » entre le client et les serveurs.

Améliorer l'expérience Internet mobile

Les entreprises en ligne avant-gardistes poursuivent une stratégie Mobile-First pour atteindre efficacement le public mobile en croissance rapide. La principale limitation affectant l'utilisation de l'Internet mobile ne réside peut-être pas dans les caractéristiques les plus remarquables des composants matériels des smartphones et des tablettes. Cela entraîne des délais plus longs dans le traitement des demandes. HTTP/2 réduit les temps de téléchargement et la latence du réseau à des niveaux acceptables.

Utilisation plus efficace du réseau

Les contenus multimédias « lourds » et les sites au design complexe entraînent une augmentation notable de la consommation de ressources lors du traitement des requêtes du navigateur par le client et le serveur. Bien que les développeurs Web aient développé des hacks d’optimisation acceptables, l’émergence d’une solution stable et fiable sous la forme de HTTP/2 était inévitable. La compression d'en-tête, le transfert proactif du serveur, les dépendances de flux et le multiplexage sont autant de fonctionnalités clés qui améliorent l'efficacité du réseau.

Sécurité

Les avantages de HTTP/2 vont au-delà des seules performances. L'algorithme HPACK vous permet de contourner les menaces courantes qui ciblent les protocoles texte au niveau des applications. Pour protéger les données transmises entre client et serveur, HTTP/2 utilise l'approche Security by Obscurity : les commandes sont présentées sous forme binaire et la compression des métadonnées d'en-tête HTTP est utilisée. De plus, le protocole offre une prise en charge complète du cryptage et nécessite l'utilisation d'une version améliorée de Transport Layer Security (TLS1.2).

Innovation

HTTP/2 est l’incarnation de l’idée d’un réseau performant. Ce protocole est à la base du cybermonde tel que nous le connaissons aujourd’hui. Les changements introduits par HTTP/2 sont principalement basés sur les fonctionnalités de SPDY, qui constituent une énorme amélioration par rapport à HTTP 1.x. Et dans un avenir proche, HTTP/2 remplacera complètement SPDY et les versions précédentes de HTTP. Les développeurs Web pourront se débarrasser des hacks d'optimisation complexes lors de la création de sites et de services hautes performances.

Avantages SEO de HTTP/2

Le marketing SEO se situe quelque part entre la science et l’art. En raison de la complexité croissante des algorithmes propriétaires utilisés par les moteurs de recherche populaires, les techniques de référencement malhonnêtes traditionnelles ne permettent plus de manipuler les résultats de recherche. Et en conséquence, les entreprises en ligne doivent changer leurs stratégies marketing. Vous devez investir judicieusement dans des sites construits à partir de zéro, soigneusement conçus, optimisés non seulement pour la vitesse, mais aussi pour des performances, une sécurité et une expérience utilisateur supérieures. Il s'agit d'attributs plus préférables qui vous permettent de créer des résultats de recherche avec les informations les plus précises et des sites faciles à utiliser pour l'ensemble du public cible.

Les processus standard d’optimisation des moteurs de recherche vont au-delà des tactiques de marketing front-end. Désormais, ils couvrent le cycle complet de l’échange de données entre client et serveur. Les référenceurs, qui étaient auparavant des figures clés des équipes de marketing en ligne, ont perdu leur place avec l'avènement des nouvelles technologies de communication numérique. Et la domination de HTTP/2 parmi eux indique un changement tectonique qui oblige les développeurs Web et les spécialistes du marketing à retourner à la planche à dessin.

Aujourd’hui, un facteur critique pour le référencement est la mise en œuvre et l’optimisation de l’infrastructure pour HTTP/2 et ses avantages prometteurs en termes de performances. Les entreprises en ligne qui ne disposent pas d’une base d’utilisateurs organiques adéquate ne peuvent pas se permettre de négliger HTTP/2 et donc les améliorations du point de vue du référencement. Après tout, ces entreprises doivent rivaliser sur la base de l’innovation avec des empires commerciaux en ligne en pleine croissance, et un service en ligne de premier plan progressera encore plus grâce à la mise en œuvre de HTTP/2 côté serveur.

Comparaison des performances de HTTPS, SPDY et HTTP/2

Les résultats du benchmark montrent clairement la situation d'amélioration des performances dans le nouveau protocole.

Les résultats du benchmark HTTP/2 confirment que la compression des en-têtes, le transfert proactif du serveur et d'autres mécanismes utilisés pour accélérer le chargement des pages sont effectivement mis en œuvre de manière cohérente.

Détails des tests :

Les résultats de ce test nous disent ce qui suit :

• Tailles des en-têtes de requête client et de réponse du serveur: HTTP/2 démontre que l'utilisation de la compression peut réduire considérablement la taille de l'en-tête. Dans ce cas, SPDY réduit uniquement l'en-tête de réponse du serveur pour cette requête. HTTPS ne réduit pas du tout les en-têtes.
• Taille du message de réponse du serveur: La taille de réponse du serveur HTTP/2 était plus grande, mais il utilisait un cryptage plus fort.
• Nombre de connexions TCP utilisées: Lors du traitement de plusieurs requêtes simultanées (multiplexage), HTTP/2 et SPDY utilisent moins de ressources réseau, donc une latence plus faible.
• Vitesse de chargement des pages: HTTP/2 était systématiquement plus rapide que SPDY. HTTPS était nettement plus lent en raison du manque de compression des en-têtes et du serveur qui envoyait les données de manière proactive.

Prise en charge et accessibilité du navigateur HTTP/2

HTTP/2 peut déjà être utilisé avec une prise en charge adéquate des serveurs et navigateurs, y compris mobiles. Les technologies qui utilisent HTTP 1.x ne seront pas perturbées par la mise en œuvre de HTTP/2 sur votre site. Mais ils devront être rapidement mis à jour pour prendre en charge le nouveau protocole. Considérez les protocoles réseau comme des langages de communication. Vous ne pouvez communiquer dans de nouvelles langues que lorsque vous vous comprenez d'une manière ou d'une autre. Idem ici : le client et le serveur doivent être mis à jour pour prendre en charge l'échange de données à l'aide du protocole HTTP/2.

Assistance client

Les utilisateurs n'ont pas à se soucier de la configuration du support HTTP/2 dans leurs navigateurs - complets et mobiles. Chrome et Firefox prennent en charge cette technologie depuis longtemps et dans Safari, la prise en charge de HTTP/2 est apparue en 2014. Dans IE, ce protocole n'est pris en charge qu'à partir de Windows 8.

Les principaux navigateurs mobiles, notamment le navigateur Android, Chrome pour Android et iOS et Safari dans iOS8 et versions ultérieures, prennent déjà en charge HTTP/2. Par mesure de sécurité, nous vous recommandons d'installer les dernières versions stables de vos navigateurs mobiles et de bureau pour obtenir des performances et des avantages en matière de sécurité optimaux.

Prise en charge du serveur : Apache et Nginx

Les propriétaires de services en ligne exécutés sur site ou dans le cloud doivent mettre à jour et configurer leurs serveurs pour ajouter la prise en charge HTTP/2. Selon l'analogie linguistique ci-dessus, les utilisateurs ne peuvent récupérer les données des serveurs que via HTTP/2, car ils ont été mis à jour et configurés à cet effet.

Les serveurs Nginx, qui représentent 66 % de tous les serveurs Web actifs, disposent d'une prise en charge intégrée de HTTP/2. Et pour fournir une prise en charge du navigateur pour HTTP/2 sur Apache, vous devez utiliser le module mod_spdy. Il a été développé par Google pour introduire la prise en charge d'Apache 2.2 pour des fonctionnalités telles que le multiplexage et la compression d'en-tête. Ce logiciel a été offert à l'Apache Software Foundation.

Comment commencer à utiliser HTTP/2 ?

Pour configurer HTTP/2 sur votre site Web, utilisez ces instructions simples :

1. Vérifiez que HTTPS est activé :
   • Achetez un certificat SSL ou TLS auprès d'une organisation réputée.
   • Activez le certificat.
   • Installez le certificat.
   • Mettez à jour votre serveur pour activer HTTPS.
2. Vérifiez que l'infrastructure réseau sous-jacente inclut la prise en charge de HTTP/2 au niveau du logiciel serveur. Les serveurs Nginx disposent d'un support natif ; il est apparu dans Apache en octobre 2015 (en version 2.4). Dans les versions antérieures, des modules supplémentaires doivent être installés pour prendre en charge HTTP/2.
3. Mettez à jour, configurez et testez vos serveurs. Les procédures de configuration et de test des serveurs Apache sont décrites. Contactez votre fournisseur d'hébergement et assurez-vous que votre site est prêt pour HTTP/2.
4. Pour vérifier si votre configuration HTTP/2 est correcte, utilisez cet outil.

Conclusion

L’inévitable domination et supériorité de HTTP/2 nous attend. Le protocole de couche application semble porter l'héritage de HTTP 1.x, qui a autrefois transformé le Web grâce à ses capacités révolutionnaires de transfert de données. Mais HTTP/2 démontre une bien plus grande supériorité technologique sur son prédécesseur que HTTP 1.x à son époque.

Cependant, l’utilisation de HTTP/2 n’est qu’une étape vers l’augmentation de la vitesse de chargement des pages. Notre guide du débutant sur l'optimisation de la vitesse d'un site Web explique comment créer des sites Web rapides, comment éliminer les goulots d'étranglement en matière de performances et les avantages commerciaux stratégiques d'une performance supérieure du site Web.

Balises : Ajouter des balises

23.04.18 827

Protocole de transfert hypertexte ( HTTP) gère la connexion entre le serveur et les navigateurs. Pour la première fois depuis 1999, nous avons reçu nouvelle version de ce protocole, et il promet des sites Web nettement plus rapides pour tout le monde.

je vais en parler principales caractéristiques du nouveau protocole, je considérerai sa compatibilité avec les navigateurs et les serveurs.

Une brève histoire de HTTP

HTTP est un ancien protocole initialement défini en 1991, et pour la dernière fois sérieusement modifié dans la version HTTP/1.1.

Les sites Web de 1999 étaient très différents de ceux que nous développons aujourd’hui. Actuellement, il faut 1,9 Mo pour afficher la page d’accueil d’un site Web moyen. Celui-ci télécharge plus de 100 ressources individuelles, des images et polices aux fichiers JavaScript et CSS.

HTTP/1.1 ne fonctionne pas bien avec de grandes quantités de ressources. Par conséquent, les meilleures pratiques d’optimisation visent à améliorer les performances de cette version du protocole.

SPDY

En 2009, deux ingénieurs de Google parlaient d'un projet de recherche appelé SPDY. Ce projet visait à résoudre des problèmes liés au fonctionnement du protocole HTTP/1.1. SPDY vous permet de :

• Utiliser des requêtes concurrentes sur la même connexion TCP ( multiplexage).
• Les navigateurs définissent des priorités afin que les ressources importantes pour l'affichage de la page soient chargées en premier.
• Compresser et réduire les en-têtes HTTP
• Implémentez la technologie Server Push, dans laquelle le serveur peut envoyer des ressources importantes au navigateur avant qu'il ne lui soit demandé de le faire.

De plus, SPDY exige que la connexion soit cryptée ( HTTPS) entre le navigateur et le serveur.

SPDY ne remplace pas HTTP. Il s'agit davantage d'un tunnel de protocole et modifie le processus d'envoi de requêtes et de réponses HTTP. Cela nécessite un support à la fois côté serveur et côté client. Grâce au support disponible dans NGNIX et aux packages Google pour Apache, SPDY a été largement utilisé. En même temps versions modernes des principaux navigateurs le soutenons pleinement.

Prise en charge SPDY navigateurs selon " Puis-je utiliser »

HTTP/2

La prise en charge de SPDY a été interrompue dans Edge en raison du fait que Microsoft a implémenté la prise en charge de HTTP/2 dans le nouveau navigateur, la dernière version du protocole HTTP. Mais d'autres navigateurs modernes prennent toujours en charge SPDY.

Prise en charge HTTP /2 navigateurs selon " Puis-je utiliser »

HTTP/2 s'appuie sur le succès de SPDY, qui a été utilisé comme plateforme de lancement du nouveau protocole. Dans le même temps, la plupart des tâches SPDY également implémenté en HTTP/2. L'exigence de connexion HTTPS a été supprimée. Malgré cela, les développeurs de tous les navigateurs ont décidé d'implémenter le support HTTP/2 pour TLS uniquement ( https) connexions. Par conséquent, utiliser HTTP/2 signifie que le site utilise HTTPS.

La spécification HTTP/2 a été finalisée en février 2015. Un an plus tard, il est parfaitement supporté par les navigateurs. Tout comme SPDY, HTTP/2 nécessite une prise en charge à la fois dans le navigateur et sur le serveur.

Il existe déjà de nombreuses implémentations pour les serveurs. Vous pouvez les suivre sur Référence HTTP/2.

Les sites devront-ils être modifiés ?

HTTP/2 est rétrocompatible avec HTTP/1.1, il est donc possible de l'ignorer et tout continuera à fonctionner comme avant. Le changement de protocole est invisible pour les utilisateurs. De nombreux lecteurs de cet article utilisent déjà depuis de nombreuses années un protocole autre que HTTP/1.1. Par exemple, si vous disposez d'un compte dans le service de messagerie Gmail et que vous utilisez le navigateur Google Chrome pour y accéder.

Mais au fil du temps, à mesure que de nombreux serveurs et navigateurs seront mis à jour vers HTTP/2, votre site, une fois optimisé selon les meilleures pratiques, commencera à paraître lent par rapport aux ressources Internet optimisées pour le nouveau protocole.

Que faut-il changer pour profiter de HTTP/2 ?

Avant d'apporter les modifications nécessaires pour déplacer votre site vers HTTP/2, vous devez déterminer si les visiteurs de votre site utilisent des navigateurs prenant en charge ce protocole.

Passer à TLS

Pour de nombreuses ressources, la chose la plus difficile lors du passage à HTTP/2 n'est peut-être pas le protocole lui-même, mais l'exigence que le site fonctionne via une connexion sécurisée. Si vous développez un nouveau site ou mettez à jour un ancien, la première étape devrait être de passer au https.

Ceci n’est pas seulement important pour HTTP/2. Google utilise connexion sécurisée comme signal lors du classement d'un site, et les navigateurs commencent à marquer les sites non-https comme « dangereux ».

Convertir plusieurs fichiers image en sprites

Avec HTTP/1.1, récupérer une grande image est beaucoup plus efficace pour le navigateur que d'effectuer plusieurs requêtes sur de petits fichiers. Pour contourner ce problème, vous pouvez inclure les icônes dans un seul fichier sprite.

Le sprite résultant a été renvoyé dans une seule requête HTTP, empêchant les requêtes de se mettre en file d'attente. Mais même si un visiteur se trouvait sur une page qui n’affichait qu’une seule de ces icônes, il lui faudrait quand même télécharger un fichier beaucoup plus volumineux pour voir une image spécifique.

Grâce à multiplexage dans Les files d'attente de demandes de ressources HTTP/2 ne posent plus de problème. Il est préférable de fournir des images individuelles pour plusieurs raisons : Vous n'aurez qu'à envoyer ce qui est demandé.

Mais un sprite peut réduire la taille des données téléchargées. Surtout quand toutes ces images sont utilisées sur la page de chargement. Cependant, utiliser des sprites n’est plus la meilleure option.

Incorporation d'images à l'aide d'URI de données

Une autre méthode pour résoudre le problème des requêtes multiples dans HTTP/1.1 est intégration d'images dans CSS à l'aide de l'URI de données. L'intégration d'images de cette manière augmente considérablement la taille du fichier de styles. Si vous combinez cette méthode avec une autre technique d’optimisation, le navigateur chargera-t-il tout ce CSS ? même si l'utilisateur ne visite pas les pages qui utilisent ces images. Dans HTTP/2, cette « meilleure pratique » est plus susceptible de nuire aux performances que de les améliorer.

Connecter CSS et JavaScript

Lors de la dernière étape de la création d’un site, de nombreuses personnes combinent tous les petits fichiers CSS et JavaScript utilisés. Nous les séparons souvent lors du développement pour les rendre plus faciles à gérer. Mais la livraison d’un fichier au navigateur est plus efficace en termes de performances que la livraison de cinq. Et nous essayons à nouveau de réduire le nombre de requêtes HTTP.

Si vous faites cela, les visiteurs devront alors télécharger tous les styles CSS et JavaScript du site. Vous pouvez contourner ce problème en incluant uniquement certains fichiers pour chaque zone du site pendant le processus de construction.

Requêtes HTTP " le moins cher" du monde HTTP/2. Une organisation page par page des ressources utilisées lors du développement d’un site Web serait une bien meilleure idée. De cette façon, il sera possible de charger dans le navigateur uniquement le code nécessaire à l'affichage de la page Web actuelle.

Partage de ressources entre hôtes : Sharding

Lorsque vous utilisez le protocole HTTP/1.1, vous êtes limité dans le nombre de connexions ouvertes simultanément. Si le téléchargement d’un grand nombre de ressources est inévitable, une méthode pour contourner cette limitation consiste à les récupérer dans différents domaines. Cette méthode est connue sous le nom de partitionnement de domaine. Avec son aide, vous pouvez réduire le temps de chargement. Mais cela peut créer des problèmes, sans parler du coût de préparation des infrastructures du site.

HTTP/2 élimine le besoin d'utiliser Partage de domaine : vous pouvez demander n'importe quel nombre de ressources. Mais cela nuira aux performances : cela crée des connexions TCP supplémentaires et interfère avec la priorisation HTTP/2.

Comment se préparer à HTTP/2

Quelques conseils pour préparer la transition vers HTTP/2.

Créez des images distinctes en plus des sprites et des intégrations d'images

Optimisez les sprites et les images individuelles utilisées au niveau de la page si vous pensez que l'utilisation de sprites améliorera les performances du site. Cela facilitera la transition des grands sprites aux petits.

Organiser les fichiers par sections du site

Lors de la migration vers HTTP/2, vous Obtenez de meilleures performances tout en gérant soigneusement les ressources, lorsque seul ce dont une page spécifique a besoin est envoyé à cette page.

Gérer la séparation entre les domaines

Actuellement, la meilleure pratique pour HTTP/1.1 consiste à limiter la séparation à deux noms d'hôte. Dans HTTP/2, il existe un moyen de fusionner ces connexions si le certificat TLS est valide pour les deux hôtes et que les hôtes sont sur la même adresse IP. Certificat TLS requis travailler via HTTP/2.

Prochaines étapes

Cet article ne traite pas de la manière de tirer parti des nouveaux outils HTTP/2 tels que le push serveur. Cette technologie permet de décider quelles ressources sont prioritaires et oblige le serveur à les transférer avant les ressources moins importantes.

Quand faire la transition ?

La décision de passer à HTTP/2 se résume à : Ce protocole est-il supporté par la plupart des navigateurs de vos utilisateurs ?. N'oubliez pas que HTTP/2 est rétrocompatible, vous n'aurez donc rien de spécial à faire.

Si la majorité des visiteurs utilisent des navigateurs prenant en charge HTTP/2, il est temps d'optimiser pour ces utilisateurs. Par exemple, bon nombre des avantages de HTTP/2 seront ressentis avec plus d’acuité par les utilisateurs d’appareils mobiles. Si votre site a un pourcentage élevé de trafic mobile, cela peut être un signal pour passer à HTTP/2.

Votre plan d'action HTTP/2

1. Lancez votre site avec une connexion sécurisée ou passez à TLS maintenant.
2. Préparez-vous à HTTP/2 lors de la création de votre site. Utilisez les conseils ci-dessus pour créer un site optimisé pour les deux versions du protocole.
3. Vérifiez votre hébergement. Assurez-vous que votre serveur prend en charge HTTP/2.
4. Déployez l’optimisation HTTP/2. Arrêtez d’utiliser des pratiques obsolètes et commencez à en utiliser de nouvelles.

Une fois que vous êtes passé à HTTP/2, cela vaut la peine de vérifier dans quelle mesure la vitesse de votre site augmentera.

En savoir plus

Une quantité croissante d’informations sur HTTP/2 est disponible sur le Web. Ci-dessous, j'ai répertorié certaines des ressources que j'ai consultées lors de la rédaction de cet article.

• “Protocole de transfert hypertexte version 2 (HTTP/2)» (spécification).
  Ceci s’adresse aux personnes qui aiment lire les spécifications ou qui ont besoin d’en comprendre les subtilités. Pour tous les autres, la FAQ HTTP/2 est un excellent aperçu des principales fonctionnalités.
• Indicateur HTTP/2 et SPDY : Chrome.
  Ce plugin vous permet de savoir si le site sur lequel vous vous trouvez est servi en HTTP/2.

Traduction de l’article « Se préparer pour HTTP/2 Un guide pour les concepteurs et développeurs Web» a été préparé par l’équipe sympathique du projet.

Bon Mauvais

18.07.2017 11:41

HTTP/2 est la deuxième version du célèbre protocole HTTP. Le nom complet de ce protocole ressemble à HTTP/2.0. Comme vous le savez, HTTP – ou Hypertex Transfer Protocol – est un protocole utilisé pour transférer de l'hypertexte. En d’autres termes, grâce à HTTP, les pages Web sont chargées et affichées via le navigateur aux internautes.

Le protocole HTTP est apparu il y a longtemps : la première version - pas même la première, mais la 0.9 - est sortie en 1991. Huit ans plus tard, en 1999, est apparue la version de HTTP activement utilisée aujourd'hui : HTTP/1.1. Il semblerait que si tout fonctionne, pourquoi changer quoi que ce soit ? Mais comme pour tout ce qui se développe, le progrès ne s’arrête pas, tout change et nécessite des changements.

Développement

Le développement de la nouvelle version du protocole a été réalisé par le groupe de travail HTTPbis de l'Internet Engineering Task Force (Internet Engineering Council, qui développe les normes Internet). Elle a été créée en 2007 spécifiquement pour travailler sur ce projet. Cependant, des actions actives n’ont commencé à avoir lieu que cinq ans plus tard, en 2012.

La base de HTTP/2 était le protocole SPDY (peut être déchiffré comme « speedy » – rapide). Le développeur de ce hack, Google, l'a créé afin de réduire le temps de chargement des pages Web. En particulier, le protocole SPDY permet de prioriser et de multiplexer plusieurs transferts de fichiers afin qu'une seule connexion soit nécessaire pour chaque client.

L'un des membres du groupe de travail, Daniel Stenberg, a publié au printemps 2014 un document expliquant pourquoi les travaux sur ce projet ont commencé et comment ils se déroulent. Le document est également disponible en russe : https://bagder.gitbooks.io/http2-explained/ru/

Voici les points brièvement listés dans la description du concept :

• Les paradigmes HTTP doivent être pris en charge ;
• les liens http:// et https:// doivent rester, pas besoin d'ajouter un nouveau schéma ;
• les serveurs et les clients utilisant HTTP/1 doivent être proxy vers les serveurs HTTP/2 ;
• Les fonctionnalités HTTP/2 doivent être converties en HTTP/1.1 à l'aide d'un proxy ;
• réduire le nombre de parties facultatives dans le protocole ;
• manque de versions mineures dans HTTP/2 ; Le protocole HTTP/3 sera développé si nécessaire.

Innovations

L'objectif principal du développement du nouveau protocole est d'augmenter la vitesse de chargement des pages. Par conséquent, les développeurs ont également cherché à se débarrasser de certains éléments qui entravent la productivité.

HTTP/2 est protocole binaire. Le choix du binaire a été fait pour rendre la formation des packages plus facile et plus simple. Cela a notamment permis de séparer plus facilement les parties associées au protocole et celles associées au paquet de données (ce problème est présent dans HTTP/1).

Multiplexage de flux- c'est sur cela que se concentre le nouveau développement. Si auparavant les paquets de plusieurs flux étaient livrés séparément, alors avec le protocole HTTP/2, les paquets d'une connexion sont mélangés et séparés de l'autre côté.

De plus, chaque fil a son propre poids ou, en d'autres termes, sa priorité afin que vous puissiez comprendre quels fils sont considérés comme les plus importants et lesquels le sont moins. Ceci est pertinent dans les situations où les ressources sont limitées et où le serveur est obligé de choisir les flux qui seront envoyés en premier.

HTTP/2 utilise des trames binaires, ce qui peut faciliter la gestion des flux. En particulier, le cadre PRIORITY permet d'indiquer quels threads dépendent d'un thread donné, c'est-à-dire de créer un certain schéma, un arbre de priorités indiquant les relations entre eux. Dans ce cas, l’importance des flux peut changer de manière dynamique. D'un point de vue pratique, cela vous permet, par exemple, de spécifier quelles images d'une page vous souhaitez que le navigateur charge en premier.

Ça vaut le coup séparément question compression. HTTP est un protocole sans état, ce qui signifie qu’il s’agit d’un protocole reproductible. En pratique, cela se traduit par le fait que si une requête concernant plusieurs ressources (par exemple des images) est envoyée au serveur, cela donne lieu à une série de requêtes elles-mêmes quasiment identiques. Il est donc logique qu’une compression soit nécessaire.

Cependant, il y a ici aussi des pièges. En particulier, les compressions HTTPS et SPDY sont vulnérables à l'attaque BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), qui exploite des failles de l'algorithme de compression gzip/DEFLATE, et à l'attaque CRIME (Compression Ratio Info-leak Made Easy), qui exploite également des algorithmes de compression de données.

En conséquence, l'équipe HTTPbis a créé HPACK est un protocole spécialisé pour compresser les en-têtes HTTP/2. Lors de l'utilisation du protocole HTTP/2, les en-têtes de service (pour le chargement des éléments de page) sont transmis compressés, réduisant ainsi la quantité de ressources requises pour une telle opération.

Un autre cadre utile est RST_STEAM. Il est chargé d’annuler l’envoi d’un message, ceci sert à réduire le gaspillage de bande passante et à éviter les coupures de connexion. Par exemple, cette trame convient si vous devez signaler rapidement un flux envoyé qui s'avère inutile.

HTTP/2 vous permet d'augmenter la sécurité d'une ressource, mais avant de passer à HTTP/2, vous devez d'abord passer à HTTPS (même si maintenant, s'il vous plaît, la grande majorité l'a déjà fait).

Cependant, HTTP/2 est rétrocompatible avec HTTP/1, il n'est donc pas nécessaire de se précipiter pour transférer le site vers le nouveau protocole. Mais à l'avenir, bien sûr, vous remarquerez peut-être un certain ralentissement dans le chargement de votre site, car... les optimisations qui fonctionnaient pour HTTP/1 pourraient ne plus fonctionner pour la version 2 de ce protocole.

HTTP/2 est pris en charge par tous les principaux navigateurs : Chrome, Firefox, Opera, Edge, Safari.
Il est également recommandé de passer rapidement au HTTP/2 pour ceux qui ont beaucoup de trafic mobile.

Transition vers HTTP/2

Pour ceux qui sont intéressés par le passage vers HTTP/2, je vous conseille de lire cette documentation en anglais : https://cdn.wp.nginx.com/wp-content/uploads/2015/09/NGINX_HTTP2_White_Paper_v4.pdf

Conclusion

HTTP/2 est un protocole qui, d'une part, contient l'héritage de HTTP/1, et d'autre part, présente de nombreux avantages pour le transfert de données, ce qui se traduit par une supériorité significative de la nouvelle version du protocole sur son prédécesseur.

Dans cet article, nous parlerons de ce qu'est HTTP/2. Organisons une sorte de contrôle, un test : s'agit-il simplement d'un mot à la mode marketing ou d'un moyen vraiment sûr d'améliorer les performances du site (et vous pouvez le vérifier en effectuant des tests en ligne et en comparant les résultats d'analyse).

Il existe deux types de développeurs Web : ceux qui utilisent déjà HTTP/2 pour augmenter les performances d'un site Web et ceux qui sont prêts à utiliser HTTP/2 dans leurs futurs projets. Si vous n'avez pas encore entendu parler de HTTP/2, alors vous avez beaucoup de retard à rattraper sur cette question. Commençons.

Alors, qu’est-ce que HTTP/2 ? Est-ce juste un mot à la mode marketing ou est-ce vraiment quelque chose qui mérite qu’on y prête attention ?

HTTP/2 est la dernière version du célèbre protocole de transfert HTTP-Hypertext, utilisé sur le World Wide Web. Ce protocole permet de séparer les informations textuelles et multimédias à l'aide de liens dits Web entre des nœuds non connectés, tels qu'un navigateur et un serveur. Par exemple, votre navigateur utilise ce protocole pour télécharger cet article. Mais sans HTTP, il n’y aurait pas d’Internet !

Avant de passer en revue les avantages de HTTP/2 et d'expliquer pourquoi il accélérera votre site, comprenons d'abord comment les données sont transférées entre des systèmes indépendants.

PROTOCOLE RÉSEAU HTTP

HTTP utilise la technologie client-serveur. Cela signifie que votre navigateur (Firefox, Chrome, etc.) est le « client » et que notre blog fonctionne sur le serveur d'hébergement. Par exemple, cet article peut être identifié et téléchargé à l’aide d’une URL Uniform Resource Locator. Si vous ouvrez l'URL de cet article, votre client envoie une requête HTTP au serveur et reçoit les informations au format HTML. Une fois le transfert de données (au niveau de la couche transport via le protocole TCP) terminé, votre navigateur affichera la réponse reçue en code HTML pour afficher le texte que vous êtes en train de lire.

Fait historique : Le terme « hypertexte » a été utilisé pour la première fois par Ted Nelson en 1965 (projet Xanadu). HTTP et HTML ont été créés par Tim Berners-Lee et son équipe au CERN en 1989. D'ailleurs, le premier site a été publié le 6 août 1991.

Le protocole réseau prend en charge les sessions et l'authentification. Une session est une séquence ouverte de transactions demande-réponse via une connexion TCP vers un port spécifique. Le port 80 est utilisé pour HTTP et 443 pour les connexions HTTPS. HTTPS est HTTP sur SSL/TLS, ce qui signifie que la connexion de bout en bout est créée sur un canal crypté à l'aide du protocole cryptographique Transport Layer Security (TLS).

HTTP/1.0 et HTTP/1.1

Avant que HTTP/2 ne soit introduit comme standard, l’ancien protocole HTTP/1.1 était la norme officielle. HTTP/1.1 est une version améliorée de la version originale HTTP/1.0, officiellement introduite en 1996. La toute première version de HTTP/1.1 a été introduite en 1997, et une version améliorée et mise à jour a été publiée en 1999, puis à nouveau en 2014. La principale différence entre ces deux normes existantes est la prise en charge de plusieurs connexions dans une seule requête.

HTTP/1.0 ne prend en charge qu'une seule connexion par demande de ressource, tandis que HTTP/1.1 permet d'utiliser la même connexion plusieurs fois, c'est-à-dire Une connexion permanente est établie. Cela donne moins de latence et permet à un site Web moderne de se charger plus rapidement. La latence est le temps entre une requête (raison) et une réponse (résultat). Cette option a encore été améliorée dans HTTP/2, mais nous expliquerons plus tard les principaux avantages de la nouvelle norme.

EN SAVOIR PLUS SUR LES MÉTHODES DE DEMANDE HTTP

Un peu plus haut nous avons parlé des requêtes au serveur. HTTP définit plusieurs méthodes de requête qui peuvent être utilisées à différentes fins et actions sur une ressource spécifique. Les méthodes les plus courantes sont GET et POST, qui devraient vous être familières.

Lorsque vous appelez une URL en cliquant sur un lien classique, votre navigateur crée une requête GET. Vous pouvez voir les paramètres GET directement dans l'URL, par exemple ?id=42. Dans cet exemple, la variable GET est un identifiant d'une valeur de 42. Lorsque vous souscrivez au service en saisissant vos données dans le formulaire et en cliquant sur le bouton confirmer, votre client effectuera une requête POST. En plus de ces méthodes, HTTP prend en charge plusieurs autres méthodes qui ne sont généralement pas utilisées par le navigateur lors de la navigation sur Internet. Voici les méthodes :

• TÊTE(similaire à la méthode GET, mais sans corps de réponse),
• METTRE(modifie ou crée une ressource),
• SUPPRIMER(supprime la ressource),
• TRACER(demande d'écho),
• OPTIONS(renvoie les méthodes HTTP prises en charge),
• CONNECTER(convertit les requêtes en tunnel TCP/IP),
• CORRECTIF(applique les modifications à la ressource).

RÉPONSES HTTP ET CODES D'ÉTAT HTTP

Jetons un coup d'œil rapide aux réponses aux requêtes. La réponse du serveur après la requête contient non seulement le corps de la réponse et le code HTML permettant d'afficher la page chargée, mais également les champs d'en-tête de la réponse. Ces champs contiennent des informations et des paramètres importants sur la transaction HTTP sur la connexion établie, tels que l'algorithme de chiffrement utilisé ou le mécanisme de mise en cache. Par souci d'exhaustivité, il convient de noter que ces paramètres importants sont également envoyés dans les champs d'en-tête de la requête.

La première ligne d'une réponse HTTP contient toujours un code d'état qui aide le client à traiter correctement la réponse. Qui ne connaît pas le fameux message « Server Error 500 ». C'est ce code d'état 500 qui a été envoyé par le serveur au navigateur en raison de problèmes internes du serveur. Il existe plusieurs catégories principales, qui sont déterminées par le premier chiffre :

• 1 – informatif,
• 2 - réussi,
• 3 – réorientation,
• 4 – erreur client,
• 5 – erreur du serveur.

AVANTAGES DE HTTP/2

HTTP/2 prend en charge la plupart de la syntaxe de haut niveau de HTTP/1.1. Par exemple, les méthodes de demande ou les codes d'état sont les mêmes. Les changements les plus importants concernent la manière dont les paquets de données sont créés et transmis entre les nœuds.

Le serveur peut transmettre des données au client même si elles n'ont pas encore été demandées par le navigateur, mais elles sont nécessaires pour que le navigateur affiche entièrement la page. Des requêtes supplémentaires peuvent être multiplexées (les requêtes ou les réponses sont combinées) et acheminées (plusieurs requêtes sans attendre les réponses correspondantes) sur une seule connexion TCP. Ces améliorations réduisent la latence et conduisent à de meilleures vitesses de chargement des pages.
Alors, que faut-il pour commencer à profiter de HTTP/2 ? Le client et le serveur doivent comprendre et prendre en charge cette norme. À ce stade, tous les navigateurs modernes populaires prennent déjà en charge HTTP/2. Votre navigateur chargera automatiquement les pages Web via HTTP/2 si le serveur le prend en charge. (c'est-à-dire s'il est activé).

COMMENT ACTIVER HTTP/2 SUR MON SERVEUR ? UTILISEZ PLESK !

Configurer HTTP/2 est vraiment simple ! Comme toujours, Plesk a fait tout le travail pour vous pendant que vous vous détendez et prenez soin de votre entreprise. Si vous avez déjà Plesk sur votre serveur, il vous suffit de faire quelques clics pour activer la prise en charge d'une norme de mise en réseau moderne et rapide.

L'équipe Plesk a créé une extension de sécurité, Security Advisor, avec laquelle vous pouvez activer HTTP/2, ainsi qu'activer un certificat SSL et le support HTTPS en 1 clic dans WordPress. Ouvrez le répertoire des extensions Plesk et installez Security Advisor. L'extension est absolument gratuite et protégera non seulement votre site, mais l'accélérera également !