HTTP/2 和 HTTP/3 解释

原文 ↗ Hacker News 讨论 ↗

HTTP/1.1 管线化与中间盒

  • 从规范上说，HTTP/1.1 允许在前一个响应到达之前，在一条 TCP 连接上发送多个请求。
  • 多位评论者表示，这在实践中“从来没真正工作过”：损坏的代理、杀毒软件 MITM 和中间盒会破坏或交错响应。
  • 因此，尽管理论上正确，浏览器还是在很大程度上放弃了管线化。

队头阻塞、复用与性能

  • 澄清一下：在 HTTP/1.1 中，你可以发送多个请求，但通常必须等前面的响应先返回，后面的请求才能被使用。
  • 浏览器会限制每个来源的并发 TCP 连接数（历史上很少，后来大约在 ~6–10），这会造成阻塞。
  • 有人认为 HTTP/2 的单连接复用会在 TCP 层 产生队头阻塞：一个流上的丢包可能会拖住其他流。
  • 也有人反驳说，多个 HTTP/1.1 连接也有自己的缺点（握手、慢启动、内核限制）。

HTTP/2 的实际表现

  • 看法分裂：
    • 正面：在典型连接上通常更快；设计更简洁（所有元数据都作为 header、stream、HPACK）；对 RPC 和许多 Web 工作负载表现良好。
    • 负面：有人报告在移动端加载时间慢 5–25%，尤其是在高延迟/丢包以及交互式 + 懒加载场景下。相关数据被提及但未公开，引发了“凭经验”与“证据不足”的争论。
  • server push 被广泛视为失败特性；主流浏览器已经移除了它。

HTTP/3 / QUIC 与 UDP

  • HTTP/3/QUIC 因连接迁移和更好的丢包处理，被宣传适合不稳定/移动网络。
  • 一位评论者说，在卫星链路上，HTTP/3 比 HTTP/1.1 + 卫星 “PEP” 表现更差。
  • 有人提出对 QUIC 在 UDP 上的 DDoS 含义的担忧，以及关于“QUIC over TCP”的提议，认为这说明现实中存在摩擦。
  • 讨论还涉及为什么 UDP 没有被更好地优化：硬件和操作系统里的 TCP offload（分段、聚合）并不能干净地迁移到 UDP。

复杂性与收益

  • 有人认为，如果 HTTP/2/3 的实现复杂度和成本都高于 HTTP/1.1，那它们就是个错误。
  • 也有人回应说，当少数实现要服务数十亿用户时，这种复杂性是合理的，而且 HTTP/3 实际上把 TCP+TLS+HTTP 折叠进了一层协议栈，总体复杂度也差不多。
  • 对于现代云平台上的应用开发者来说，HTTP/3 通过托管负载均衡器可以是“免费的”。

TLS、CA，以及寿命 / 审查

  • 对 HTTP/3 强制使用基于 CA 的 TLS 存在强烈分歧：
    • 支持方：不安全/明文或自签名部署不应暴露到公网；用户安全和隐私比便利更重要。
    • 反对方：依赖 CA 会损害长期可用性（证书过期、ACME 脆弱），将审查权力集中化，并阻碍简单的个人网站；自签名或明文应该仍然可行（但要有警告）。
  • 关于只读内容是否总是需要加密也存在争论；反对者指出，在敌对司法辖区中的监控是需要加密的原因之一。

使用场景与“HTTP/2/3 为谁服务”

  • 一位评论者认为，HTTP/2/3 主要解决的是由大型广告和 CDN 公司驱动的、充满广告和多域名页面的问题，而不是简单的文本获取。
  • 他们声称，对于单域名的文本获取，HTTP/1.1 管线化仍然更优；其他人对此表示不同意，但没有提供反向基准测试。
  • 一个关于在不同浏览器/HTTP 版本下加载大量图片的小测试显示了不同的并行度和排序，突出实现差异。

更高层的复用 vs. SCTP

  • 另一个未解决的问题是：为什么 HTTP/2/3 的复用是在应用层（运行在 TCP/UDP 之上）完成的，而不是直接使用 SCTP。
  • 线程提出了这个问题，但没有给出明确答案。