原文作者： Liam Crill - F5 产品管理总监
发布时间：2020 年 6 月 10 日
原文链接：支持 QUIC 和 HTTP/3 的 NGINX 技术预览版上线
转载来源：NGINX 中文官网

注记：QUIC的协议规范已经在2021年5月27日定稿，欲了解NGINX最新针对 QUIC 和 HTTP/3 的产品路线，请点击“阅读原文”阅读我们的最新英文博客文章。

很高兴宣布NGINX支持 QUIC+HTTP/3的预览版本正式发布。该预览版实现了IETF QUIC 草案规范，并由独立的开发分支维护，与稳定分支及主线分支隔离。经过几个月的初步开发，该版本已可进行互操作性测试，并接受意见反馈和代码贡献了。

官方同时提供了一个基于NGINX QUIC+HTTP/3实现的演示站点：https://quic.nginx.org/。

HTTP/3 的前世今生

当今世界瞬息万变，但超文本传输协议 (HTTP) 却在过去二十多年里始终未曾改变。HTTP/1.1 标准发布于 1999 年，现已成为 Web 应用和 API 普遍使用的传输协议。在协议发布后的21 年里，虽然应用和服务都发生了翻天覆地的变化，但协议本身仍未有变。

有的读者可能会问，“不是已推出了 HTTP/2 吗？”。这个问题问得好。HTTP/2 标准发布于 2015 年，目前已经有 45% 的面向互联网的网站采用了 HTTP/2。然而，此统计数据掩盖了这样一个事实，即 HTTP 在公共互联网与在“最后一英里”（运行时基础架构）上的使用有很大不同。

事实上，HTTP/2 很少被端到端地部署到现代互联网基础架构中。HTTP/2 的目的是解决公共互联网中最突出的一些问题，例如延迟过长且难以预测，以及一旦一个 HTTP 请求出现问题，后续请求就都可能会出现延迟。

然而，在应用运行环境内部（例如公有云或私有数据中心），网络延迟低且可靠性高，基于文本传输的HTTP/1.1在可检测方面比基于流的HTTP/2更好，因此HTTP/2并不占优势。

HTTP/2 非常适用于客户端到运行时基础架构的“边缘”环境，其很大程度改善了浏览器和移动设备的用户体验。此时，HTTP/2请求通常会被代理到使用 HTTP/1.1 的内部运行时环境中。边缘很可能是 CDN 提供商，或是负责入口流量处理的反向代理负载均衡器。

两大 HTTP 版本的典型混合部署

既然这种混合使用 HTTP/2 和 HTTP/1.1 来交付网站和应用的方法效果很好，那么为什么要提出去开发另一新协议 HTTP/3 呢？

HTTP/2 的主要创新在于使用 TCP 作为底层传输时，利用单个连接的多路复用方式处理HTTP请求。然而，TCP 本身固有的局限性，限制了网站和应用的性能及用户体验。

TCP 标准首次发布于 1981 年，作为通用传输协议取得了巨大成功。但是，当您通过同一连接多路复用多个独立请求时，它们都会受限于该连接的可靠性。只要有一个请求的数据包丢失，所有多路复用请求都会延迟，直到检测到丢失的数据包，然后重新传输。

HTTP/3 基于 QUIC 传输协议，该协议专门用于支持多路复用连接，并摆脱了对单个 TCP 连接的依赖。QUIC 使用 UDP 作为在客户端和服务器之间的数据包底层传输机制，并为HTTP 请求提供可靠连接。值得注意的是，QUIC 还将 TLS作为内置组件，而不是像 HTTP/1.1 和 HTTP/2 那样作为附加层。

HTTP 传输栈简要概述

QUIC 的目标是为 HTTP/3 提供高性能、高可靠性、高安全性的传输协议（尽管 QUIC 也适用于非 HTTP 流量）。从语义上讲，HTTP/3 本身与 HTTP/2 非常相似。然而，在没有明确的 HTTP 版本指定时，网站地址https://www.example.com可能同时支持HTTP/1.1、HTTP/2 和 HTTP/3版本中的一个或多个，此时客户端（或Web 浏览器）如何知道使用哪个 HTTP 版本？

版本识别问题最初随着 HTTP/2 的发布而出现，为了解决这个问题，开发人员使用 TLS 握手机制来检测客户端和服务器能否通过 HTTP/2 通信。这样，客户端早在连接建立之前就知道如何与服务器对话。然而，QUIC 使用 UDP（代替 TCP）作为底层传输协议也产生了新的问题，即客户端如何知道初始请求应该建立哪种类型的连接，TCP 还是 UDP？

解决方法是让客户端为初始 HTTP 请求建立 TCP 连接。支持 HTTP/3 的服务器返回信息会包含 Alt-Svc Header，同时Alt-Svc还可指定监听 HTTP/3 流量的 UDP 端口。此外，浏览器还会记住哪些站点支持 QUIC，以减少频繁使用 Alt-Svc 方式探测QUIC协议支持与否带来的开销。

NGINX QUIC+HTTP/3 预览版

今天我们正式推出了支持QUIC 和 HTTP/3的NGINX初始版本 — http_v3_module。该版本为技术预览版，仅供实验使用，不适用于生产环境。在撰写本文时，QUIC 标准尚未定稿，此初始版本根据当前草案的子集实现。

经过数月的设计和开发，http_v3_module 现在已经可以进行互操作性测试了。我们也非常欢迎大家提供反馈意见并贡献代码。请注意，NGINX 开源主线开发分支（以及任何版本的 NGINX Plus）暂不提供 http_v3_module，它仍然是实验版本，并位于专门的开发分支中：https://hg.nginx.org/nginx-quic。

另请注意，此 QUIC+HTTP/3 实现是全新的，与 Cloudflare quiche 项目提供的补丁无关。

对于熟悉 NGINX 配置的人来说，QUIC+HTTP/3 的启用过程非常简单。

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 http3 reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'h3=":443"';   # Advertise that HTTP/3 is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

有关从 nginx-quic 源码库构建 NGINX 的更多信息和推荐配置，请参阅README。此外，http_v3_module 的演示站点请参见 https://quic.nginx.org/。

您也可以通过访问该网站检查您的浏览器是否支持 QUIC，并将 HTTP/3 互操作性与自己构建的 nginx-quic 进行比较。由于 QUIC 标准尚未定稿，您可能需要使用常用浏览器的开发版本或最新版本启用 QUIC 连接。

感谢试用 nginx-quic，期待您的反馈：

● 如果您有任何意见或建议，请在下方的评论区告诉我们，或发送到 NGINX 邮件列表；

● 如果您遇到错误或异常行为，或者需要故障定位帮助，请将您的消息发送到 NGINX 邮件列表（NGINX 研发团队会予以密切关注）。