qu est-ce que HTTP sur 3 ? En novembre 2018, l’Internet Engineering Task Force (IETF) s’est réunie à Bangkok et un nouveau projet Internet a été adopté. Le protocole de transport QUIC, le successeur de HTTP/2, a été renommé en HTTP/3. HTTP/3 s’appuie sur UDP et est déjà utilisé par d’importantes sociétés Internet telles que Google et Facebook. Si vous utilisez Chrome et vous connectez à un service Google, vous utilisez probablement déjà QUIC.

La nouvelle version du protocole HTTP bénéficie du bare-metal, du protocole UDP low-level, et définit un grand nombre des nouvelles fonctionnalités qui se trouvaient dans les versions précédentes du protocole HTTP sur la couche TCP. Cela permet de résoudre les contraintes au sein de l’infrastructure Internet existante.

Les premiers résultats sont prometteurs, et lorsque le projet Internet de l’IETF expirera, en juin 2019, on peut s’attendre à ce que HTTP/3 soit présenté comme une nouvelle norme HTTP de troisième génération.

HTTP/3 arrive

Certains disent que la soif de vitesse et de latence de l’industrie du web n’a d’égal que la soif de Google Chrome pour plus de RAM.

En 2016, nous avons publié un article sur HTTP/2, une norme qui, selon W3Techs, a actuellement un taux d’adoption mondial d’environ 34%. Et selon Can I use, il est également supporté par tous les navigateurs web modernes. Pourtant, nous voici en train d’écrire un article sur la prochaine version du protocole, HTTP/3.

HTTP/3 est, au moment de la rédaction de cet article, un Internet-Draft ou ID de l’IETF, ce qui signifie qu’il est actuellement à l’étude pour une future norme Internet par l’Internet Engineering Task Force – un organisme international de normalisation Internet, chargé de définir et de promouvoir des normes de protocole Internet approuvées, comme TCP, IPv6, VoIP, Internet des objets, etc.

Il s’agit d’un organisme ouvert qui réunit l’industrie du web et facilite la discussion sur l’orientation de l’internet.

Actuellement, la phase ID de HTTP/3 est la dernière phase avant que les propositions ne soient promues au niveau des RFCs, ou demandes de commentaires, que nous pouvons considérer, à toutes fins utiles, comme une définition officielle du protocole Internet. Ils sont mis en œuvre par tous les principaux acteurs de l’Internet.

Cela signifie que HTTP/3 deviendra une norme officielle lorsque le projet expirera plus tard cette année (juin 2019).

Retour en arrière – Ça a commencé avec HTTP/2

Chez Kinsta, nous sommes obsédés par l’idée d’extraire jusqu’à la dernière milliseconde de notre pile, qu’il s’agisse de tirer parti de la toute dernière version de PHP, de fournir des données sur le réseau Premium de Google Cloud Platform ou de mettre en cache des ressources sur notre réseau CDN HTTP/2.

HTTP/2 a apporté de sérieuses améliorations avec des téléchargements non bloquants, des pipelines et les serveurs push qui nous ont aidé à surmonter certaines limitations du protocole TCP sous-jacent. Cela nous a permis de réduire au minimum le nombre de cycles de requêtes-réponses.

HTTP/2 permettait de pousser plus d’une ressource dans une seule connexion TCP – le multiplexage. Nous avons également obtenu plus de flexibilité dans l’ordre des téléchargements statiques, et nos pages ne sont maintenant plus limitées par une progression linéaire des téléchargements.

En pratique, cela signifie qu’une ressource javascript importante n’équivaut pas nécessairement à un point d’étranglement pour toutes les autres ressources statiques qui attendent leur tour.

Ajoutez à cela la compression HPACK de l’en-tête HTTP/2 et le format binaire par défaut du transfert de données, et nous avons, dans de nombreux cas, un protocole beaucoup plus efficace.

Les implémentations majeures de navigateurs ont rendu nécessaire l’implémentation du cryptage – SSL – pour pouvoir bénéficier des avantages de HTTP/2 – et parfois cela a entraîné un surcoût de calcul qui a rendu les améliorations de vitesse imperceptibles. Il y a même eu des cas où les utilisateurs ont signalé un ralentissement après la transition vers HTTP/2.

Disons simplement que les premiers jours de l’adoption de cette version n’étaient pas pour les cœurs fragiles.

