Comment HTTP est devenu un protocole à tout faire

Lorsque Tim Berners Lee inventa le World Wide Web à la fin des années 1980, en ne faisant « que prendre le principe d’hypertexte et le relier au principe du TCP et du DNS », il avait dans l’idée de faciliter l’échange d’informations entre ordinateurs. Déjà fort de cette invention et de la renommée qui en découlerait, il ne se doutait peut-être pas que son protocole allait devenir le protocole à tout faire d’Internet trente ans plus tard.

Bref historique

Le protocole a subi peu de nouvelles versions (mais de profonds changements) au fil du temps : entré dans le domaine public en 1993 et formalisé en 1996, il passe en version 1.1 en 1999 avec une mise à jour importante (l’en-tête Host obligatoire) permettant l’hébergement de pages en environnement mutualisé. Google avait déjà été à l’origine du protocole SPDY qui sera ensuite intégré à HTTP/2 en 2015 ; l’entreprise récidive avec l’intégration de QUIC à HTTP/3 en 2022, avec l’objectif annoncé de rendre TCP obsolète. Ces deux évolutions amènent le multiplexage des requêtes, le but étant de limiter la congestion des réseaux et de rendre l’accès aux sites et applications web plus rapide.

Le multiplexage des requêtes permet à une page de fournir aux clients davantage de ressources en un minimum de temps. Ces ressources peuvent être diverses, notamment des feuilles de style et du javascript, mais aussi des images. Cela ouvre donc la porte à des sites et applications de plus en plus fournis et complexes alors que, dans le même temps, le nombre de clients ne cesse de croître, sous la forme de périphériques mobiles, de téléviseurs, de réfrigérateurs ou encore de voitures connectées.

L’obésité du Web

La question qui se pose alors est la suivante : qui alimente qui ? Est-ce que c’est réellement l’obésité croissante du Web qui impose l’élaboration des mises à jour du protocole ? Ou est-ce que ce sont ces mises à jour qui incitent à la création et à l’usage de sites et applications toujours plus lourds ?

Pour ma part, je postule que les évolutions du protocole ont entraîné un paradoxe de Jevons : si le but affiché de ces mises à jour était d’accélérer le Web, on a profité de l’évolution concomitante des débits de connexion à Internet pour créer des sites et applications de plus en plus complexes – et donc plus lourds qui, en retour, ont nécessité de nouveaux protocoles. Le cercle vicieux, typique de la société de consommation, où progrès et besoins apparents s’entretiennent mutuellement.

Les rapports fournis par HTTP Archive sont éloquents : une page web pèse en moyenne un peu plus de 3Mo (soit plus de 43 fois le poids du code qui a permis à Apollo 11 d’alunir estimé à environ 70ko) et force près de 80 requêtes pour un chargement complet (dont 2 pour le HTML, 8 pour les feuilles de style, 4 pour les fontes, 19 pour les images et 23 pour le javascript).

Ces courbes montrent que la vitesse à laquelle un plus haut débit s’est imposé est très supérieure à la vitesse à laquelle les pages ont grossi. J’en déduis que de nouveaux protocoles n’étaient pas nécessaires, si leur but était réellement d’accélérer l’accès aux ressources. C’est d’autant plus évident lorsque l’on prend en compte les évolutions des outils de développement qui permettent la concaténation et l’optimisation des ressources tierces, ou encore l’évolution du matériel de plus en plus performant.

Autrement dit, si le Web s’était figé dans son état antérieur à l’introduction de HTTP/2, le protocole n’aurait pas forcément eu besoin d’évoluer pour rendre le Web plus rapide. Par corollaire, ce n’est pas forcément parce que le protocole a évolué que la navigation sur Internet est devenue plus rapide.

Dans les faits, on télécharge de plus en plus rapidement des pages de plus en plus lourdes ; on se rend de moins en moins compte d’une complexité cachée, édulcorée par une rhétorique commerciale progressiste à laquelle tout le monde semble adhérer. On dispose d’un protocole créé pour en faire plus, pourquoi ne pas en faire plus ? Si HTTP est devenu si performant, pourquoi ne pas en faire plus que simplement de la transmission d’information ?

HTTP n’est plus ce qu’il était

Le phénomène n’est pas récent : les premières implémentations de XML-RPC remontent à 1999, Microsoft développe le RPC over HTTP pour Outlook dans les années 2000, XMPP via BOSH existe depuis 2007, git peut utiliser HTTP depuis 2010, et surtout DNS-over-HTTPS émerge en 2018. Depuis 2022, on cherche à utiliser UDP pour transporter du trafic HTTP, et depuis 2023, MASQUE vise à créer un tunnel IP complet via HTTP. Il en résulte une véritable culture technique œuvrant à transformer le protocole HTTP – dont je questionne à la fois les motivations et la finalité¹.

