Discourseはすでにhttp3をサポートしていますか？
主にネットワークの問題であることは承知していますが、たとえばDigitalOceanでDiscourseを実行する場合、Discourseが実行されているDockerコンテナがhttp3をサポートできる必要があります。
わかりませんが、http3 は Discourse にどのように役立ちますか？
現時点ではサポートしていません
「いいね！」 2
技術的にはHTTP3はHTTPプロトコルの単なる別のバージョンです。そのため、DiscourseインスタンスをHTTP3経由で提供したい場合は、Discourseインスタンスの前にHTTP3をサポートする別のリバースHTTPプロキシを配置することで実現できます。これは、DiscourseのDockerイメージを変更せずに可能です。
これは私の推測ですが、Dockerイメージは内部的にDiscourseのリバースプロキシとしてNginxを使用しているようです。NginxはHTTP3をネイティブでサポートしていますが、現時点では実装を実験的なものと見なしています。おそらく、それが現時点でDockerイメージでHTTP3サポートが実装されていない理由かもしれません。
「いいね！」 2
はい、実験的な機能ですが、他のサイトでのテストから、今日すでにHTTP/3ルートを選択するプロジェクトにとって十分に安定していることがわかります。
もし私がホストするDiscourseのDockerメンテナーがいて、興味のあるプロジェクトのために、オプション機能としてHTTP/3サポートを追加できれば、それは可能でしょうか？
Discourseのメリットを把握できる、非常に良い記事はこちらです: What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
HTTP/3の概要は理解しており、WordPress/LAMPでどのように役立つかはわかっていますが、Discourseでなぜ違いが出るのか理解できません。
Http3は、サーバーとクライアント間の接続確立時のレイテンシを最大150ミリ秒短縮します。さらに、http通信の確立がより経済的であるため、サーバーリソースを節約できます。
これにより、ユーザーはより良いコミュニティ体験を得られ、サーバーオペレーターの負荷は軽減されます。Win-Winです。
残念ながら、現時点ではサポートしていません。
(注を確認) 2019年からコンテナをHTTP/3対応にしたブランチを保持しており、GitHub - discourse/discourse_docker at http3 で確認できます。
広く展開していない理由は、エコシステム全体における一連の問題です。
-
Nginx の開発は停滞しており、HTTP/3 や Early Hints のような新しいウェブ技術に追随していません。
-
Nginx のモジュール式アーキテクチャにより、モジュール経由で追加でき、私のブランチでは Cloudflare の nginx モジュールである quiche を使用しています。しかし、Cloudflare も nginx から離れており、そのモジュールは本番環境で利用できるとは考えられていませんでした。
-
よりモダンなウェブサーバー、例えば Caddy への移行を検討しましたが、人々がカスタマイズするセルフホスト型ソフトウェアをリリースする場合、そのような変更は非常に困難です。
-
HAProxy への移行はより受け入れられやすいでしょうが、静的ファイルサービングには nginx を使用しており、HAProxy はそれを実行できません。
-
OpenSSL のメンテナーが QUIC を実質的に 妨害 し、エコシステム全体の進捗を 10 年分ほど停止させたという事実。
上記すべてに加えて、TCP から UDP への移行に伴う固有の問題も含まれており、この変更は私たちにとってリスクが高すぎました。
過去 4 年間の平均的な家庭では、YouTube、Amazon、Shopify、Instagram、Twitch.tv など、すべての主要プレイヤーが数年前に移行しているため、トラフィックのほとんどが既に HTTP/3 であることを考えると、これは非常に残念です。これにより、ビッグテックと小規模サイトの格差がさらに広がり、SPDY、HTTP/2、Brotli で早期採用者であったにもかかわらず、ここで早期採用者になれなかったのは残念です。
これらすべてを考慮すると、この問題全体を簡単に 1 クリックで解決したい場合は、Discourse インスタンスの前面に Cloudflare を使用できます。
「いいね！」 12
それを聞いて残念です。いくつか検討すべきアイデアがあります。話し合ってもよろしいでしょうか？
- HTTP/3を可能にするようなモジュールをNginxにインストールすることを検討します。
- Caddyコミュニティに、あなたのDiscourseが動いていることを伝え、Caddyへの移行を手伝ってもらえないか尋ねます。これはWin-Winの関係になるかもしれません
QUIC is not supported - Help - Caddy Community
「いいね！」 1
最もクリーンな構築方法は、最終的に出荷できる可能性のある新しいテンプレートを追加することです。これは web.ssl.template.yml の代替となるもので、web.ssl2.template.yml と呼びましょう。
このテンプレートでは、nginx を変更する代わりに、Caddy のような代替ウェブサーバーを起動し、すべてのトラフィックを処理して nginx にプロキシします。これにより、多くの実験が可能になり、複数のウェブサーバーをテストでき、新しいインストールでデフォルトにできる可能性のあるものに進化する可能性があります。
「いいね！」 4
素晴らしいですね。テストに参加したいです。次のステップは何ですか？
「いいね！」 2
作業中です 
「いいね！」 5
HTTP3トラフィックのみを処理する専用のHTTPリバースプロキシをDockerイメージに追加するというアプローチもあります。例えば、Envoy Proxyを組み込み、HTTP3インバウンドをサポートし、ポート443/udpでh3トラフィックのみをリッスンするように設定し、すべての着信h3リクエストをh2またはh1.1に変換してNginxインスタンスに転送することができます。
ただし、少しハッキーなアプローチなので、良いアイデアとは言えません。
「いいね！」 2
どちらの方向へ進むにしても、http3 は良い一歩であり、エコシステム全体に役立つと思います。次のステップを楽しみにしています。
[開示：私は1月からOpenSSL Foundationのコミュニティマネージャーです。]
実際、OpenSSL 3.5は4月にQUICサーバーサポートを伴ってリリースされる予定です。nghttp3を使用したOpenSSL QUIC APIを使用するHTTP3サーバーのデモもあります。
（あのリンクでガバナンスの問題が提起されたので、OpenSSLは昨年新しいガバナンス構造を採用したことを指摘しておくべきでしょう。私は慎重に楽観的であり、QUICがついにリリースされるのに役立ったと思います。）
nginxがOpenSSLのQUIC APIを採用するようです。ただし、タイムラインについてはまだ示されていません。
「いいね！」 4