Unterstützt Discourse bereits http3?
Ich weiß, dass es sich hauptsächlich um ein Netzwerkproblem handelt, aber wenn ich Discourse zum Beispiel auf DigitalOcean ausführe, muss der Docker-Container, in dem Discourse läuft, http3 unterstützen.
Ich weiß es nicht, aber wie würde http3 Discourse helfen?
Derzeit nicht
2 „Gefällt mir“
Technisch gesehen ist HTTP3 nur eine weitere Version des HTTP-Protokolls. Wenn also jemand seine Discourse-Instanz heute über HTTP3 anbieten möchte, kann er dies tun, indem er einen separaten Reverse-HTTP-Proxy, der HTTP3 unterstützt, vor seine Discourse-Instanz schaltet. Dies ist ohne Änderung des Discourse-Docker-Images möglich.
Ich rate hier ein wenig, also mit Vorbehalt, aber es scheint, dass das Docker-Image Nginx als Reverse-Proxy für Discourse intern verwendet. Ich sehe, dass Nginx HTTP3 nativ unterstützt, es aber derzeit als experimentelle Implementierung betrachtet. Vielleicht ist das der Grund, warum die HTTP3-Unterstützung im Docker-Image derzeit nicht implementiert ist?
2 „Gefällt mir“
Ja, es ist eine experimentelle Funktion, aber aus Tests auf anderen Websites kann man sehen, dass sie bereits stabil genug für Projekte ist, die sich heute für den http3-Weg entscheiden.
Gibt es einen Docker-Maintainer für Discourse, den ich hosten würde, wenn er http3-Unterstützung als optionale Funktion für Projekte hinzufügen könnte, die daran interessiert sind?
Ein sehr schöner Artikel, der Ihnen eine Vorstellung von den Vorteilen von Discouse vermitteln kann, finden Sie hier What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
Ich habe ein allgemeines Verständnis von HTTP/3 und weiß, wie und warum es mit WordPress/LAMP nützlich ist, aber ich verstehe nicht, warum es bei Discourse einen Unterschied machen würde.
Http3 reduziert die Latenz bei der Herstellung einer Verbindung zwischen Server und Client um bis zu 150 ms. Außerdem spart es Serverressourcen, da der Aufbau einer HTTP-Kommunikation wirtschaftlicher ist.
So hat der Benutzer ein besseres Community-Erlebnis und der Serverbetreiber weniger Last. Win-Win
Im Moment leider nicht.
Ich habe seit (prüft Notizen) 2019 einen Branch unseres Containers HTTP/3-ready gehalten, den Sie unter GitHub - discourse/discourse_docker at http3 einsehen können.
Der Grund, warum wir das nicht flächendeckend eingeführt haben, liegt an einer Reihe von Problemen im gesamten Ökosystem:
-
Die Entwicklung von Nginx kam stark ins Stocken, und sie halten mit neuen Webtechnologien wie HTTP/3 oder Early Hints nicht mehr Schritt.
-
Nginx’ modulare Architektur bedeutete, dass wir es über ein Modul hinzufügen konnten, und mein Branch verwendet Cloudflares Nginx-Modul, quiche, dafür. Aber Cloudflare hat sich ebenfalls von Nginx abgewandt, und dieses Modul wurde nie als produktionsreif angesehen.
-
Ich habe erwogen, zu einem moderneren Webserver wie Caddy zu wechseln, aber Änderungen wie diese sind extrem schwierig, wenn man selbst gehostete Software veröffentlicht, die die Leute anpassen werden.
-
Ein Wechsel zu HAProxy wäre leichter zu verkaufen, aber wir verwenden Nginx für die Bereitstellung statischer Dateien, was HAProxy nicht kann.
-
Die Tatsache, dass die OpenSSL-Maintainer QUIC im Grunde sabotiert und den Fortschritt des gesamten Ökosystems für das Äquivalent eines Jahrzehnts gestoppt haben.
All das oben Genannte, plus all die inhärenten Probleme des TCP → UDP-Wechsels, der Teil davon ist, bedeuteten, dass diese Änderung für uns zu riskant war.
Was sehr schade ist, da im Durchschnittshaushalt der letzten 4 Jahre der meiste Traffic bereits HTTP/3 ist, da jeder große Player vor Jahren darauf umgestiegen ist, wie YouTube, Amazon, Shopify, Instagram, Twitch.tv usw. Dies vergrößert die Kluft zwischen Big Tech und kleinen Websites weiter, und es ist eine Schande, dass wir hier nicht zu den frühen Anwendern gehören konnten, wie wir es bei SPDY, HTTP/2 und Brotli waren.
Angesichts all dessen, wenn Sie eine einfache 1-Klick-Lösung für dieses ganze Durcheinander wünschen, können Sie Cloudflare vor Ihre Discourse-Instanz schalten.
12 „Gefällt mir“
Es tut mir leid, das zu hören. Ich habe ein paar Ideen, die wir untersuchen könnten. Können wir sie besprechen?
- Ich würde in Erwägung ziehen, ein Modul in Nginx zu installieren, das HTTP/3 ermöglicht.
- Ich würde mich an die Caddy-Community wenden, die Ihr Discourse betreibt, und sie fragen, ob sie Ihnen bei der Umstellung auf Caddy helfen könnten. Das könnte eine für beide Seiten vorteilhafte Partnerschaft sein
QUIC is not supported - Help - Caddy Community
1 „Gefällt mir“
Der sauberste Weg, dies zu tun, der das Potenzial hat, etwas zu werden, das wir schließlich ausliefern könnten, wäre das Hinzufügen einer neuen Vorlage, die eine Alternative zu web.ssl.template.yml wäre, nennen wir sie web.ssl2.template.yml.
In dieser Vorlage startet anstatt nginx einen alternativen Webserver, sagen wir Caddy, der den gesamten Traffic abwickelt und an nginx weiterleitet. Dies würde viel Experimentieren, die Möglichkeit, mehrere Webserver zu testen, ermöglichen und könnte sich potenziell zu etwas entwickeln, das wir zum Standard für neue Installationen machen könnten.
4 „Gefällt mir“
Klingt großartig. Ich würde mich gerne am Testen beteiligen. Was sind die nächsten Schritte?
2 „Gefällt mir“
Die Arbeit machen 
5 „Gefällt mir“
Ein anderer Ansatz wäre, dem Docker-Image einen dedizierten HTTP-Reverse-Proxy hinzuzufügen, der nur den HTTP3-Verkehr verarbeitet. Sie könnten zum Beispiel Envoy Proxy einbetten – der HTTP3-Ingress unterstützt – und ihn so konfigurieren, dass er nur auf Port 443/udp für H3-Verkehr lauscht und alle eingehenden H3-Anfragen in H2 oder H1.1 umwandelt und an die Nginx-Instanz weiterleitet.
Allerdings ist das eher ein Hack, daher ist es keine gute Idee.
2 „Gefällt mir“
Welchen Weg Sie auch wählen, ich denke, HTTP/3 ist ein guter Schritt und wird dem gesamten Ökosystem helfen. Ich freue mich auf die nächsten Schritte.
[Offenlegung: Ich bin seit Januar der Community Manager der OpenSSL Foundation.]
Wie sich herausstellt, wird OpenSSL 3.5 im April mit QUIC-Serverunterstützung veröffentlicht. Es gibt auch eine Demo eines HTTP3-Servers, der die OpenSSL QUIC API mit nghttp3 verwendet.
(Da die Frage der Governance in diesem Link aufgeworfen wurde, möchte ich darauf hinweisen, dass OpenSSL letztes Jahr eine neue Governance-Struktur angenommen hat. Ich bin vorsichtig optimistisch und denke, dass es geholfen hat, QUIC endlich auf den Weg zu bringen.)
Es scheint, dass nginx die QUIC-API von OpenSSL übernehmen wird. Es gibt jedoch noch keine Angaben zum Zeitplan.
4 „Gefällt mir“