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.

Tout comme avec HTTP/2, HTTP/3 s'appuiera à nouveau sur ces réalisations pour aider à accélérer le Web. 🚀 Cliquez pour Tweet

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.

Utilisation du HTTP/2

Utilisation du HTTP/2

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.

Push HTTP/2

Push HTTP/2

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.

Pas de pipelining vs pipelining

Pas de pipelining vs pipelining (Source de l’image : Wikipedia, Author Mwhitlock)

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.

Compression HTTP/2 HPACK

Compression HTTP/2 HPACK

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.

Protocole Internet(RFC791)

Protocole Internet (Source de l’image : RFC791)

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.

Adoption d'IPv6

Adoption d’IPv6

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…

Internet Datagram Header

Internet Datagram Header (Source de l’image : RFC791)

Comprendre le rôle du TCP et UDP

Maintenant, il est temps d’explorer où HTTP/3 s’intègre avec TCP et UDP.

TCP

Alors que l’IP est la couche sous-jacente de toutes nos communications en ligne aujourd’hui, le TCP (Transmission Control Protocol) est une partie de plus haut niveau de la suite de protocoles Internet, fournissant la fiabilité nécessaire pour le Web, le courrier, le transfert de fichiers (FTP) – pour les couches d’applications/protocoles de l’Internet.

Cela comprend l’établissement d’une connexion à plusieurs étapes, l’ordre assuré des paquets et la retransmission des paquets perdus. Il fournit un feedback (Acks) de la livraison à l’expéditeur et ainsi de suite. Il y a aussi le calcul de la somme de contrôle pour détecter les erreurs.

Toutes ces choses indiquent un grand nombre d’étapes qui font de TCP un protocole fiable, ce qui en fait le fondement des services Internet les plus célèbres que nous utilisons aujourd’hui.

Ses spécifications remontant à 1974 (RFC 675) et 1981 (RFC 793) n’ont pas beaucoup changé à ce jour.

La fiabilité que fournit TCP n’est cependant pas sans coût. Les frais généraux de tous les allers-retours requis par les prises de contact, les retours de livraison, les commandes de garanties et les sommes de contrôle qui pourraient être considérés comme faibles et redondants. Il a fait de TCP un goulot d’étranglement de la pile de protocoles moderne. HTTP/2 a atteint un plateau d’améliorations de vitesse qui peuvent être réalisées sur TCP.

Changer le TCP de manière substantielle n’est pas une tâche simple, car le protocole fait partie de la pile TCP/IP qui remonte aux années 70. Cela est profondément ancré dans les systèmes d’exploitation, le micrologiciel de l’appareil, etc.

UDP

UDP (User Datagram Protocol) est également l’une des parties de la suite de protocole Internet, avec ses spécifications qui remontent à 1980 (RFC 768).

Il s’agit, comme son nom l’indique, d’un protocole sans connexion basé sur un datagramme. Ce qui signifie qu’il n’y a pas de prise de contact et qu’il n’y a aucune garantie de commande ou de livraison. Cela signifie que toutes les étapes possibles pour assurer la livraison, l’intégrité des données et d’autres choses sont laissées sur la couche application. Cela signifie qu’une application construite sur UDP peut choisir les stratégies qu’elle utilisera en fonction du cas concret, ou qu’elle peut éventuellement utiliser des éléments de la couche de lien, comme les sommes de contrôle, pour éviter les frais généraux.

Parce que l’UDP est répandu tout comme le TCP, il permet de réaliser des améliorations sans nécessiter de grands changements de firmware sur tous les appareils connectés à Internet, ni de changements significatifs dans les systèmes d’exploitation.

Le déploiement de nouveaux protocoles est entravé par de nombreux pare-feu, NATs, routeurs et autres middle-box qui n’autorisent que le déploiement TCP ou UDP entre les utilisateurs et les serveurs qu’ils doivent atteindre. – Explication de HTTP/3

Ce fil de discussion sur Hacker News peut nous aider à commencer à comprendre le raisonnement derrière la construction de la nouvelle version HTTP sur la pile réseau existante, plutôt que de la réinventer (bien qu’il y ait plus que cela).

La spécification du format de paquet UDP est plutôt minimale, son en-tête se compose du port source, du port de destination, de la longueur, en octets, de l’en-tête du paquet et des données du paquet et de la somme de contrôle. La somme de contrôle peut être utilisée pour vérifier l’intégrité des données tant pour l’en-tête que pour la partie données du paquet.

La somme de contrôle est facultative lorsque la couche de protocole sous-jacente est IPv4, et obligatoire avec IPv6. Jusqu’à présent, l’UDP a été utilisé pour des choses comme la synchronisation de l’horloge des systèmes informatiques (NTP), applications VoIP, le streaming vidéo, le système DNS et le protocole DHCP.

QUIC et HTTP/3

