预览版 NGINX QUIC+HTTP/3 实现的二进制包现已可用

[編輯： NGINX 现已通过 QUIC 正式支持 HTTP/3。它作为 NGINX 1.25.1 主线版本的一部分提供给开源用户，作为NGINX Plus R30 的一部分提供给企业客户。
[ngx_snippet 名称='table-style-blog']
我们很高兴地宣布，我们对 NGINX QUIC+HTTP/3 支持的预览实现现在可以作为两个发行版的预构建二进制包使用：

• Red Hat Enterprise Linux 9 及其二进制兼容版本
• Ubuntu 22.04

这些二进制文件是托管预览实现的单独nginx-quic repo 的quic分支的最新交付物。 自从我们开始在 NGINX 中开发 QUIC+HTTP/3以来，您仍然可以下载和构建NGINX 开源版本，其中包含 QUIC+HTTP/3 和支持 QUIC 的 SSL/TLS 库。虽然代码被标记为实验性的，但一些社区成员报告说他们在生产中成功使用了nginx-quic 。

我们发布预构建二进制文件的主要动机是更快、更轻松地使用 QUIC+HTTP/3 测试 NGINX。 二进制文件无需从源代码编译，可以使用标准包管理工具进行安装。

在撰写本文时，开源 SSL/TLS 的事实标准 OpenSSL 不支持 QUIC。因此，我们使用quictls库包构建二进制发行版，该包作为依赖项自动安装。 我们选择 quictls 是因为它目前代表了稳定性、兼容性和功能的最佳组合。

二进制分发的安装说明可在NGINX QUIC 网站上找到。

为 QUIC+HTTP/3 配置 NGINX

有几个新的指令可用于为 QUIC+HTTP/3 配置 NGINX，但可以很容易地将它们与现有虚拟服务器（ server{} ）配置块中的 HTTP/1.1 和 HTTP/2 指令结合起来。

对于最基本的功能配置，您所要做的就是在server{} （和子location{} ）块中包含三个指令：

以下是示例server{}块：

server { # 为了获得更好的兼容性，我们建议
# 对 QUIC 和 TCP 使用相同的端口号
listen 443 quic repeatport; # QUIC
listen 443 ssl; # TCP

ssl_certificate certs/example.com.crt;
ssl_certificate_key certs/example.com.key;
ssl_protocols TLSv1.3;

location / {
# 通告 QUIC 在配置的端口上可用
add_header Alt-Svc 'h3=":$server_port"; ma=86400';

#proxy_pass <上游组>; 
        ＃根       /<根目录>; 
}
}

有几个新的可选 HTTP/3 相关指令和变量（未在代码片段中显示），其中包括：

• $http3 – （变量）在 HTTP/3 会话期间发送请求时设置为h3 （否则为空字符串）。
• quic_retry –（指令）设置为on时，告诉 NGINX 向请求者发送一个 QUIC 重试消息，指定要使用的新连接 ID，以验证请求者的 IP 地址。 QUIC 重试数据包部分弥补了由于 QUIC 在 UDP 上运行而无法使用 TCP 三次连接握手来验证连接的事实。

• ssl_early_data –（指令）设置为on时，告诉 NGINX 在客户端通过新的 TLS 1.3 连接发送的第一个请求中接受应用数据（如果该客户端之前有连接）。 这被称为零往返时间（0-RTT）连接恢复。 支持发送“早期数据”是TLS 1.3的一项功能，通过消除 TLS 握手所需的额外往返消息交换，有助于提高 QUIC+HTTP/3 的性能。

  笔记： 0‑RTT 连接恢复可能会带来安全风险，因为如果早期数据包含GET以外的 HTTP 请求方法，则容易受到重放攻击。 有关详细信息，请参阅我们博客上发布 NGINX Plus R17中有关 TLS 1.3 的部分。

该图突出显示了使用 QUIC+HTTP/3 的 0-RTT 连接恢复如何提高性能，因为客户端在恢复与 NGINX 的 QUIC 连接时可以在其第一条消息中发送 HTTP 请求。相比之下，对于使用 TLS 的 TCP，客户端必须与 NGINX 执行新的 TLS 握手才能建立安全连接，代价是进行几次额外的往返。

有关所有新指令和变量的信息，请参阅3。 配置 部分 nginx-quic 自述。

使用 QUIC+HTTP/3 测试 NGINX

如前所述，我们发布预构建二进制文件的动机之一是更容易测试 NGINX 是否正确处理 HTTP/3 流量。 对于简单的命令行测试，您可以构建支持 HTTP/3 的curl或使用预构建的容器。 此外，大多数浏览器的较新版本都支持QUIC+HTTP/3。

要验证启用 QUIC 的站点是否满足来自浏览器的 HTTP/3 连接请求，您可以使用浏览器的开发人员工具检查 NGINX 返回的 HTTP 标头。如果 NGINX 在对浏览器通过 TCP 的初始 HTTP 请求的响应中包含上述Alt-Svc标头，则 QUIC+HTTP/3 实现正常运行。

此时，支持 QUIC 的浏览器会在Alt-Svc指令中指定的端口上建立 QUIC 连接，后续的 HTTP 请求和响应都通过 QUIC 进行。验证是否正在使用 QUIC+HTTP/3 的另一种方法是添加另一个add_header指令，将自定义 HTTP 标头的值设置为$server-protocol变量捕获的协议。 您可以跟踪标头的值，因为它从建立 QUIC 连接之前的HTTP/ 1.x变为使用 QUIC 时的HTTP/3.0 。

以下是自定义 HTTP 标头为X-protocol 的示例位置块：

location / { # 通告 QUIC 在配置的端口上可用 
add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 

# 发出信号表明我们是否正在使用 QUIC+HTTP/3
add_header X-protocol $server_protocol always; 

#proxy_pass <上游组>; 
    ＃根 /<根目录>; 
}

或者，还有像 Chrome HTTP Indicator扩展这样的工具，可以直观地指示正在使用的协议。 （请注意，这并不对任何浏览器扩展的认可，并且您必须确信，根据您的情况，扩展的任何可能的安全隐患都是可以接受的）。

下一步

我们将在未来几周内继续提供针对 QUIC+HTTP/3 的解决方案并提供更多 NGINX 优化的示例。 同时，请分享您自己的测试结果，以帮助我们做出决策。 您可以在NGINX 开发邮件列表和NGINX 社区 Slack上的#quic‑http3频道分享您的反馈。

要了解我们在 QUIC+HTTP/3 方面的工作的最新进展，包括下一个重要里程碑 - 将nginx-quic repo 合并到主线 NGINX 开源分支 - 请订阅NGINX 公告邮件列表。

观看网络研讨会

我们还鼓励您参加我们即将于 2023 年 4 月 19 日星期三举行的网络研讨会“亲身体验 NGINX 和 QUIC+HTTP/3” ：

• 北美– 太平洋标准时间上午 10:00
• 欧洲、中东和非洲地区 – 上午 11:00（中欧时间）
• APCJ – 新加坡时间上午 10:00