Discourse supporta già http3?
So che è principalmente un problema di rete, ma se eseguo Discourse su DigitalOcean, ad esempio, il container Docker in cui viene eseguito Discourse deve essere in grado di supportare http3
Non lo so, ma in che modo http3 aiuterebbe Discourse?
Al momento no
2 Mi Piace
Tecnicamente HTTP3 è solo un’altra versione del protocollo HTTP. Quindi, se qualcuno vuole offrire la propria istanza Discourse tramite HTTP3 oggi, può farlo mettendo un proxy HTTP inverso separato che supporta HTTP3 davanti alla propria istanza Discourse. Ciò è possibile senza modificare l’immagine Docker di Discourse.
Sto ipotizzando un po’, quindi prendi nota, ma sembra che l’immagine Docker utilizzi Nginx come proxy inverso per Discourse internamente. Vedo che Nginx supporta nativamente HTTP3, ma considera l’implementazione sperimentale per il momento. Forse è per questo che il supporto HTTP3 nell’immagine Docker non è implementato per il momento?
2 Mi Piace
Sì, è una funzionalità sperimentale, ma dai test su altri siti, si può vedere che è già abbastanza stabile per i progetti che scelgono la strada http3 oggi.
C’è qualche manutentore Docker per Discourse che ospiterei, se potessero aggiungere il supporto http3 come funzionalità opzionale, per i progetti interessati?
Un articolo molto interessante da cui puoi farti un’idea dei vantaggi di Discouse è qui What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
Ho una comprensione generale di HTTP/3 e so come e perché è utile con WordPress/LAMP, ma non capisco perché farebbe la differenza con Discourse.
Http3 riduce la latenza nella creazione di una connessione tra server e client fino a 150 ms. Inoltre, consente di risparmiare risorse del server, poiché la creazione della comunicazione http è più economica.
In questo modo l’utente avrà una migliore esperienza nella community e l’operatore del server avrà meno carico. Un vantaggio per tutti.
Al momento, purtroppo, no.
Ho mantenuto un branch del nostro container pronto per HTTP/3 dal (controlla appunti) 2019, che puoi trovare su GitHub - discourse/discourse_docker at http3.
Il motivo per cui non l’abbiamo implementato ampiamente è dovuto a una serie di problemi nell’ecosistema generale:
-
Lo sviluppo di Nginx ha subito un brusco rallentamento e non sta più tenendo il passo con le nuove tecnologie web, come HTTP/3 o Early Hints.
-
L’architettura modulare di Nginx significava che potevamo aggiungerlo tramite un modulo, e il mio branch utilizza il modulo nginx di Cloudflare, quiche, per questo. Ma anche Cloudflare si è allontanato da nginx e quel modulo non è mai stato considerato pronto per la produzione.
-
Ho considerato la migrazione a un web server più moderno, come Caddy, ma cambiamenti del genere sono estremamente difficili quando si rilascia software self-hosted che le persone personalizzeranno.
-
La migrazione a HAProxy sarebbe più facile da proporre, ma usiamo nginx per il serving di file statici, cosa che HAProxy non farà.
-
Il fatto che i manutentori di OpenSSL abbiano praticamente sabotato QUIC e interrotto il progresso dell’intero ecosistema per l’equivalente di un decennio.
Tutto quanto sopra, più tutti i problemi intrinseci del passaggio da TCP a UDP che ne fa parte, ha reso questo cambiamento troppo rischioso per noi.
Il che è molto triste, dato che nella media delle famiglie degli ultimi 4 anni, la maggior parte del traffico è già HTTP/3, poiché tutti i grandi player vi sono migrati anni fa, come YouTube, Amazon, Shopify, Instagram, Twitch.tv, ecc. Questo aumenta ulteriormente il divario tra la grande tecnologia e i piccoli siti, ed è un peccato che non siamo stati in grado di essere tra i primi ad adottarlo, come lo siamo stati con SPDY, HTTP/2 e Brotli.
Dato tutto ciò, se desideri una soluzione semplice con 1 clic per tutto questo pasticcio, puoi utilizzare Cloudflare di fronte alla tua istanza Discourse.
12 Mi Piace
Mi dispiace sentirlo. Ho alcune idee da esplorare. Possiamo discuterne?
- Prenderei in considerazione l’installazione di un modulo in Nginx, come ad esempio quello che consentirebbe http3
- Scriverei alla community di Discourse di Caddy e chiederei loro se potessero aiutarvi con la transizione a Caddy, potrebbe essere una partnership vantaggiosa per entrambi
QUIC is not supported - Help - Caddy Community
1 Mi Piace
Il modo più pulito per costruirlo, che ha il potenziale per essere qualcosa che potremmo eventualmente rilasciare, sarebbe aggiungere un nuovo template che sarebbe un’alternativa a web.ssl.template.yml, chiamiamolo web.ssl2.template.yml.
In questo template, invece di modificare nginx, avvia un web server alternativo, diciamo Caddy, che gestisce tutto il traffico e inoltra a nginx. Ciò consentirebbe molta sperimentazione, la possibilità di testare più web server e potrebbe potenzialmente evolversi in qualcosa che potremmo rendere predefinito per le nuove installazioni.
4 Mi Piace
Ottimo. Mi piacerebbe essere coinvolto nel testing. Quali sono i prossimi passi?
2 Mi Piace
Fare il lavoro 
5 Mi Piace
Un altro approccio sarebbe aggiungere all’immagine Docker un proxy HTTP dedicato per gestire il traffico HTTP3 e solo quello. Ad esempio, potresti incorporare Envoy Proxy - che supporta l’ingress HTTP3 - e configurarlo per ascoltare solo sulla porta 443/udp per il traffico h3, e trasformare tutte le richieste h3 in ingresso in h2 o h1.1 e inoltrarle all’istanza Nginx.
Un po’ un hack, quindi non direi che sia una buona idea.
2 Mi Piace
Qualunque sia la strada che deciderai di percorrere, penso che http3 sia un buon passo e aiuterà l’intero ecosistema. Attendo con impazienza i prossimi passi.
[Disclosure: Sono il community manager della OpenSSL Foundation da gennaio.]
A quanto pare, OpenSSL 3.5 è previsto per il rilascio ad aprile con supporto server QUIC. Esiste anche una demo di un server HTTP3 che utilizza l’API QUIC di OpenSSL con nghttp3.
(Poiché la questione della governance è stata sollevata in quel link, dovrei far notare che OpenSSL ha adottato una nuova struttura di governance l’anno scorso. Sono cautamente ottimista e penso che abbia aiutato a far uscire QUIC finalmente.)
Sembra che nginx adotterà l’API QUIC di OpenSSL. Non ci sono ancora indicazioni sulla tempistica, tuttavia.
4 Mi Piace