Discourse prend-il déjà en charge http3 ?
Je sais que c’est principalement un problème de réseau, mais si j’exécute Discourse sur DigitalOcean, par exemple, le conteneur Docker dans lequel Discourse s’exécute doit être capable de prendre en charge http3.
Je ne sais pas, mais comment http3 aiderait-il Discourse ?
Pas pour le moment
Techniquement, HTTP3 n’est qu’une autre version du protocole HTTP. Donc, si quelqu’un souhaite proposer son instance Discourse sur HTTP3 aujourd’hui, il peut le faire en plaçant un proxy inverse HTTP distinct qui prend en charge HTTP3 devant votre instance Discourse. C’est possible sans modifier l’image Docker de Discourse.
Je suppose un peu ici, donc attention, mais il semble que l’image Docker utilise Nginx comme proxy inverse pour Discourse en interne. Je vois que Nginx prend en charge HTTP3 nativement, mais considère l’implémentation comme expérimentale pour le moment. C’est peut-être pour cela que la prise en charge de HTTP3 dans l’image Docker n’est pas implémentée pour le moment ?
Oui, c’est une fonctionnalité expérimentale, mais d’après les tests sur d’autres sites, on peut voir qu’elle est déjà suffisamment stable pour les projets qui choisissent la voie http3 aujourd’hui.
Existe-t-il un mainteneur Docker pour Discourse que j’hébergerais, s’il pouvait ajouter la prise en charge de http3 comme fonctionnalité optionnelle, pour les projets qui y sont intéressés ?
Un très bon article qui vous donne une idée des avantages de Discouse est ici What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
J’ai une compréhension générale de HTTP/3 et je sais comment et pourquoi il est utile avec WordPress/LAMP, mais je ne comprends pas pourquoi il ferait une différence avec Discourse.
Http3 réduit la latence lors de l’établissement d’une connexion entre le serveur et le client jusqu’à 150 ms. De plus, il permet d’économiser des ressources serveur, car l’établissement de la communication http est plus économique.
Ainsi, l’utilisateur bénéficiera d’une meilleure expérience communautaire et l’opérateur serveur aura moins de charge. Gagnant-gagnant.
Pas pour le moment, malheureusement.
J’ai conservé une branche de notre conteneur prête pour HTTP/3 depuis (vérifie les notes) 2019, que vous pouvez consulter sur GitHub - discourse/discourse_docker at http3.
La raison pour laquelle nous ne l’avons pas déployé largement est due à un ensemble de problèmes dans l’écosystème général :
Le développement de Nginx a ralenti considérablement, et ils ne suivent plus les nouvelles technologies web, comme HTTP/3 ou Early Hints.
L’architecture modulaire de Nginx signifiait que nous pouvions l’ajouter via un module, et ma branche utilise le module nginx de Cloudflare, quiche, pour cela. Mais Cloudflare s’est également détourné de nginx, et ce module n’a jamais été considéré comme prêt pour la production.
J’ai envisagé de migrer vers un serveur web plus moderne, comme Caddy, mais des changements comme celui-ci sont très difficiles lorsque vous publiez un logiciel auto-hébergé que les gens vont personnaliser.
Migrer vers HAProxy serait plus facile à accepter, mais nous utilisons nginx pour la diffusion de fichiers statiques, ce que HAProxy ne fera pas.
Le fait que les mainteneurs d’OpenSSL aient essentiellement saboté QUIC et arrêté les progrès de tout l’écosystème pendant l’équivalent d’une décennie.
Tous les éléments ci-dessus, ainsi que tous les problèmes inhérents au passage de TCP à UDP qui fait partie de cela, signifiaient que ce changement était trop risqué pour nous.
Ce qui est très triste, étant donné que dans le foyer moyen des 4 dernières années, la plupart du trafic est déjà HTTP/3, car tous les grands acteurs y ont migré il y a des années, comme YouTube, Amazon, Shopify, Instagram, Twitch.tv, etc. Cela augmente encore l’écart entre la grande technologie et les petits sites, et il est dommage que nous n’ayons pas pu être des adopteurs précoces ici, comme nous l’avons été avec SPDY, HTTP/2 et Brotli.
Compte tenu de tout cela, si vous souhaitez une solution simple en 1 clic pour résoudre tout ce désordre, vous pouvez utiliser Cloudflare devant votre instance Discourse.
Cela me peine de l’entendre. J’ai quelques idées à explorer. Pouvons-nous en discuter ?
QUIC is not supported - Help - Caddy CommunityLa manière la plus propre de le construire, qui a le potentiel de devenir quelque chose que nous pourrions éventuellement expédier, serait d’ajouter un nouveau modèle qui serait une alternative à web.ssl.template.yml, appelons-le web.ssl2.template.yml.
Dans ce modèle, au lieu de modifier nginx, il démarre un serveur web alternatif, disons Caddy, qui gère tout le trafic et relaie vers nginx. Cela permettrait beaucoup d’expérimentation, la possibilité de tester plusieurs serveurs web, et pourrait potentiellement évoluer en quelque chose que nous pourrions faire par défaut pour les nouvelles installations.
Génial. J’adorerais participer aux tests. Quelles sont les prochaines étapes ?
Faire le travail 
Une autre approche consisterait à ajouter une passerelle HTTP dédiée à l’image Docker pour gérer le trafic HTTP3 et uniquement cela. Par exemple, vous pourriez intégrer Envoy Proxy - qui prend en charge l’entrée HTTP3 - et le configurer pour qu’il n’écoute que sur le port 443/udp pour le trafic h3, et transformer toutes les requêtes h3 entrantes en h2 ou h1.1 et les transmettre à l’instance Nginx.
Cependant, c’est un peu une solution de contournement, donc je ne dirais pas que c’est une bonne idée.
Quelle que soit la voie que vous décidiez d’emprunter, je pense que http3 est une bonne chose et qu’elle aidera tout l’écosystème. J’attends avec impatience les prochaines étapes.
[Divulgation : Je suis le responsable de la communauté de la Fondation OpenSSL depuis janvier.]
Il s’avère qu’OpenSSL 3.5 devrait être publié en avril avec la prise en charge du serveur QUIC. Il existe également une démo d’un serveur HTTP3 qui utilise l’API QUIC d’OpenSSL avec nghttp3.
(Étant donné que la question de la gouvernance a été soulevée dans ce lien, je dois souligner qu’OpenSSL a adopté une nouvelle structure de gouvernance l’année dernière. Je suis prudemment optimiste et je pense que cela a finalement permis de finaliser QUIC.)
Il semble que nginx adoptera l’API QUIC d’OpenSSL. Aucune indication du calendrier pour le moment, cependant.