QUIC (Quick UDP Internet Connections) a été déployé pour la première fois par Google en 2012. Il redéfinit les limites des couches réseau en s’appuyant sur le protocole UDP de niveau inférieur, en redéfinissant les prises de contact, les fonctions de fiabilité et les fonctions de sécurité dans « l’espace utilisateur », ce qui évite d’avoir à mettre à niveau les noyaux des systèmes Internet.

HTTP/2 stack vs HTTP/3 stack

HTTP/2 stack vs HTTP/3 stack

Tout comme avec HTTP/2, une avancée qui a été menée par Google SPDY ou Speedy, HTTP/3 s’appuiera à nouveau sur ces réalisations.

Bien que HTTP/2 nous ait donné le multiplexage et atténué le blocage en tête de ligne, il est limité par TCP. Vous pouvez utiliser une seule connexion TCP pour plusieurs flux multiplexés ensemble pour transférer des données, mais lorsque l’un de ces flux subit une perte de paquets, toute la connexion (et tous ses flux) sont retenus en otage, pour ainsi dire, jusqu’à ce que TCP fasse son travail (retransmettre le paquet perdu).

Cela signifie que tous les paquets, même s’ils sont déjà transmis et en attente, sont bloqués dans le tampon du noeud de destination jusqu’à ce que le paquet perdu soit retransmis. Daniel Stenberg dans son livre sur http/3 appelle ça un « bloc de tête de ligne basé sur TCP ». Il affirme qu’avec 2% de perte de paquets, les utilisateurs feront mieux avec HTTP/1, avec six connexions pour couvrir ce risque.

QUIC n’est pas contraint par cela. Avec QUIC s’appuyant sur le protocole UDP connectionless, le concept de connexion n’a pas les limites de TCP et les échecs d’un flux n’ont pas à influencer le reste.

Comme l’a dit Lucas Pardue de Cloudflare :

Lucas Pardue sur HTTP/3

Lucas Pardue sur HTTP/3

En mettant l’accent sur les flux UDP, QUIC réalise le multiplexage sans avoir à utiliser une seule connexion TCP. QUIC construit sa connexion à un niveau plus élevé que TCP. Les nouveaux flux dans les connexions QUIC ne sont pas obligés d’attendre que les autres se terminent. Les connexions QUIC bénéficient également de l’élimination de la surcharge du handshake TCP, ce qui réduit la latence.

Les gens de Cisco ont fait une vidéo intéressante expliquant la prise de contact à 3 voies de TCP.

Alors que QUIC supprime les fonctions de fiabilité TCP, il compense par la couche UDP, en assurant la retransmission des paquets, la commande, etc. Google Cloud Platform a introduit le support QUIC pour ses load balancers en 2018 et a vu une amélioration du temps moyen de chargement des pages de 8% au niveau mondial, et jusqu’à 13% dans les régions où la latence est plus élevée.

Entre Google Chrome, YouTube, Gmail, la recherche de Google et d’autres services, Google a pu déployer QUIC sur une bonne partie d’Internet, sans attendre l’IETF. Les ingénieurs de Google affirment qu’en 2017, 7% du trafic Internet était déjà réalisé sur QUIC.

La version de QUIC de Google se concentrait uniquement sur le transport HTTP, en utilisant la syntaxe HTTP/2. Les gens de l’IETF (ceux en charge de la standardisation de QUIC), ont décidé que la version IETF de QUIC devrait être capable de transporter plus que seulement HTTP. Pour l’instant, cependant, tout travail sur les protocoles autres que le protocole HTTP sur QUIC est en suspens.

Le groupe de travail de l’IETF a également décidé que la version standardisée utilisera le cryptage TLS 1.3 au lieu de la solution personnalisée de Google. TLS 1.3, par rapport aux anciennes versions, contribue également à la vitesse du protocole, car ses prises de contact nécessitent moins d’aller-retour. Kinsta supporte le TLS 1.3 sur tous nos serveurs et notre CDN Kinsta.

Actuellement, Google continue d’utiliser sa propre version de QUIC dans son produit, tout en orientant ses efforts de développement vers les normes IETF. La plupart des autres acteurs de l’Internet s’appuient sur la version de l’IETF (les deux diffèrent sur d’autres aspects que le cryptage).

Si nous ouvrons Chrome Dev Tools et chargeons certains produits Google, comme Gmail, dans la colonne Protocole de l’onglet Réseau, nous verrons beaucoup de ressources chargées via la version Google du protocole QUIC. C’est également le cas pour les produits Google comme Analytics, Google Tag Manager, etc.

Service Google QUIC

Service Google QUIC

Cloudflare a récemment publié une mise à jour très complète sur les progrès de la normalisation.

