Curl HTTP/3 性能

原文 ↗ Hacker News 讨论 ↗

curl 新的 HTTP/3/QUIC 支持基准测试显示，在 localhost 上的原始吞吐量目前落后于 HTTP/1.1 和 HTTP/2，这凸显了 QUIC 更高的 CPU 成本以及高度优化的 TCP 栈的成熟度。评论者指出，这些测试主要衡量的是效率，而不是在延迟和丢包条件下的真实世界性能；在那种情况下，HTTP/3 可以通过更好的多路复用、拥塞控制和连接迁移表现出优势。讨论串还涉及实现细节（OpenSSL QUIC、缺少 UDP GSO、Caddy 和 Debian 打包）、HTTP/3 的安全与证书要求，以及关于新协议代码使用 C 还是 Rust 的更广泛问题。

HTTP/3 / QUIC 性能对比 HTTP/1.1 和 HTTP/2

  • 基准测试显示，在 localhost 上，HTTP/1.1 吞吐量最高，HTTP/2 较慢，HTTP/3 更慢。
  • 一些读者对此感到惊讶或担忧；另一些人强调，这测量的是回环（loopback）上的 CPU 效率，而不是真实网络性能。
  • 多条评论强调，HTTP/2/3 的目标是延迟、多路复用以及在丢包下的行为，而不是纯带宽。
  • 线程中引用的真实世界研究据称显示，在互联网条件下，HTTP/3 的吞吐量优于 HTTP/2。

CPU 效率 vs 网络行为

  • 大家普遍承认，QUIC 在本质上比 TCP+TLS 更不节省 CPU。
  • 讨论的原因包括：逐包加密、许多较小的 UDP 包、更多用户态的包组装与加密工作，以及更复杂的连接/流记账。
  • 一项实验表明，由于缺乏成熟的硬件卸载，以及长期以来 TCP 内核/NIC 优化的积累，QUIC 对某些高吞吐服务器工作负载来说，效率大约低一个数量级。

基准测试设置与实现成熟度

  • 该测试很可能运行在 localhost 上，并使用了相对较旧的 Caddy / quic-go 栈，未启用 GSO，UDP 缓冲区调优也不理想。
  • 有人认为这不公平地惩罚了 QUIC，而偏袒了高度调优的 TCP 栈。
  • 另一些人指出，HTTP/1.1 被给了 50 个并行 TCP 连接，而真实浏览器通常远少于这个数。

协议权衡：并行性、HOL 阻塞与连接

  • 讨论集中在 HTTP/1.1 是否“有”队头阻塞：这是协议本身的问题，还是实际限制（浏览器连接上限、连接建立成本）的问题。
  • HTTP/2/3 的多路复用被视为解决并行性和 HOL 问题的方案，但也有人认为，多条 TCP 连接已经可以提供很高的性能。
  • 还讨论了 TCP 64k 端口/连接限制，以及多 IP、DSR 和 SO_REUSEPORT 等技术；这些都依赖具体场景，而且颇具争议。

部署问题与实现（curl、nginx、Debian、Caddy）

  • curl 维护者正朝着启用 HTTP/3（通过 GnuTLS 或 OpenSSL QUIC）的方向推进，并在考虑 WebSocket 支持，但这些仍属实验性。
  • 有人报告 nginx 的 HTTP/2（尤其在 Kubernetes 中）存在严重延迟问题，改回 HTTP/1.1 后得到修复；也有人表示 nginx 对非 H1 的支持很弱。
  • Debian 中的 Caddy 版本被批评过时且补丁不足；“稳定”打包与及时的安全/性能修复之间存在张力。

安全、证书与“人类化的 Web”

  • HTTP/3 强制 TLS，且没有 null cipher / 无 TLS 模式，这让自签名和业余项目站点感到担忧。
  • 一些人担心，对公共 CA 和浏览器政策的依赖会进一步边缘化自托管、非企业站点，相比之下，TOFU/自签名工作流会受到压制。

语言与实现选择（C vs Rust）

  • 有人对新的 QUIC 代码仍然用 C 编写感到失望，尽管已有 Rust 的 QUIC 实现，且 curl 之前也用过 Rust。
  • 反方观点是：Rust 工具链并不适用于或未被验证于许多小众和嵌入式架构；Rust 的二进制体积和构建成本更高；生态成熟度与目标覆盖范围仍是现实约束。