¿Discourse ya soporta http3?
Sé que es principalmente un problema de red, pero si ejecuto Discourse en DigitalOcean, por ejemplo, el contenedor Docker en el que se ejecuta Discourse debe poder soportar http3.
No lo sé, pero ¿cómo ayudaría http3 a Discourse?
Por ahora no
2 Me gusta
Técnicamente, HTTP3 es solo otra versión del protocolo HTTP. Por lo tanto, si alguien quiere ofrecer su instancia de Discourse a través de HTTP3 hoy, puede hacerlo colocando un proxy inverso HTTP separado que admita HTTP3 delante de su instancia de Discourse. Eso es posible sin cambiar la imagen docker de Discourse.
Estoy adivinando un poco aquí, así que ten cuidado, pero parece que la imagen docker utiliza Nginx como proxy inverso para Discourse internamente. Veo que Nginx admite HTTP3 de forma nativa, pero considera que la implementación es experimental por el momento. ¿Quizás por eso no se implementa el soporte HTTP3 en la imagen docker por el momento?
2 Me gusta
Sí, es una característica experimental, pero por las pruebas en otros sitios, se puede ver que ya es lo suficientemente estable para los proyectos que eligen la ruta http3 hoy en día.
¿Hay algún mantenedor de Docker para Discourse que yo alojaría, si pudieran agregar soporte http3 como una característica opcional, para los proyectos que estén interesados en él?
Un artículo muy bueno del que puedes hacerte una idea de los beneficios para Discouse está aquí What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
Tengo una comprensión general de HTTP/3 y sé cómo y por qué es útil con WordPress/LAMP, pero no entiendo por qué marcaría la diferencia con Discourse.
Http3 reduce la latencia al establecer una conexión entre el servidor y el cliente hasta en 150 ms. Además, ahorra recursos del servidor, ya que establecer la comunicación http es más económico.
Así, el usuario tendrá una mejor experiencia en la comunidad y el operador del servidor tendrá menos carga. Beneficio para todos.
Lamentablemente, por el momento no.
He mantenido una rama de nuestro contenedor lista para HTTP/3 desde (revisa notas) 2019, la cual puedes consultar en GitHub - discourse/discourse_docker at http3.
La razón por la que no lo hemos implementado de forma generalizada se debe a una serie de problemas en el ecosistema general:
-
El desarrollo de Nginx se ralentizó drásticamente y ya no se mantiene al día con las nuevas tecnologías web, como HTTP/3 o Early Hints.
-
La arquitectura modular de Nginx significaba que podíamos añadirlo a través de un módulo, y mi rama utiliza el módulo nginx de Cloudflare, quiche, para ello. Pero Cloudflare también ha abandonado nginx, y ese módulo nunca se consideró listo para producción.
-
Consideré migrar a un servidor web más moderno, como Caddy, pero cambios como ese son súper difíciles cuando lanzas software autoalojado que la gente personalizará.
-
Migrar a HAProxy sería más fácil de aceptar, pero usamos nginx para servir archivos estáticos, algo que HAProxy no hará.
-
El hecho de que los mantenedores de OpenSSL básicamente sabotearan QUIC y detuvieran el progreso de todo el ecosistema durante el equivalente a una década.
Todo lo anterior, además de todos los problemas inherentes al cambio de TCP a UDP que forma parte de esto, significó que este cambio era demasiado arriesgado para nosotros.
Lo cual es muy triste, dado que en el hogar promedio de los últimos 4 años, la mayor parte del tráfico ya es HTTP/3, ya que todos los grandes jugadores han migrado a él hace años, como YouTube, Amazon, Shopify, Instagram, Twitch.tv, etc. Esto aumenta aún más la brecha entre la gran tecnología y los sitios pequeños, y es una pena que no hayamos podido ser adoptadores tempranos aquí, como lo fuimos con SPDY, HTTP/2 y Brotli.
Dado todo esto, si quieres una solución fácil de 1 clic para todo este lío, puedes usar Cloudflare delante de tu instancia de Discourse.
12 Me gusta
Me duele oír eso. Tengo algunas ideas para explorar. ¿Podemos discutirlas?
- Consideraría instalar un módulo en Nginx, como el que permitiría http3
- Escribiría a la comunidad de Discourse que utiliza Caddy y les preguntaría si podrían ayudarle con la transición a Caddy, podría ser una asociación beneficiosa para ambos
QUIC is not supported - Help - Caddy Community
1 me gusta
La forma más limpia de construirlo, que tiene el potencial de ser algo que eventualmente enviemos, sería agregar una nueva plantilla que sería una alternativa a web.ssl.template.yml, llamémosla web.ssl2.template.yml.
En esta plantilla, en lugar de modificar nginx, inicia un servidor web alternativo, digamos Caddy, que maneja todo el tráfico y se proxy a nginx. Esto permitiría mucha experimentación, la capacidad de probar múltiples servidores web y podría evolucionar en algo que podríamos convertir en el predeterminado para nuevas instalaciones.
4 Me gusta
Suena genial. Me encantaría participar en las pruebas. ¿Cuáles son los próximos pasos?
2 Me gusta
Haciendo el trabajo 
5 Me gusta
Otro enfoque sería añadir, a la imagen de Docker, un proxy inverso HTTP dedicado para manejar el tráfico HTTP3 y solo eso. Por ejemplo, podrías incrustar Envoy Proxy - que soporta la entrada HTTP3 - y configurarlo para que escuche solo en el puerto 443/udp para el tráfico h3, y transformar todas las solicitudes h3 entrantes a h2 o h1.1 y reenviarlas a la instancia de Nginx.
Aunque es un poco un hack, así que no diré que es una buena idea.
2 Me gusta
Como sea que decidas ir, creo que http3 es un buen paso y ayudará a todo el ecosistema. Estoy deseando ver los próximos pasos.
[Disclosure: Soy el gerente de la comunidad de la Fundación OpenSSL desde enero.]
Resulta que OpenSSL 3.5 está programado para ser lanzado en abril con soporte de servidor QUIC. También hay una demostración de un servidor HTTP3 que utiliza la API QUIC de OpenSSL con nghttp3.
(Dado que se planteó el tema de la gobernanza en ese enlace, debo señalar que OpenSSL adoptó una nueva estructura de gobernanza el año pasado. Soy cautelosamente optimista y creo que ayudó a que QUIC saliera finalmente.)
Parece que nginx adoptará la API QUIC de OpenSSL. Sin embargo, aún no hay indicación de la línea de tiempo.
4 Me gusta