Discourse 是否已支持 http3？
我知道这主要是一个网络问题，但如果我在 DigitalOcean 上运行 Discourse，例如，Discourse 运行的 Docker 容器必须支持 http3。
我不知道，但 http3 如何能帮助 Discourse？
目前不支持
2 个赞
从技术上讲，HTTP3 只是 HTTP 协议的另一个版本。因此，如果有人想在今天通过 HTTP3 提供他们的 Discourse 实例，他们可以通过在 Discourse 实例前面放置一个支持 HTTP3 的独立反向 HTTP 代理来实现。这可以在不更改 discourse docker 镜像的情况下完成。
我在这里只是猜测，所以请注意这一点，但似乎 docker 镜像内部使用 Nginx 作为 Discourse 的反向代理。我看到 Nginx 原生支持 HTTP3，但目前认为该实现仍处于实验阶段。也许这就是为什么目前在 docker 镜像中不支持 HTTP3 的原因？
2 个赞
是的，这是一项实验性功能，但根据在其他网站上的测试，对于今天选择 http3 路线的项目来说，它已经足够稳定。
是否有 Discourse 的 Docker 维护者，如果我托管，他们是否可以添加 http3 支持作为一项可选功能，供对此感兴趣的项目使用？
您可以在这里找到一篇关于 HTTP/3 的非常有用的文章，从中可以了解其优势：What Is HTTP/3 and How Does It Differ from HTTP/2? | Gcore
我对 HTTP/3 有大致的了解，并且知道它在 WordPress/LAMP 中的作用和优势，但我不太明白为什么它对 Discourse 会有区别。
Http3 通过将服务器与客户端之间的连接建立延迟最多降低 150 毫秒来减少延迟。此外，由于建立 http 通信更经济，因此可以节省服务器资源。
这样用户将获得更好的社区体验，服务器运营商的负载也会减轻。双赢。
目前还不支持，很遗憾。
我从（查阅笔记）2019 年开始就一直维护着一个容器化的 HTTP/3 就绪分支，你可以在 GitHub - discourse/discourse_docker at http3 查看。
我们没有广泛推广它的原因是整体生态系统存在一系列问题：
-
Nginx 的开发速度慢了下来，他们不再跟进新的网络技术，比如 HTTP/3 或早期提示（Early Hints）。
-
Nginx 的模块化架构意味着我们可以通过模块添加它，我的分支使用了 Cloudflare 的 nginx 模块 quiche 来实现。但 Cloudflare 也已经放弃了 nginx，并且该模块从未被认为适合生产环境。
-
我考虑过迁移到更现代的 Web 服务器，比如 Caddy，但当你发布人们会自定义的自托管软件时，这样的更改非常困难。
-
迁移到 HAProxy 会更容易接受，但我们使用 nginx 来提供静态文件服务，而 HAProxy 无法做到这一点。
-
OpenSSL 维护者基本上破坏了 QUIC，并让整个生态系统的进展停滞了大约十年。
以上所有原因，加上 TCP → UDP 迁移固有的所有问题，都意味着这个改变对我们来说风险太大了。
这非常令人遗憾，因为在过去四年里，普通家庭的大部分流量已经是 HTTP/3 了，因为像 YouTube、Amazon、Shopify、Instagram、Twitch.tv 等所有大公司多年前就已经迁移到它了。这进一步加大了科技巨头和小网站之间的差距，很可惜我们未能像 SPDY、HTTP/2 和 Brotli 那样成为早期采用者。
考虑到所有这些，如果你想要一个简单的“一键式”解决方案来解决这个混乱的问题，可以在你的 Discourse 实例前面使用 Cloudflare。
12 个赞
听到这个消息我很难过。我有一些想法可以探讨。我们可以讨论一下吗？
- 我会考虑在 Nginx 中安装一个模块，例如允许 http3 的模块
- 我会写信给你的 Discourse 所属的 Caddy 社区，问他们是否能帮助你过渡到 Caddy，这可能是一个双赢的合作
QUIC is not supported - Help - Caddy Community
1 个赞
最干净的构建方式，并且有潜力最终发布，就是添加一个新模板，作为 web.ssl.template.yml (discourse_docker/templates/web.ssl.template.yml at main · discourse/discourse_docker · GitHub) 的替代方案，我们称之为 web.ssl2.template.yml。
在此模板中，它不修改 nginx，而是启动一个替代的 Web 服务器，比如 Caddy，它处理所有流量并代理到 nginx。这将允许大量的实验，测试多个 Web 服务器的能力，并可能发展成我们可以为新安装设置的默认选项。
4 个赞
太好了。我很想参与测试。下一步是什么？
2 个赞
开始工作 
5 个赞
另一种方法是在 Docker 镜像中添加一个专用的 HTTP 反向代理来处理 HTTP3 流量，仅此而已。例如，您可以嵌入 Envoy Proxy（支持 HTTP3 入站）并将其配置为仅在 443/udp 端口上侦听 h3 流量，然后将所有传入的 h3 请求转换为 h2 或 h1.1 并转发到 Nginx 实例。
不过，这有点像一种 hack，所以不能说是个好主意。
2 个赞
无论您决定如何选择，我认为 http3 都是一个不错的选择，它将有助于整个生态系统。我期待着下一步。
[披露：我从一月开始就是OpenSSL 基金会社区经理。]
事实证明，OpenSSL 3.5 计划于四月发布并支持 QUIC 服务器。还有一个HTTP3 服务器演示，它使用 OpenSSL QUIC API 和nghttp3。
（鉴于该链接中提到了治理问题，我应该指出 OpenSSL 在去年采用了新的治理结构。我谨慎乐观，并且我认为这最终有助于 QUIC 的推出。）
看起来nginx 将采用 OpenSSL 的 QUIC API。但目前还没有时间表。
4 个赞