Adoption de HTTP3 par les chatons

stephane · April 13, 2023, 8:24pm

À l’occasion d’un échange sur les réseaux sociaux des chatons, le chaton de la contrevoie publiait un post au sujet de leur fameux service nitter

Ce service utilise HTTP3 . À priori, c’est le premier service déployé par un chaton qui propose HTTP3. Le post, par ailleurs, met en avant cela.

Une discussion sur pourquoi l’adoption de ce protocole a été initiée. Il a été proposé de poursuivre sur le forum en ouvrant un sujet dédié. Cependant cela n’a pas été fait. Donc, mea culpa @neil , je le fais maintenant.

Stéphane Bortzmeyer a fait de nombreux articles sur le sujet de HTTP3. On les trouvera notamment sur son blog (note pour + tard → mettre des liens)

Il semblerait qu’il se dessine une controverse entre les grands opérateurs du marché. Pour faire court, les gagnants seraient les services portés par les grands hébergeurs de service comme par exemple youtube, netflix, amazon prime, les perdants les FAI et opérateur réseaux qui vous amènent ces paquets jusque dans votre poche ou à la maison.

En effet, HTTP3 permet d’optimiser au mieux les ressources coté serveur car l’essentiel du flux est transmis en une fois et sur un temps très court. Ce qui permet logiquement d’augmenter la disponibilité du matériel pour servir de plus nombreux clients. (Je fais court) C’est ce qu’on appelle un effet rebond. Il se trouve que l’effet en question est parfaitement observé par les gens qui font de la qoe comme par exemple sandivine.

Cela permet, en creux, de comprendre comment ces hébergeurs arrivent à produire des rapports environnementaux enviable et envié par toute l’industrie.

Du coup, @neil , est-ce que vous avez eu un débat sur ce sujet? C’est à dire adopter HTTP/3 comme une avancée technologique enviable, et, après tout, pourquoi pas. Ou certain·es d’entre vous on émit des réserves pour exprimer un souhait d’une forme de décroissance de nos usages, qui reste à définir, mais sur laquelle il serait bon de s’attarder ?

Merci par avance pour vos réponses.

neil · April 14, 2023, 9:48pm

Bonjour Stéphane,

Je te remercie de (re)lancer ce sujet, et je te prie d’excuser par ailleurs ma réaction défensive sur les réseaux, ayant d’abord cru que cette critique de notre usage de ce protocole relevait d’une forme de pureté militante, alors qu’il me semble simplement que nous nous soyons mal compris.

J’imagine que tu parles de cet article, par exemple : Blog Stéphane Bortzmeyer: RFC 9114: Hypertext Transfer Protocol Version 3 (HTTP/3)

J’ajoute en complément sa conférence à Paris Web sur le sujet (que je recommande s’il y a besoin de vulgarisation ).

Tout d’abord, la raison pour laquelle nous sommes passé·es à HTTP/3, c’est parce que nous avons décidé d’abandonner Nginx pour nous orienter vers Caddy, un autre serveur HTTP (écrit en Go).

Caddy propose notamment l’automatisation complète de la gestion des certificats, propose des paramètres de sécurité et des suites de chiffrement très corrects par défaut, le support natif de l’agrafage OCSP, de l’algorithme de compression Brotli et de HTTP/3.

C’est cet ensemble de fonctionnalités qui nous a intéressés à la base, car cela simplifie la gestion de notre infrastructure (plus besoin de nos occuper des agrafages OCSP et du renouvellement des certificats, c’est le serveur HTTP qui gère tout seul). Et le support natif de HTTP/3 est un « bonus » non négligeable à tout cela.

Oui en effet, le protocole QUIC ayant été (à la base) développé par Google pour ses besoins, il a été pensé pour améliorer la performance des gros serveurs avant tout. Je précise par ailleurs que Google a par ailleurs également développé SPDY, qui est à l’origine de HTTP/2 (que fort heureusement tout le monde utilise aujourd’hui, y compris chez les CHATONS).

Je ne vois pas en quoi les FAI et les autres opérateurs réseau sont perdants, puisque le but du protocole est d’améliorer les performances

Non, nous ne voyons (toujours) aucune controverse à ce sujet donc nous n’en avons pas discuté, je dirais même qu’il y a eu consensus pour activer le support HTTP/3 puisque Caddy nous le propose.

Je pense que nous sommes déjà dans la décroissance de nos usages avec notre minuscule infrastructure
Je te renvoie à la présentation vidéo de notre infrastructure si cela t’intéresse.

Et sur le principe, nous utiliserions volontiers des outils et des protocoles plus modernes qui allègeraient encore plus notre infrastructure (bien que je doute que HTTP/3 ait un tel impact).

En tout cas, refuser HTTP/3 pour des raisons de sobriété numérique ne me semble pas censé, puisque c’est une avancée technologique qui est à notre portée et qui ne nous coûte absolument rien. À l’échelle d’un CHATONS, on pourrait dire que cela reviendrait à refuser HTTP/2 pour les mêmes raisons.

Par ailleurs, il n’est pas impossible que HTTP/3 ait un réel impact sur les performances de notre serveur, puisque notre service Nitter traite un flux assez important de requêtes, aux dernières mesures :

58.4 millions de requêtes par semaine
42 888 utilisateur·ice·s uniques par jour en moyenne
Consommation totale de bande passante sur ce service uniquement : 2.4 To par semaine