Bien que le protocole UDP offre certains avantages inhérents au QUIC et au HTTP/3, il comporte aussi certains défis. TCP est le protocole courant depuis des années, alors que UDP ne l’est pas, de sorte que les systèmes d’exploitation et la pile logicielle n’est généralement pas aussi optimisée. Par conséquent, il y a beaucoup plus de charge/besoins CPU avec QUIC, selon certaines estimations, deux fois plus qu’avec HTTP/2.

Les optimisations vont en profondeur jusqu’au noyau des systèmes d’exploitation et aux différents routeurs et micrologiciels des appareils. Ce guide Red Hat Tuning peut apporter plus de lumière sur le sujet pour ceux qui sont plus enclins sur le plan technique.

Nous pourrions dire que QUIC tente de réinventer les fonctionnalités TCP en plus d’un protocole plus minimal et plus flexible.

Les connexions QUIC, que nous avons mentionnées plus haut, combinent le TLS et les poignées de main de transport. Une fois établis, ils sont identifiés par des CIDs uniques (ID de connexion). Ces IDs persistent à travers les changements d’IP et peuvent aider à sécuriser les téléchargements ininterrompus sur, par exemple, un passage de la 4G vers le WiFi. Cela est d’autant plus important que le trafic Internet est de plus en plus important sur les appareils mobiles. On peut se demander si cet élément est conçu par Google pour faciliter un meilleur suivi des utilisateurs entre les différentes connexions et les différents fournisseurs d’accès à Internet.

Le protocole TLS est obligatoire et vise à empêcher les périphériques situés au milieu d’altérer ou de snifer le trafic. C’est pourquoi il n’est pas rare de voir des fournisseurs de pare-feu comme Cisco voir le protocole UDP comme un problème, et de fournir des moyens de le désactiver. Il est plus difficile pour les intermédiaires d’inspecter et de superviser ou de filtrer le trafic QUIC.

Les flux QUIC sont envoyés via des connexions QUIC, unidirectionnelles ou bidirectionnelles. Les flux ont des IDs qui identifient l’initiateur et indiquent si le flux est unidirectionnel ou bidirectionnel, et servent également au contrôle du débit dans le flux.

Alors que QUIC est un protocole de couche de transport, HTTP est la couche supérieure, un protocole de couche d’application, ou protocole d’application.

Comme la rétrocompatibilité est de la plus haute importance, l’IETF a encouragé la mise en œuvre de HTTP/3 en incluant l’ancienne version (HTT1 ou HTTP/2) dans la réponse. Il comprendra un en-tête qui informe le client que HTTP/3 est disponible, ainsi que des informations sur le port/hôte, comme décrit dans la RFC 7838.

C’est différent de HTTP/2, dans lequel le transport peut être négocié dans le cadre de la prise de contact TLS. Mais comme l’IETF a pratiquement adopté le protocole HTTP/3 basé sur QUIC comme norme suivante, nous pouvons nous attendre à ce que les clients Web anticipent de plus en plus le support de HTTP/3. Il est possible pour les clients de mettre en cache les données des connexions HTTP/3 précédentes, et de se connecter directement (zero-round-trip, ou 0-RTT) lors de visites ultérieures sur le même hébergeur.

Résumé

Il y a ceux qui pensent qu’avec l’adoption incomplète de la norme HTTP/2, il est peut-être trop tôt pour faire pression en faveur de HTTP/3 (version trois). C’est un point valable, mais, comme nous l’avons mentionné, ce protocole a déjà fait l’objet d’essais et de mises en œuvre à grande échelle. Google a commencé à le tester dès 2015, ainsi que Facebook en 2017.

Depuis lors, d’autres acteurs se sont joints aux efforts de normalisation, tels qu’Akamai et Mozilla. Lors du dernier hackathon de l’IETF en novembre 2018, la liste des participants a montré de l’intérêt pour QUIC par des entreprises telles que Facebook, Apple, Google, Mozilla, NetApp, et LiteSpeed Tech. Il y a eu quelques tests prometteurs, et il semble que LiteSpeed pourrait être le premier grand fournisseur de serveurs avec un serveur HTTP/3 fonctionnel. Cloudflare est également en cours d’exécution de QUIC en version bêta.

Peu de temps après, QUIC a été renommé en HTTP/3 dans l’Internet Draft de l’IETF. Il expirera à la fin juin 2019, et nous pouvons nous attendre à ce que le RFC, ou la norme finale, soit adopté en juillet.

Cette année sera passionnante, car nous pouvons nous attendre à ce que les principaux fournisseurs de logiciels adoptent la nouvelle norme.

Quand HTTP/3 sera-t-il disponible chez Kinsta ?

Une fois la RFC finalisée (été 2019) et que Nginx supporte officiellement QUIC, vous pouvez garantir que l’équipe Kinsta sera sur le coup ! Lorsque ce sera prêt pour la production, nous le déploierons.

10
Partages