L'état de HTTP en 2022

Âgé de plus de trente ans, le protocole HTTP demeure la fondation du web et l'un des protocoles les plus populaires d'Internet ; non seulement pour naviguer, regarder des vidéos et écouter de la musique, mais également pour les applications, la communication entre machines –et même comme base pour le développement d'autres protocoles formant ce que certains appellent la « deuxième ceinture » sur le diagramme classique représentant Internet sous la forme d'un sablier.

À quoi HTTP doit-il son succès ? L'une des réponses est qu'il représente un « point d'équilibre » pour la plupart des applications nécessitant un protocole d'application. Le document « Building Protocols with HTTP » (publié en 2022 dans la série Best Current Practice RFC par HTTP Working Group) affirme que le succès du protocole HTTP peut être attribué à des facteurs tels que les suivants :

- Sa connaissance par les ingénieurs d'application, les spécificateurs, les administrateurs, les développeurs et les utilisateurs ;- La disponibilité de différentes mises en œuvre pour clients, serveurs et proxys ;- Sa simplicité d'utilisation ;- La disponibilité des navigateurs web ;- La réutilisation de mécanismes existants, tels que l'authentification et le chiffrement ;- La présence de serveurs et de clients HTTP dans les déploiements cibles ; et- La capacité à franchir les pare-feu.

Un autre facteur important est la communauté de personnes qui utilisent, mettent en œuvre et normalisent HTTP. Nous travaillons ensemble à la maintenance et au développement actifs du protocole, afin d'assurer son interopérabilité et de répondre aux besoins actuels. Si HTTP stagne, un autre protocole le remplacera (à juste titre), et nous perdrons tout l'investissement, la compréhension partagée et l'interopérabilité de la communauté.

À cette fin, Cloudflare et de nombreux autres invitent leurs ingénieurs à participer à l'initiative IETF, où sont examinés et normalisés la plupart des protocoles Internet. Nous assistons et parrainons également des événements communautaires, tels que HTTP Workshop, lors desquels nous discutons des problèmes que rencontrent les personnes, de leurs besoins et de la compréhension des changements qui pourraient les aider.

Alors, quels ont été les fruits de tous ces réunions de groupes de travail, documents de spécification et événements parallèles en 2022 ? Que font les ingénieurs d'application et de déploiement du protocole du web ? Et quelles nouveautés nous attendent ensuite ?

Sur le plan des spécifications, la publication de HTTP/3 a été l'événement le plus marquant de 2022 : elle représente une avancée considérable pour répondre aux exigences des applications et des sites modernes, promouvant une utilisation plus efficace du réseau pour débloquer les performances du web.

