Quand avez-vous commencé à accéder à l’internet ? Si c’était après 1999, vous utilisez le même protocole que celui que vous utilisez actuellement pour accéder aux pages web, HTTP/1.1. Après 16 ans sans mises à jour majeures, le 18 février dernier, l’Internet Engineering Steering Group (IESG), l’organe responsable des révisions techniques des normes Internet, a approuvé HTTP/2. Mais qu’est-ce que c’est ? Et quelle différence cela fera-t-il dans votre vie ?
Nous allons vous expliquer.
Sommaire
Qu’est-ce que le HTTP ? Comment se nourrit-elle ? Comment cela se passe-t-il ?
L’Internet est formé de quelques couches (quatre ou sept, selon votre religion). La plus proche de vous est la couche application, qui rassemble les protocoles pour des fonctions spécifiques. Vous avez IMAP, que votre client de messagerie utilise pour télécharger vos messages ; NTP, qui maintient l’horloge de votre ordinateur synchronisée ; FTP, pour télécharger et envoyer des fichiers ; BitTorrent, utilisé pour télécharger ? des distributions Linux ; et bien d’autres encore.
HTTP est un protocole développé à l’origine pour distribuer du contenu hypertexte, c’est-à-dire du texte hyperlié qui peut vous conduire à d’autres textes hyperliés. Vous utilisez HTTP tous les jours pour accéder à des pages web, et il est tellement omniprésent que votre navigateur n’affiche probablement plus http:// dans la barre d’adresse comme c’était le cas auparavant.
La première version de HTTP que nous connaissons est o HTTP/0.9, publiée en 1991, qui n’était utilisée que pour transférer du texte d’un serveur à votre ordinateur. En 1996, lorsque l’Internet commercial a été branché en France, le HTTP/1.0 a été finalisé. Parmi les nouveautés, on peut citer la possibilité d’inclure d’autres types de fichiers sur une page, comme des images (wow !) et la nouvelle méthode POST, pour permettre aux utilisateurs non seulement de recevoir, mais aussi d’envoyer des informations à un serveur, comme des termes de recherche dans un moteur de recherche et des messages sur les réseaux sociaux.
Le protocole que la plupart des sites utilisent aujourd’hui est le HTTP/1.1, publié en 1999. Il a permis au web de continuer à se développer en résolvant certains problèmes HTTP/1.0, comme la forte utilisation des données. Avec le nouveau HTTP/1.1, les pages pouvaient être compressées par les serveurs et décompressées par l’ordinateur de l’utilisateur. Ainsi, il serait possible de télécharger une page plus rapidement avec un étonnant modem de pointe de 28 800 bits par seconde.
Si HTTP/1.1 fonctionne, pourquoi avez-vous inventé une autre version ?
En fait, tout comme cela s’est produit lors de la transition de HTTP/1.0 à HTTP/1.1, la version actuelle du protocole commence à montrer des signes de fatigue. Les pages web sont devenues beaucoup plus lourdes ces dernières années, intégrant de plus en plus d’images, de vidéos et d’autres éléments externes tels que des polices personnalisées et des fichiers CSS et JavaScript.
Le problème d’une page comportant de nombreux éléments est que HTTP/1.1 est un protocole séquentiel : votre navigateur ouvre une connexion, demande un fichier au serveur du site, reçoit le fichier et ne demande qu’ensuite un autre fichier. Pour minimiser cette perte de temps, les navigateurs ouvrent généralement plusieurs connexions (entre quatre et huit) par serveur. Ainsi, le navigateur peut télécharger plusieurs éléments en même temps et accélérer le chargement de la page.
Mais comme la plupart des pages incorporent des éléments provenant de plusieurs serveurs (vidéos sur YouTube, polices sur Google et images sur un serveur cache, par exemple), cela signifie que votre navigateur peut finir par ouvrir des dizaines de connexions juste pour charger une page. Il est évident que cette congestion et cette monopolisation de l’utilisation du réseau nuisent à d’autres applications, telles que les connexions VoIP ? c’est pourquoi vous fixez une limite de connexion dans votre client torrent.
De plus, l’ouverture de nouvelles connexions à tout moment signifie que votre navigateur doit toujours faire des négociations. Pour chaque demande de fichier, le serveur du site et votre navigateur échangent des en-têtes, qui incluent le user-agent, avec la version de votre navigateur et votre système d’exploitation, par exemple. Certaines de ces informations ne changent pas à tout moment, de sorte qu’il y a beaucoup de trafic gaspillé sur des pages comportant de nombreux éléments en HTTP/1.1.
Par conséquent, le principal problème que o HTTP/2 tente de résoudre est celui des connexions multiples.
Qu’est-ce qui a changé avec HTTP/1.1 ? Et pourquoi les sites deviendront-ils plus rapides ?
“Cela change beaucoup, mais tout reste pareil”, plaisante Alex Soares, architecte principal de l’innovation chez Exceda, une société qui propose des services d’accélération et de distribution de contenus sur Internet. “Le protocole HTTP/1.1 est entièrement textuel. Vous pouvez vous connecter au serveur manuellement, taper du texte et faire ce que vous voulez. Il a été développé pour un vieux web. HTTP/2 est un protocole binaire, conçu pour être compris par des machines, et non plus par des personnes. Par conséquent, il est plus efficace et apporte des avantages qui règlent les problèmes actuels du web”.
Dans HTTP/1.1, le navigateur ouvre une connexion pour télécharger un seul fichier. Si cette connexion reste occupée pendant une longue période, soit parce que le fichier est trop volumineux, soit parce que le serveur est lent à répondre, le chargement de la page se bloque simplement au milieu du processus. Il existe des moyens d’atténuer ce problème en ouvrant de multiples connexions, mais ce n’est qu’un alambic, pas une solution.
HTTP/2 utilise le multiplexage, un nom compliqué pour dire que le navigateur ouvre une seule connexion pour télécharger plusieurs fichiers. Les demandes et les réponses sont parallèles et asynchrones : votre navigateur demande plusieurs fichiers en même temps et les reçoit dès qu’ils sont prêts, sur la même connexion. Mais que se passe-t-il si une image sur la page, par exemple, est trop lourde ? Pas de problème : sur la même connexion, vous pouvez mélanger les données, en recevant une partie de l’image, puis un fichier totalement différent et enfin le reste de l’image qui manquait. Sensationnel, non ?
Une autre nouveauté de HTTP/2 est ce que l’on appelle un serveur “push”. Si vous regardez le code source de PerlmOl, vous verrez qu’il y a un certain nombre d’appels à des éléments externes, tels que des fichiers CSS et JS. En HTTP/1.1, votre navigateur doit d’abord demander la page, lire le code source HTML, interpréter qu’il y a des appels à des éléments externes, puis demander ces éléments.
Seul, avec HTTP/2, le serveur sera en mesure d’envoyer ces éléments avant que votre navigateur ne les demande. Ainsi, dès que votre navigateur demandera notre index.html, le serveur pourra répondre avec index.html, style.css, tb.css, jquery.js et favicon.png. Le temps que votre navigateur se rende compte que vous devez utiliser ces fichiers pour rendre la page, ils seront sur votre ordinateur, prêts à être utilisés. C’est plus efficace et tout le monde est content.
Mais le serveur push ne pourrait-il pas provoquer des failles de sécurité dans les navigateurs en raison du téléchargement de fichiers à l’avance, dont certains potentiellement dangereux ? “Non, car il s’agira d’une connexion pré-établie. Toutes les demandes proviennent du client. Le serveur “push” est uniquement destiné à accélérer le rendu de la page”, explique M. Soares.
De plus, en HTTP/2, les en-têtes seront compressés avec un format appelé HPACK. Chaque fois que votre navigateur demande un fichier, il doit télécharger l’en-tête de ce fichier, qui peut contenir la taille du fichier, des informations sur le serveur et un cookie. En général, un en-tête ne fait que 1 Ko, mais imaginez que cela se multiplie par des dizaines de fichiers ? Avec la compression des en-têtes, l’utilisation des données sera moins ? et les pages se chargeront plus rapidement, bien sûr.
Sur le plan commercial
Outre l’amélioration de l’expérience utilisateur, HTTP/2 devrait également apporter des avantages aux entreprises. “Avec toutes les nouvelles optimisations techniques, les entreprises vont mieux utiliser les infrastructures en général. Cela permettra un meilleur retour sur investissement des équipements actuels et assurera la survie des appareils utilisés”.
“Il est intéressant qu’ils [les professionnels qui travaillent sur le web] commencent à chercher si leurs fournisseurs ont déjà des plans pour soutenir HTTP/2. Vérifiez si l’application doit être modifiée et si les fournisseurs prennent déjà en charge la technologie. Cela permettra au site de supporter HTTP/2 lorsque le protocole sera ratifié, ce qui, je pense, se produira en avril ou mai”.
Et quand pourrai-je l’utiliser ?
Les spécifications HTTP/2 ont été finalisées en février et sont en cours de transmission pour devenir une norme.
L’Internet Explorer de Windows 10 Technical Preview est maintenant prêt pour HTTP/2. Google a annoncé que Chrome va obtenir le soutien de HTTP/2 dans les prochaines semaines ? HTTP/2 apporte quelques idées de SPDY, un protocole que Google a commencé à développer en 2009 pour accélérer le web ; en raison de la nouvelle norme, SPDY sera abandonné. Mozilla teste HTTP/2 dans Firefox depuis la version 34.
Du côté des serveurs, tout se passe bien aussi. Apache et o nginx comprennent déjà un support expérimental pour HTTP/2 basé sur le projet de spécifications publié en 2014. L’IIS de Microsoft prend en charge le protocole HTTP/2 dans l’aperçu technique de Windows 10.
L’adoption de la nouvelle version du protocole devrait se faire au cours des prochains mois et des prochaines années ? la migration se fera petit à petit, et nous vivrons certainement longtemps avec des sites HTTP/1.1 et HTTP/2 côte à côte. Comme les principaux navigateurs et serveurs sont déjà préparés ou en passe de l’être pour HTTP/2, il ne devrait pas falloir longtemps pour dominer l’internet. Nos relations sont appréciées.
