O Discourse já suporta http3?
Sei que é principalmente uma questão de rede, mas se eu executar o Discourse na DigitalOcean, por exemplo, o contêiner Docker em que o Discourse é executado deve ser capaz de suportar http3.
Não sei, mas como o HTTP/3 ajudaria o Discourse?
Neste momento não
2 curtidas
Tecnicamente, o HTTP3 é apenas mais uma versão do protocolo HTTP. Portanto, se alguém quiser oferecer sua instância Discourse sobre HTTP3 hoje, pode fazê-lo colocando um proxy reverso HTTP separado que suporte HTTP3 na frente de sua instância Discourse. Isso é possível sem alterar a imagem Docker do Discourse.
Estou adivinhando um pouco aqui, então cuidado, mas parece que a imagem Docker usa o Nginx como um proxy reverso para o Discourse internamente. Vejo que o Nginx suporta HTTP3 nativamente, mas considera a implementação experimental por enquanto. Talvez seja por isso que o suporte a HTTP3 na imagem Docker não está implementado por enquanto?
2 curtidas
Sim, é um recurso experimental, mas pelos testes em outros sites, já se vê que ele é estável o suficiente para projetos que optam pela rota http3 hoje.\n\nExiste algum mantenedor do Docker para o Discourse que eu hospedaria, se eles pudessem adicionar suporte a http3 como um recurso opcional, para projetos que estejam interessados nele?
Um artigo muito bom do qual você pode ter uma ideia dos benefícios para o Discouse está aqui What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
Tenho uma compreensão geral do HTTP/3 e sei como e por que ele é útil com WordPress/LAMP, mas não entendo por que faria diferença com o Discourse.
O Http3 reduz a latência no estabelecimento de uma conexão entre o servidor e o cliente em até 150ms. Além disso, ele economiza recursos do servidor, pois o estabelecimento da comunicação http é mais econômico.
Assim, o usuário terá uma melhor experiência na comunidade e o operador do servidor terá menos carga. Ganha-ganha.
No momento, infelizmente não.
Mantive um branch do nosso container pronto para HTTP/3 desde (verifica as anotações) 2019, que você pode conferir em GitHub - discourse/discourse_docker at http3.
O motivo pelo qual não implementamos isso amplamente se deve a uma série de problemas no ecossistema geral:
-
O desenvolvimento do Nginx desacelerou drasticamente, e eles não estão acompanhando as novas tecnologias web, como HTTP/3 ou Early Hints.
-
A arquitetura modular do Nginx significava que poderíamos adicioná-lo via módulo, e meu branch usa o módulo nginx da Cloudflare, quiche, para isso. Mas a Cloudflare também se afastou do nginx, e esse módulo nunca foi considerado pronto para produção.
-
Considerei migrar para um servidor web mais moderno, como o Caddy, mas mudanças como essa são super difíceis quando você lança software auto-hospedado que as pessoas irão personalizar.
-
Migrar para o HAProxy seria mais fácil de vender, mas usamos nginx para servir arquivos estáticos, o que o HAProxy não fará.
-
O fato de os mantenedores do OpenSSL basicamente sabotarem o QUIC e paralisarem o progresso de todo o ecossistema por uma década.
Todos os pontos acima, além de todos os problemas inerentes à mudança de TCP para UDP que faz parte disso, significaram que essa mudança era muito arriscada para nós.
O que é super triste, dado que na residência média dos últimos 4 anos, a maior parte do tráfego já é HTTP/3, pois todos os grandes players migraram para ele anos atrás, como YouTube, Amazon, Shopify, Instagram, Twitch.tv, etc. Isso aumenta ainda mais a lacuna entre a big tech e os sites pequenos, e é uma pena que não tenhamos conseguido ser adotantes precoces aqui, como fomos com SPDY, HTTP/2 e Brotli.
Diante de tudo isso, se você quiser uma solução fácil de 1 clique para toda essa bagunça, pode usar o Cloudflare na frente da sua instância Discourse.
12 curtidas
Dói-me ouvir isso. Tenho algumas ideias para explorar. Podemos discuti-las?
- Eu consideraria instalar um módulo no Nginx, como um que permitisse o http3
- Eu escreveria para a comunidade do Discourse que você usa e perguntaria se eles poderiam ajudá-lo na transição para o Caddy, poderia ser uma parceria ganha-ganha
QUIC is not supported - Help - Caddy Community
1 curtida
A maneira mais limpa de construir isso, que tem potencial para ser algo que eventualmente entregaremos, seria adicionar um novo template que seria uma alternativa ao web.ssl.template.yml, vamos chamá-lo de web.ssl2.template.yml.
Neste template, em vez de modificar o nginx, ele inicia um servidor web alternativo, digamos Caddy, que lida com todo o tráfego e faz proxy para o nginx. Isso permitiria muita experimentação, capacidade de testar múltiplos servidores web e pode potencialmente evoluir para algo que poderíamos tornar o padrão para novas instalações.
4 curtidas
Parece ótimo. Adoraria me envolver nos testes. Quais são os próximos passos?
2 curtidas
Fazendo o trabalho 
5 curtidas
Outra abordagem seria adicionar, à imagem do Docker, um proxy HTTP dedicado para lidar com o tráfego HTTP3 e apenas isso. Por exemplo, você poderia incorporar o Envoy Proxy - que suporta entrada HTTP3 - e configurá-lo para escutar apenas na porta 443/udp para tráfego h3, e transformar todas as requisições h3 recebidas em h2 ou h1.1 e encaminhar para a instância Nginx.
Um pouco de gambiarra, então não direi que é uma boa ideia.
2 curtidas
De qualquer forma que você decidir seguir, acho que o http3 é um bom passo e ajudará todo o ecossistema. Estou ansioso pelos próximos passos.
[Disclosure: Sou o gerente de comunidade da OpenSSL Foundation a partir de janeiro.]
Acontece que o OpenSSL 3.5 está programado para ser lançado em abril com suporte a servidor QUIC. Há também uma demonstração de um servidor HTTP3 que usa a API QUIC do OpenSSL com nghttp3.
(Como a questão da governança foi levantada nesse link, devo apontar que o OpenSSL adotou uma nova estrutura de governança no ano passado. Estou cautelosamente otimista e acho que isso ajudou a liberar o QUIC finalmente.)
Parece que o nginx adotará a API QUIC do OpenSSL. Ainda não há indicação de cronograma.
4 curtidas