Il y a bien longtemps, dans les années 90, les protocoles HTTP/0.9 et HTTP/1.0. établissaient une nouvelle connexion TCP pour chaque requête, ce qui représentait une utilisation incroyablement inefficace du réseau. HTTP/1.1 a introduit les connexions persistantes (qui ont été rétroportées dans HTTP/1.0, avec l'en-tête « Connection: Keep-Alive »). Cette amélioration a aidé les serveurs et le réseau à faire face à l'explosion de la popularité du web ; même à l'époque, toutefois, la communauté savait qu'elle comportait des restrictions problématiques, notamment le blocage de tête de ligne (qui survient lorsqu'une requête en attente sur une connexion empêche le traitement des autres requêtes).

Cela avait peu d'importance dans les années 90 et au début des années 2000, mais les pages et applications web actuelles imposent au réseau des exigences face auxquelles ces restrictions grèvent sévèrement les performances. Les pages comportent souvent des centaines de ressources qui se disputent toutes les ressources du réseau, et HTTP/1.1 n'était pas à la hauteur de la tâche. Après quelques faux départs, la communauté a finalement remédié à ces problèmes avec HTTP/2, en 2015.

Cependant, la suppression du blocage de tête de ligne dans HTTP a révélé le même problème une couche plus bas, dans le protocole TCP. Le protocole TCP étant un protocole de livraison fiable et ordonné, la perte d'un seul paquet dans un flux peut bloquer l'accès aux paquets suivants, même s'ils se trouvent dans les tampons du système d'exploitation. Cela s'est avéré être un vrai problème lors du déploiement de HTTP/2, notamment sur les réseaux non optimaux.

La réponse, bien sûr, consistait à remplacer TCP, le vénérable protocole de transport sur lequel est bâti une immense partie de l'Internet. Au terme de maintes discussions et de nombreux projets au sein de l'initiative QUIC Working Group, la version 1 de QUIC a été publiée afin d'acter ce remplacement, en 2021.

HTTP/3 est la version de HTTP qui utilise QUIC. Si le groupe de travail l'a effectivement finalisé en 2021, en même temps que QUIC, sa publication a été reportée à 2022, afin de correspondre à celle d'autres documents (voir ci-dessous). 2022 a également été une année importante dans le déploiement de HTTP/3, puisque Cloudflare a constaté une adoption et une confiance croissantes dans le nouveau protocole.

Bien que quelques années seulement se soient écoulées entre HTTP/2 et HTTP/3, la communauté ne semble aujourd'hui guère encline à travailler sur HTTP/4. QUIC et HTTP/3 sont tous deux nouveaux, et le monde apprend encore comment mettre en œuvre ces protocoles, les exploiter et créer des sites et des applications qui les utilisent. Bien que nous ne puissions exclure l'éventualité d'une limitation qui nécessiterait une nouvelle version à l'avenir, l'IETF a élaboré ces protocoles sur la base d'une vaste expérience sectorielle des réseaux modernes, et ils offrent une capacité d'extension considérable, qui facilitera d'éventuelles modifications nécessaires.

L'autre événement marquant concernant les spécifications de HTTP en 2022 a été la publication des documents « Core », qui constituent la fondation de la spécification de HTTP. Ces documents incluent les publications suivantes : HTTP Semantics – les aspects tels que les méthodes, les en-têtes, les codes d'état et le format des messages ; HTTP Caching – le fonctionnement du cache HTTP ; HTTP/1.1 – la mise en œuvre concrète de la sémantique, dans le format que nous connaissons et aimons tous.

Par ailleurs, les documents relatifs à HTTP/2 ont été republiés, afin de s'intégrer correctement au contexte de la publication HTTP Semantics et de corriger quelques problèmes restés en suspens.

Il s'agit de la dernière d'une longue série de révisions de ces documents. Dans le passé, nous avons eu la série RFC 723x, les publications RFC 2616 (peut-être la plus connue) et RFC 2068, ainsi que l'aïeule toutes ces publications, RFC 1945. Chaque révision a eu pour but d'améliorer la lisibilité, de corriger les erreurs, de mieux expliquer les concepts et de clarifier le fonctionnement du protocole. Les fonctionnalités incorrectement spécifiées (ou mises en œuvre) sont dépréciées, tandis que de nouvelles fonctionnalités permettant d'améliorer le fonctionnement du protocole sont ajoutées. Pour plus de détails, consultez l'annexe « Changes from... » de chaque document. Et surtout, reportez-vous toujours aux dernières révisions indiquées ci-dessus ; les publications RFC précédentes sont désormais obsolètes.

HTTP/2 incluait server push, une fonctionnalité conçue pour permettre aux serveurs de « pousser » une paire requête/réponse vers un client lorsqu'ils savaient que celui-ci allait avoir besoin de données, afin d'éviter la pénalité de latence liée à l'envoi d'une requête et l'attente de la réponse.

Après la finalisation de HTTP/2 en 2015, Cloudflare et de nombreuses autres mises en œuvre de HTTP ont rapidement déployé server push, en espérant constater d'importants gains de performance. Malheureusement, cela s'est avéré plus difficile qu'attendu : server push exige effectivement que le serveur prédise l'avenir – pas uniquement les requêtes qu'enverra le client, mais également les conditions du réseau. Et, lorsque le serveur se trompe (« over-pushing »), les requêtes « poussées » se trouvent directement en concurrence avec les requêtes légitimes provenant du navigateur. Cela représente un coût d'opportunité considérable et peut réellement grever les performances, au lieu de les améliorer. L'impact est aggravé lorsque le navigateur possède déjà une copie des données en cache et n'a donc pas du tout besoin des informations « poussées ».

Par conséquent, Chrome a supprimé HTTP/2 server push en 2022. D'autres navigateurs et serveurs le prennent peut-être encore en charge, mais la communauté semble convenir qu'à l'heure actuelle, la fonction est uniquement adaptée à des utilisations spécialisées, telles que le protocole Web Push, spécifique aux notifications de navigateur.

Cela ne signifie pas pour autant que nous renonçons. Le code d'état 103 (Early Hints) a été publié sous forme « d'Experimental RFC » par le groupe de travail HTTP en 2017. Il permet à un serveur d'envoyer des « hints » (indices) au navigateur dans une réponse non finale, avant la « vraie » réponse finale. C'est une fonctionnalité utile si vous savez que le contenu va inclure certains liens vers des ressources récupérées par le navigateur, mais vous avez besoin de plus de temps pour transmettre la réponse au client (parce que sa génération demande plus de temps ou parce que le serveur doit aller la récupérer ailleurs, comme dans le cas d'un réseau CDN).

Early Hints peut être utilisé dans de nombreuses situations pour lesquelles server push a été conçu – par exemple, lorsqu'une page doit charger des fichiers CSS et du code JavaScript. En théorie, les codes Early Hints ne sont pas aussi optimaux que server push, parce qu'ils permettent uniquement l'envoi de « hints » lorsqu'une requête est en attente, et parce que la transmission de ces « hints » au client et leur prise en compte ajoutent une certaine latence.

En pratique, toutefois, Cloudflare et nos partenaires (comme Shopify et Google) ont passé l'année 2022 à expérimenter avec Early Hints ; ils ont découvert que son utilisation étaient beaucoup plus sûre et qu'il offrait des bienfaits prometteurs en termes de performances, notamment une diminution significative d'un certain nombre d'indicateurs essentiels des performances web.

Nous sommes enthousiastes au sujet du potentiel d'Early Hints ; tellement enthousiastes, d'ailleurs, que nous l'avons intégré dans Cloudflare Pages. Par ailleurs, nous évaluons actuellement de nouvelles utilisations de cette nouvelle fonctionnalité du protocole pour améliorer les performances.

Pour beaucoup, les extensions les plus intéressantes du protocole HTTP en 2022 concernaient l'intermédiation, c'est-à-dire la capacité d'insérer des proxies, des passerelles et d'autres composants semblables dans le protocole dans le but d'atteindre des objectifs spécifiques, souvent avec pour but l'amélioration de la confidentialité.

MASQUE Working Group, par exemple, est une initiative visant à ajouter de nouvelles fonctionnalités de tunnellisation à HTTP, de sorte qu'un intermédiaire puisse transmettre le trafic tunnellisé à un autre serveur.

Si CONNECT permet depuis longtemps l'utilisation des tunnels TCP, MASQUE autorise l'utilisation de tunnels UDP, permettant la tunnellisation plus efficace d'un plus grand nombre de protocoles, parmi lesquels QUIC et HTTP/3.

Chez Cloudflare, nous sommes enthousiastes à l'idée de collaborer avec Apple autour de l'utilisation de MASQUE pour déployer iCloud Private Relay et améliorer la confidentialité de ses clients, sans dépendre d'un prestataire unique. Nous nous intéressons également aux travaux futurs du groupe de travail, notamment la tunnellisation IP, qui permettra le déploiement de VPN basés sur MASQUE.

Une autre spécification priorisant l'intermédiation est Oblivious HTTP (ou OHTTP). OHTTP utilise des ensembles d'intermédiaires pour éviter qu'un serveur n'utilise des connexions ou des adresses IP pour suivre les clients ; il offre ainsi de meilleures garanties de confidentialité pour des aspects tels que la collecte de données de télémétrie ou d'autres données sensibles. Cette spécification arrive tout juste au terme du processus de normalisation, et nous l'utilisons afin de créer un nouveau produit important, Privacy Gateway, qui permet de protéger la confidentialité des clients de nos clients.

Nous pensons, comme beaucoup d'autres membres de la communauté Internet, que ce n'est qu'un début, car l'intermédiation peut cloisonner les communications, qui constituent un outil précieux pour améliorer la protection de la vie privée.

Enfin, en 2022, de nombreux travaux ont été réalisés sur les aspects liés à la sécurité du protocole HTTP. La spécification Digest Fields est une mise à jour du champ d'en-tête (désormais ancien) « Digest », et permet l'ajout d'informations d'intégrité condensées (« digests ») aux messages. La spécification HTTP Message Signatures permet d'ajouter des signatures cryptographiques aux requêtes et aux réponses –une fonctionnalité qui a bénéficié d'un vaste déploiement ad hoc, mais n'a, jusqu'à présent, pas été normalisée. Ces deux spécifications ont atteint la phase finale du processus de normalisation.

Des progrès considérables ont également été accomplis en 2022 sur une révision de la spécification relative aux cookies, qui devrait bientôt être finalisée. Puisqu'il est impossible de se débarrasser entièrement des cookies dans un avenir proche, de nombreux travaux ont été réalisés dans le but de restreindre leur fonctionnement, afin d'améliorer la confidentialité et la sécurité, notamment avec un nouvel attribut « SameSite ».

Par ailleurs, Cloudflare investit depuis de nombreuses années dans un autre ensemble de spécifications liées à la sécurité, appelé Privacy Pass (également connu sous le nom de « Private Access Tokens »). Il s'agit de jetons cryptographiques permettant d'assurer que les clients sont de véritables personnes, et non des bots, sans utiliser un CAPTCHA intrusif et sans surveiller l'activité en ligne de l'utilisateur. Dans le protocole HTTP, ils se présentent sous la forme d'un nouveau schéma d'authentification.

Bien que Privacy Pass n'ait pas encore tout à fait atteint le terme du processus de normalisation, en 2022, il a fait l'objet d'un déploiement à grande échelle par Apple, ce qui constitue un énorme pas en avant. Et puisque Cloudflare l'utilise dans Turnstile, son alternative aux CAPTCHA, vos utilisateurs peuvent dès aujourd'hui bénéficier d'une expérience meilleure.

Alors, quelle sera la suite des événements ? Outre les spécifications ci-dessus, qui ne sont pas encore tout à fait finalisées, HTTP Working Group a quelques autres travaux en cours, parmi lesquels une méthode QUERY (semblable à GET, mais avec une composante « body »), Resumable Uploads (des transferts de fichiers avec reprise, basés sur le protocole tus), Variants (un en-tête « Vary » amélioré pour la mise en cache), des améliorations à Structured Fields (notamment un nouveau type Date), et une approche pour intégrer rétroactivement des en-têtes existants à Structured Fields. Nous consacrerons d'autres articles à ces sujets au fur et à mesure de leur avancement en 2023.

Lors de l'édition 2022 de HTTP Workshop, la communauté a également discuté des nouveaux travaux que nous pouvons entreprendre afin d'améliorer le protocole. Parmi les idées évoquées figuraient l'amélioration de notre infrastructure partagée de test de protocoles (à l'heure actuelle, nous disposons de quelques ressources, mais elles pourraient être bien plus complètes), l'amélioration (ou le remplacement) d'Alternative Services, afin de permettre une gestion plus intelligente et précise des connexions, ainsi que des changements plus radicaux, tels que d'autres sérialisations binaires des en-têtes.

La discussion se poursuit également au sein de la communauté afin de déterminer si HTTP doit s'adapter à la fonction pub/sub, ou si le protocole doit être normalisé dans l'optique de la compatibilité avec WebSockets (et prochainement, WebTransport). Bien qu'il soit difficile de le dire maintenant, le récents travaux adjacents consacrés à Media over QUIC pourraient offrir une opportunité d'avancées dans ce domaine.

Bien entendu, ce n'est pas tout, et ce qu'il adviendra de HTTP en 2023 (et au-delà) reste à voir. Le protocole HTTP continue d'évoluer, même s'il reste compatible avec le plus vaste système hypertexte distribué jamais conçu, le World Wide Web.