Nous hébergeons actuellement notre Nitter sur une très petite machine : 2 vCPU et 2 GB de RAM, avec une bande passante plafonnée à 100 Mbps. Cette machine étant très fortement sollicitée par le flux de requêtes de Nitter, donc si HTTP/3 nous permet d’améliorer (même un tout petit peu !) les performances de notre petite installation (la latence, la consommation de CPU, la bande passante…), on prend volontiers.

J’espère que j’ai pu éclairer tes interrogations et inquiétudes.

pilot · April 17, 2023, 10:34pm

Je rejoins l’avis de @neil, notamment à propos des bienfaits du déploiement de HTTP/3. C’est une évolution très intéressante permettant d’utiliser UDP et de réduire les échanges réseaux inutiles. L’effet rebond de cette nouvelle version est également positive en ce qu’elle permet de faire évoluer les infrastructures (vive caddy ! ). Ceci permet de tendre vers plus de sécurité et d’efficacité (y compris énergétique).

Opposer HTTP/3 à une stratégie de décroissance semble incongru, si on considère les pratiques amplement plus impactantes de certains hébergeurs (même parmi les CHATONS). Ainsi, le serveur Nitter de la Contre-Voie est à considérer comme efficace grâce à l’exploitation de peu ressources, sur un VPS mutualisé qui plus est. Cela est bien différent d’un énorme serveur dédié dans un centre de donnée et utilisé au minimum de ses capacités.

Le seul bémol de cette version du protocole est aussi une de ses qualités : UDP. En effet, et bien que ce soit un usage minime, l’UDP n’est pas supporté par Tor ce qui empêche l’accès aux services à des usagers pour qui l’anonymat est primordial. À ce titre, proposer HTTP/2 et HTTP/3 semble être la meilleure solution. (HTTP/2 n’est de toute manière pas près de disparaître.)

stephane · April 19, 2023, 3:24pm

Tout d’abord, je vous remercie pour vos réponses. Ensuite je souhaiterais lever une potentielle incompréhension.

Mon interrogation n’est certainement pas de vouloir interdire à quiconque et encore moins à un Chatons de faire, tester, essayer, découvrir, etc… Bien au contraire, je ne peux que encourager cela. Peu m’ importe qu’une techno soit initié ou porté par Google. La condition minimale est qu’elle soit libre.

Je suis assez serein la plupart du temps. t’inquiètes donc pas

Toutafé. Il est d’ailleurs probable que cette tendance soit génératrice de plus d’usage globalement plus impactant. Je comprends qu’il soit difficile de comprendre cela.

Toutes les technos mettent du temps à disparaître. HTTP/1.1 HTTP/2 HTTP3 vont coexister pendant longtemps à priori pas de problème pour Tor.

Cependant, l’essentiel de l’originalité de cette techno ne réside pas dans l’usage de UDP . UDP et TCP sont dans la même couche. HTTP/3 s’affranchit de TCP/IP. C’est à dire qu’une connexion QUIC initié dans la couche transport peut être maintenu même avec une autre IP. C’est à dire même après avoir changé de réseau. C’est particulièrement vrai pour une connexion mobile.

Là par contre, il y a potentiellement des problématiques de «vie privée» . Je ne suis pas certain qu’elle soient bien évaluées.

Ensuite, cela ouvre d’autre problématique de sécurité. En effet, un attaquant pourrait maintenir une connexion tout en la distribuant sur de multiple ip. Ce qui la rendrait indétectable par nos outils standards.

Bref encore pleins de questions très à la marge de la discussion initiale.

neil · April 19, 2023, 6:23pm

Personnellement, je doute que la généralisation de HTTP/3 entraîne une évolution des usages qui soit suffisamment impactante pour être prise au sérieux, tant les gains en performance sont relativement minimes. On est très loin, par exemple, des gains de bande passante de la 4G à la 5G qui peuvent réellement boulverser les usages du quotidien, avec les revers écologiques que la fabrication de ces antennes et du remplacement des appareils mobiles peuvent entraîner (et je te réfère justement au blog de Stéphane Bortzmeyer à ce sujet).

Je suppose que tu fais allusion au fait qu’une session QUIC puisse être réutilisée même en changeant d’IP, offrant ainsi de nouvelles possibilités de retracer des utilisateur·ices pour les hébergeurs de services, qui s’ajoutent à la grande panoplie des méthodes existantes (cookie, données de navigateur, canvas webGL, IP…).

Mais si lesdits hébergeurs de services s’engagent à ne pas utiliser ces méthodes et à respecter la vie privée des utilisateur·ices, la question ne se pose même pas Et ça tombe bien, nous avons une charte qui nous engage à ce sujet.

Tu vas me dire, ça reste un problème lié à HTTP/3. Mais le fait que les CHATONS déploient HTTP/3 ou non n’a aucune influence sur l’usage de ces méthodes de traçage par les GAFAM, puisque la large majorité des navigateurs supportent désormais HTTP/3 et l’utiliseront par défaut de toute manière.

Honnêtement, si l’on devait définir un modèle de menace à La Contre-Voie pour hiérarchiser les potentiels vecteurs d’attaque de notre infrastructure, on aurait d’autres priorités : les attaques par déni de service distribuées (et sans QUIC) que même nos outils actuels ne peuvent encaisser correctement (voir le topic fail2ban), l’abus de nos services par des spammeurs à des fins de phishing…

En terme de sécurité, je pense que c’est une bonne chose que le protocole HTTP/3 nécessite TLS dans sa spécification même, c’est plutôt un bond en avant.