HTTP/3 est le prochain protocole de communication réseau sur le Web, qui est destiné à remplacer partiellement HTTP/1 et HTTP/2. Un mois avant la prochaine réunion du groupe de travail QUIC, qui se tiendra à Zurich en février prochain, il peut être utile de récapituler les promesses de HTTP/3 et à quoi ressemble son support client/serveur actuel.
HTTP/3 promet de rendre les connexions Internet plus rapides, plus fiables et plus sécurisées. Né sous le nom de "HTTP over QUIC", un effort pour adapter le protocole HTTP afin qu'il s'exécute au-dessus du protocole de couche de transport de Google, QUIC, il a été plus tard proposé comme norme IETF et il s'agit actuellement d'un Internet Draft. En octobre 2018, le coprésident des groupes de travail IETF HTTP & QUIC Mark Nottingham a proposé de renommer HTTP over QUIC en HTTP/3 pour clarifier sa vraie nature et son indépendance vis-à-vis de QUIC.
QUIC est un élément clé de HTTP/3, car il fournit les bases de ses principales fonctionnalités. Construit sur UDP, QUIC tente de résoudre les principaux problèmes rencontrés lors de l'utilisation du protocole TCP, à savoir la latence d'établissement de connexion et la gestion de plusieurs flux en présence de perte de paquets. Le problème de latence TCP provient des exigences de son algorithme de contrôle de congestion, qui exige un démarrage lent pour évaluer la quantité de trafic pouvant être envoyée avant la congestion. Cela aggrave, dans HTTP/1.0, le fait que chaque échange de requête/réponse TCP se voit attribuer une nouvelle connexion, encourant ainsi la pénalité d'un démarrage lent.
Depuis lors, la tentative de contourner le démarrage lent de TCP a été au cœur des efforts successifs pour améliorer le protocole HTTP.
HTTP/1.1 a introduit les connexions persistantes "keep-alive" pour permettre de séquencer plusieurs échanges requête-réponse sur la même connexion TCP, ne nécessitant ainsi pas de nouvelle phase d'établissement de connexion pour chaque demande. Les connexions persistantes HTTP/1.1, cependant, ne prennent pas en charge l'envoi de plusieurs demandes en même temps, ce qui a de nouveau entraîné un goulot d'étranglement en raison de la complexité croissante des pages Web.
HTTP/2, basé sur le protocole SPDY désormais obsolète a introduit le concept de first-class streams embarqué dans la même connexion. Cela a permis des échanges simultanés de requête-réponse mais avec un défaut majeur : lorsque la perte de paquets augmente, les performances HTTP/2 se dégradent en raison de la façon dont TCP traite la retransmission des paquets, qui finit par les affecter également, c'est-à-dire l'arrêt de tous les flux partageant la même connexion. Lorsque la perte de paquets dépasse un seuil donné, paradoxalement, plusieurs connexions HTTP/1 fonctionnent plus efficacement que HTTP/2.
Comme mentionné, QUIC a des first-class streams, ce qui résout la latence de démarrage lent de la connexion comme cela se produit dans HTTP/2. De plus, il les gère séparément les uns des autres, ce qui résout les problèmes de performances dus à la perte de paquets. L'adoption de QUIC comme protocole de couche transport est la plus grande étape entre HTTP/2 et HTTP/3. Étant donné que QUIC implémente nativement un certain nombre de fonctionnalités liées à la gestion des flux qui faisaient partie intégrante de la spécification HTTP/2, celles-ci pourraient être supprimées de HTTP/3. De plus, l'adoption de QUIC a nécessité la création d'un nouveau schéma de compression d'en-têtes HTTP, QPACK, car la compression d'en-têtes HTTP/2 HPACK est fortement dépendant de l'ordre dans lequel TCP livre les paquets aux enpoints.
Depuis plusieurs années, Google utilise QUIC pour ses propres services, y compris la recherche, YouTube et d'autres, et l'a également pris en charge dans Chrome. Pendant un certain temps, Chrome était le seul moyen d'utiliser QUIC lors de la communication avec les services Google le prenant en charge. Récemment, Mozilla a également ajouté la prise en charge de HTTP/3 dans Firefox 72, bien que expérimentale. L'outil de ligne de commandes curl a également ajouté la prise en charge de HTTP/3 dans la version 7.66.0, ainsi que de nombreuses fonctionnalités supplémentaires. Côté serveur, HTTP/3 est pris en charge par LightSpeed et Nginx.
Sur le cloud, outre Google, Cloudflare a annoncé il y a quelques mois qu'il avait préalablement activé HTTP/3 pour une partie de ses clients. Cloudflare est également l'entreprise derrière Quiche, une bibliothèque Rust open-source permettant l'implémentation de clients et serveurs HTTP/3.
Comme mentionné, HTTP/3 est toujours en cours de définition par l'IETF, sans date de sortie officielle fixée pour le moment. Parallèlement, l'adoption de HTTP/3 se développe dans le monde entier, avec près de 300 000 services l'utilisant à travers le monde. Google est toujours en tête des organisations à déployer HTTP/3, mais plusieurs autres prennent une part non négligeable. InfoQ continuera à fournir des informations sur HTTP/3 pour tenir nos lecteurs au courant de l'évolution d'Internet.