HTTP est utilisé par plusieurs milliards de sites et applications Web : les pare-feu sont déjà configurés pour laisser passer ce trafic, l’écosystème logiciel est mature, riche et déjà sécurisé grâce à TLS. Pour un besoin applicatif donné, créer un nouveau protocole dédié revient à attribuer un ou plusieurs ports réseau, choisir un protocole de transport, gérer des sessions, développer la couche de sécurité (souvent basée sur les mêmes briques que de nombreuses autres applications), impose une politique spécifique de gestion des accès, et soulève des questions de portabilité. Tout cela représente un coût, non seulement intellectuel mais également financier, en tout cas pour les entreprises commerciales qui souhaitent répondre à un besoin applicatif inexistant. HTTP apparait donc comme un choix rationnel.

Le recours systématique à HTTP produit rarement une catastrophe immédiate. Au contraire, il fonctionne assez bien pour être répété. Cette réussite partielle le rend toutefois dangereux lorsqu’il est systématiquement mis en œuvre, et à en juger par l’avenir réservé au protocole, il me semble prudent d’anticiper les dettes que nous allons contracter.

Les dettes à venir

La première dette est la perte de lisibilité. Un pare-feu qui voyait autrefois du DNS sur 53, du SMTP sur 25, de l’IMAP sur 143 ou 993 et du SSH sur 22 voit désormais une masse croissante de flux HTTPS sur 443 : le port cesse d’indiquer la fonction.

La deuxième dette est la concentration des risques. Quand une infrastructure dépend fortement de HTTPS, du reverse-proxy, des certificats, de l’authentification web et des règles de routage, une erreur sur cette couche peut affecter des services très différents. Un certificat expiré, une règle de pare-feu applicatif trop stricte, une mauvaise configuration HTTP/2, un problème de SNI ou une redirection mal posée peuvent provoquer des symptômes très éloignés de leur cause. On risque d’ailleurs de diluer ces problèmes par la multiplication des infrastructures redondantes, au lieu de les corriger à leur niveau le plus fondamental.

La troisième dette est le diagnostic indirect. Un protocole spécialisé expose souvent des erreurs propres à son domaine. HTTP ramène une grande diversité de problèmes à des statuts génériques : 400, 401, 403, 404, 429, 500, 502, 503, 504. Ces codes sont utiles, mais ils peuvent masquer la cause réelle : erreur DNS interne, backend indisponible, token expiré, timeout, limite de débit, règle de proxy, entête manquant, saturation applicative, etc.

Alors que l’on est de moins en moins enclins à produire des messages d’erreurs utiles et informatifs, il est peu probable que nous nous engagions dans une voie améliorative avec HTTP. Au contraire, on risque de réutiliser les codes d’erreur génériques du protocole par paresse ou économie. On risque également de faire perdurer la télémétrie et la transmission d’informations potentiellement sensibles à des entreprises tierces, perpétuant ainsi la tradition d’externaliser les problèmes et leur traitement. Dit plus vulgairement : on va continuer à cacher les problèmes sous un tapis en espérant que personne ne les remonte.

Une critique sans nostalgie

La critique d’HTTP comme protocole à tout faire peut facilement tourner au regret d’un Internet ancien, composé de protocoles spécialisés, lisibles et séparés. Cette nostalgie serait trompeuse. Les protocoles historiques avaient aussi leurs défauts : sécurité parfois ajoutée tardivement, ergonomie médiocre, déploiement difficile, compatibilités inégales, traversée réseau pénible, clients hétérogènes, etc. Ce que je regrette avant tout, c’est que l’on fasse le choix de la facilité en oubliant au passage des principes fondamentaux et en piétinant l’identité des éléments déjà construits.

Cela dit, le succès d’HTTP vient aussi de la résolution de problèmes réels. L’objectif n’est donc pas de réclamer un retour pur et simple au passé, mais de faire preuve de bon sens, et de distinguer plusieurs situations.

Avant de systématiser le recours à HTTP, il convient, d’après moi, de se poser les bonnes questions :

• « Le modèle requête/réponse suffit-il ? »
• « Le navigateur est-il un client naturel ? »
• « Est-ce que l’application a besoin d’un cache ? »
• « Le port 443 est-il choisi pour ses qualités ou pour contourner un blocage ? »
• « Le diagnostic restera-t-il possible sans l’application web ? »
• « La sécurité se comprend-elle au niveau HTTP ? »

Conclusion

HTTP mérite sa place centrale. Son histoire, son outillage et sa capacité d’évolution expliquent largement son succès. Les RFC modernes montrent un protocole vivant, capable de s’adapter à de nouveaux transports, de nouvelles performances et de nouveaux usages. Le Web a fourni à l’informatique distribuée une infrastructure commune, robuste et extraordinairement pratique.

La mauvaise habitude commence quand cette infrastructure commune devient une excuse pour ne plus penser les protocoles. Encapsuler dans HTTP permet souvent d’aller plus vite. Cela peut aussi rendre le réseau plus opaque, concentrer les pannes, affaiblir les frontières administratives et déplacer le diagnostic dans des couches intermédiaires. Le sujet n’oppose donc pas modernité et tradition. Il oppose deux manières de concevoir l’infrastructure : choisir HTTP parce qu’il correspond au problème, ou choisir HTTP parce qu’il évite d’avoir à traiter le problème dans sa forme propre.

La formule la plus juste pourrait être celle-ci :

HTTP est devenu le langage commun de l’infrastructure. Le danger commence quand un langage commun devient une pensée unique.