L’implémentation de NGINX ne disposait pas non plus de la fonction de push serveur, s’appuyant sur un module. Et les modules NGINX ne sont pas les modules Apache habituels que vous pouvez simplement copier – NGINX doit être recompilé avec ceux-ci.

Bien que certains de ces problèmes soient maintenant résolus, si nous regardons l’ensemble de la pile de protocoles, nous constatons que la contrainte principale se situe à un niveau inférieur à celui que HTTP/2 a osé tenter.

Pour élaborer ceci, nous allons disséquer la pile de protocole Internet d’aujourd’hui de sa couche inférieure vers le haut. Si vous voulez en savoir plus sur l’arrière-plan de HTTP/2, n’hésitez pas à consulter notre guide HTTP/2 ultime.

Protocole Internet (IP)

Le protocole Internet (IP) définit la partie inférieure de toute la topologie Internet. C’est la partie de la pile Internet qui n’est, nous pouvons le dire, vraiment pas négociable sans tout changer, y compris le remplacement de toute l’infrastructure matérielle, des routeurs aux serveurs et même aux machines des utilisateurs finaux.

Ainsi, bien que la révision du protocole soit peut-être due, une entreprise d’une telle envergure n’est pas à l’horizon en ce moment, principalement parce que nous n’avons pas encore trouvé une solution de rechange viable, révolutionnaire, mais compatible avec le passé.

En dessous, il y a une couche de liaison – la partie du protocole qui est pour ainsi dire « bare metal ».

D’autre part, la rapidité avec laquelle les créateurs d’IPFS (système de fichiers interplanétaires) sont parvenus à clôturer un financement de l’OIC qui leur a permis de gagner 250 millions de dollars en un mois est un exemple convaincant d’une refonte complète.

Les débuts du protocole IP remontent à 1974, avec un article publié par l’Institute of Electrical and Electronics Engineers et rédigé par Vint Cerf et Bob Cahn. Il détaille les paquets envoyés sur un réseau, les achemine à travers les adresses IP et les adresses numériques définies des nœuds d’un réseau/réseaux. Le protocole définissait le format de ces paquets, ou datagrammes – ses en-têtes et sa charge utile.

Après la définition de la RFC 760 de 1980, l’IETF a adopté la définition largement utilisée à ce jour, dans sa Demande de Commentaires 791. C’est la quatrième version du protocole, mais on peut dire qu’il s’agit de la première version en production.

Il utilise des adresses 32 bits, ce qui limite le nombre d’adresses à environ 4 milliards. Cette limitation explique le mystère de savoir pourquoi les internautes non professionnels obtiennent des « adresses IP dynamiques » de la part de leur FAI, et une IP statique est considérée comme une « valeur ajoutée » et souvent soumise à des frais supplémentaires.

Ils sont en train de rationner.

Il n’a pas fallu longtemps avant que l’on se rende compte que les adresses 32 bits ne suffisaient pas et que la pénurie était imminente, de nombreux RFCs ont donc été publiés pour tenter d’y remédier. Bien que ces solutions soient largement utilisées aujourd’hui et qu’elles fassent partie de notre vie quotidienne, on peut probablement dire sans risque de se tromper qu’elles sont très populaires.

Le protocole Internet version 6 ou IPv6 est venu comme un moyen d’aborder ces limitations, y compris d’être progressivement adopté par rapport à la version précédente. Il est devenu un projet de norme pour l’IETF en 1998 et a été élevé au rang de norme Internet en 2017.

Alors que l’espace adresse IPv4 était limité par sa longueur d’adresse de 32 bits, la norme IPv6 était de 128 bits, soit 3,4 * 10 ^ 38 adresses possibles. Cela devrait suffire à nous faire durer un certain temps.

Selon Google et la connectivité IPv6 parmi ses utilisateurs, l’adoption d’IPv6 est légèrement supérieure à 25 % en mars 2019.

L’IP est une couche rudimentaire de la pile Internet, définissant la plupart des choses de base, sans garantie de livraison, d’intégrité des données, ou de commande des paquets transmis. À lui seul, il n’est pas fiable. Le format d’en-tête d’IPv4 fournit la somme de contrôle d’en-tête que les nœuds de transmission utilisent pour vérifier l’intégrité de l’en-tête. Cela le rend différent de la version IPv6, qui s’appuie sur la couche de liaison en dessous, ce qui lui permet d’être plus rapide…