宣布推出 NGINX Plus R31

我们很高兴地宣布 NGINX Plus Release 31 (R31) 已经推出。 NGINX Plus 基于 NGINX 开源，是唯一集 Web 服务器、负载均衡器、反向代理、内容缓存和 API 网关于一体的软件。

NGINX Plus R31 的新增功能和增强功能包括：

• 原生 NGINX 使用情况报告- NGINX Plus 现在原生支持报告整个组织的 NGINX 部署情况，从而可以在 NGINX 实例管理器中统一查看您的 NGINX 基础架构。 此功能可以增强 NGINX 实例的治理，以实现合规目的。
• SNI 配置的增强– 以前，通过服务器名称标识 (SNI) 的服务器名称使用 proxy_ssl_name 指令，并被上游组中的所有服务器使用。 NGINX Plus R31 可以将此 SNI 设置为选定的上游服务器。
• 使用 NGINX JavaScript 定期执行任务– NGINX JavaScript 引入了 js_periodic 指令，允许以定期间隔运行内容。 此增强功能消除了设置 cron 作业的需要，并可配置为在所有或特定的工作进程上运行以获得最佳性能。
• 更好的 NGINX 启动体验– NGINX Plus R31 在配置中存在大量“位置”的情况下改善了整体 NGINX 启动体验。
• QUIC+HTTP/3 优化和改进——NGINX Plus R31 为 QUIC 实现添加了许多增强功能和性能优化，包括支持路径最大传输单元 (MTU) 发现、拥塞控制改进以及在整个 QUIC 会话中重用加密上下文的能力。

该版本还包括从 NGINX 开源继承的新功能和错误修复以及对 NGINX JavaScript 模块的更新。

行为方面的重要变化

笔记： 如果您要从 NGINX Plus R30 以外的版本升级，请务必检查以前公告博客中的“行为中的重要变化”部分，了解当前版本和此版本之间的所有版本。

弃用 OpenTracing 模块

NGINX Plus R18 中引入的 OpenTracing 模块现已弃用。 从 NGINX Plus R34 的未来版本开始它将被删除。 在此之前，该软件包将与所有 NGINX Plus 版本一起提供。 强烈建议使用 NGINX Plus R29 中引入的OpenTelemetry 模块。

未报告 NGINX 使用情况的警告消息

NGINX Plus 用户需要向 F5 报告其 NGINX 使用情况以满足合规要求。 随着 NGINX Plus R31 的发布，向NGINX 实例管理器报告 NGINX 使用情况的功能已原生存在且默认启用。 如果 NGINX 实例由于任何原因无法向 NGINX 实例管理器提供其使用信息，则会记录一条警告消息。

有关如何在您的环境中配置此功能的详细信息，请参阅本机 NGINX 使用情况报告部分。

平台支持变更

支持的新操作系统：

• FreeBSD 14
• Alpine 3.19

已删除旧操作系统：

• Alpine 3.15，于 2023 年 11 月 1 日达到使用寿命终止 (EOL)

NGINX Plus R32 中已弃用并计划删除的旧操作系统：

• FreeBSD 12 将于 2023 年 12 月 31 日达到 EOL

新功能详情

原生 NGINX 使用情况报告

NGINX Plus R31 引入了与网络上的 NGINX 实例管理器的本机通信，以自动化许可合规性。 如果您参与F5 Flex 消费计划，您将不再需要手动跟踪您的 NGINX Plus 实例。

默认情况下，NGINX Plus 将在启动时尝试通过nginx-mgmt.local主机名的 DNS 查找来发现 NGINX 实例管理器。 虽然主机名是可配置的，但我们建议（为简单起见）向您的本地 DNS 添加 A 记录，将默认主机名与运行 NGINX 实例管理器的系统的 IP 地址关联。 然后，NGINX Plus 将与 NGINX 实例管理器建立 TLS 连接，每三十分钟报告一次其版本号、主机名和唯一标识符。

为了增加安全性，我们还建议使用可选的mgmt配置块来配置此连接和 mTLS。 NGINX 实例管理器将定期向 F5 服务报告 NGINX Plus 实例的总使用情况。

如果 NGINX Plus 在解析nginx-mgmt.local主机名或与 NGINX 实例管理器通信时遇到任何问题，您将在错误日志中看到一条警告消息。

这是一个错误消息示例，表明 NGINX Plus 实例无法解析nginx-mgmt.local ：

2023/12/21 21:02:01 [警告] 3050#3050：使用情况报告：未找到解析端点“nginx-mgmt.local”的主机

下面是一个错误消息示例，表明 NGINX Plus 实例在与 NGINX 实例管理器通信时遇到困难：

2023/12/21 21:02:01 [警告] 3184#3184：使用情况报告：连接超时

自定义管理配置块设置

如果您希望微调 NGINX Plus 实例与 NGINX 实例管理器的通信方式，您可以选择使用新的mgmt配置块和相关指令。 这样做可以让您定义自定义解析器，使用 IP 地址或备用主机名来识别您的 NGINX 实例管理器系统，指定 TLS 选项，使用 mTLS 增强安全性，并指定其他自定义参数。

以下是自定义配置的示例：

mgmt {
usage_report end=instance-manager.local interval=30m;
resolver 192.168.0.2; # 示例内部 DNS IP

uuid_file /var/lib/nginx/nginx.id;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers DEFAULT;

ssl_certificate client.pem;
ssl_certificate_key client.key;

ssl_trusted_certificate trust_ca_cert.crt;
ssl_verify on;
ssl_verify_depth 2;
}

有关这些指令的更多详细信息，请参阅产品文档。

有关下载和安装 NGINX 实例管理器的更多信息，请参阅安装指南。

笔记： 如果您使用的是早期版本的 NGINX Plus，您仍然可以按照以下说明报告您的实例。

SNI 配置增强功能

在此版本之前，NGINX Plus 假定上游组中的所有服务器都是相同的。 这意味着他们需要能够回答相同的请求，响应相同的 SNI 名称（当使用proxy_ssl_server_name时），并返回与相同名称匹配的 SSL 证书。

然而，在某些情况下，这种行为是不够的。 例如，如果多个虚拟服务器在上游服务器后面共享，并且需要通过不同的 SNI 和/或主机标头来区分，以将请求路由到特定资源。 也有可能上游组中的所有服务器不能使用同一个证书，或者将上游服务器放入单独的上游组存在限制。

NGINX Plus R31 引入了对每个上游服务器配置的 SNI 支持。 变量$upstream_last_server_name指的是所选上游服务器的名称，然后可以使用proxy_ssl_server_name和proxy_ssl_name指令将其传递给代理服务器。

下面展示了如何将proxy_ssl_server_name设置为on ，从而使服务器名称能够通过 SNI：
proxy_ssl_server_name 开启；

以下是如何使用proxy_ssl_name传递选定的上游服务器名称：
proxy_ssl_name $upstream_last_server_name;

使用 NGINX JavaScript 定期执行任务

NGINX JavaScript v0.8.1 引入了一个新的指令js_periodic ，可在http和stream上下文中使用。 该指令允许指定定期运行的 JavaScript 内容处理程序。 这在自定义代码需要定期运行并且可能需要访问 NGINX 变量的情况下很有用。 内容处理程序接收会话对象作为参数并且还可以访问全局对象。

默认情况下，内容处理程序在工作进程 0 上运行，但可以配置为在特定或所有工作进程上运行。

此指令在位置上下文中可用：

example.conf:

location @periodics {

# 在工作进程 1 和 3 中以 15 分钟为间隔运行
js_periodic main.handler interval=900s worker_affinity=0101;

resolver 10.0.0.1;
js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

async function handler(s) {
let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
let body = await reply.text();

ngx.log(ngx.INFO, body);
}

有关语法和配置详细信息，请参阅NGINX JavaScript 文档。

更好的 NGINX 启动体验

在 NGINX 配置包含大量“位置”的情况下，NGINX 启动时间可能会花费相当长的时间。 在许多情况下，这可能是不可接受的。 根本问题存在于用于对位置列表进行排序的排序算法中。

NGINX R31 引入了一项增强功能，将现有的排序算法从时间复杂度为O(n2)的插入排序替换为时间复杂度为O(n*log n)的合并排序。

在具有 20,000 个位置的测试配置中，观察到此次更新后总启动时间从 8 秒减少到 0.9 秒。

QUIC+HTTP/3 优化与改进

NGINX Plus R31 对 QUIC+HTTP/3 实现进行了多项增强和性能优化，例如：

• 使用 QUIC+HTTP/3 时路径最大传输单元 (MTU) 发现– 路径 MTU 是可通过网络传输的最大尺寸帧或数据包的字节数测量值。 在此更改之前，QUIC 实现对所有数据报使用 1200 字节的路径 MTU。 NGINX Plus 现在支持发现路径 MTU 大小，然后将其用于所有传出数据报。
• 在整个 QUIC 会话中重复使用加密上下文——此优化与 QUIC 数据包的加密和解密行为有关。 以前，每个加密或解密操作都会创建一个单独的加密上下文。 现在，整个 QUIC 会话都使用相同的上下文，从而获得更好的性能。

其他性能优化包括减少发送确认数据包时的潜在延迟、将确认（ACK）帧放在队列的前面以减少帧重传和 ACK 帧传送的延迟，以及改进通用分段卸载（GSO）模式下的拥塞控制行为。

NGINX Plus R31 中的其他增强功能和错误修复

附加管理模块

在 NGINX Plus R31 中， ngx_mgmt_module使您能够将 NGINX 使用信息报告给 NGINX 实例管理器。 此信息包括 NGINX 主机名、NGINX 版本和唯一实例标识符。

该模块提供了几个指令来微调 NGINX 实例与 NGINX 实例管理器的通信方式。 有关可用指令和配置选项的完整列表，请参阅NGINX 文档。

MQTT 模块中的错误修复

NGINX Plus R29 引入了消息队列遥测传输 (MQTT) 支持，此版本包含针对 MQTT 模块中发现的问题的一些错误修复。

一个重要的修复解决了未提供密码时 CONNECT 消息被拒绝的问题。 以前，我们无条件地期望用户名字段后面跟着密码。 但是，MQTT 规范中也存在特殊情况 - 例如匿名身份验证 - 其中提供密码不是强制性的。 该修复程序通过查看数据包的cflags字段有条件地检查是否需要密码。 如果未设置标志，则表示密码不是强制性的。

另一个错误修复是当消息长度小于接收的字节数时停止解析 MQTT CONNECT 消息。

HTTP/3 server_tokens支持变量

NGINX Plus R31 增加了对 HTTP/3 连接缺少的server_tokens变量的支持。 字符串字段可用于明确设置错误页面上的签名和“服务器”响应头字段值。 如果字符串字段为空，则会禁用“服务器”字段的发射。

从 NGINX 开源版本继承的变更

NGINX Plus R31 基于 NGINX Open Source 1.25.3，继承了自 NGINX Plus R30 发布以来（在 NGINX 1.25.2 和 1.25.3 中）的功能变化、特性和错误修复。

特征

• 使用 QUIC 时的路径 MTU 发现- 以前，所有数据报都使用 1200 MTU 的默认大小。 作为 QUIC+HTTP/3 改进的一部分，我们增加了对发现路径 MTU 大小的支持，然后将其用于所有传出数据报。
• QUIC 中的性能优化- NGINX 主线版本 1.25.2 在 QUIC 实现中引入了优化，以重用整个 QUIC 会话的加密上下文。 这减少了发送 ACK 数据包的延迟，并将 ACK 帧放在队列的前面，以减少帧重传和 ACK 帧传送的延迟。
• 使用 HTTP/3 时支持TLS_AES_128_CCM_SHA256密码套件- 此增强功能为 QUIC 添加了TLS_AES_128_CCM_SHA256支持，它目前是 NGINX QUIC 实现不支持的唯一密码套件。 它在 OpenSSL 中默认是禁用的，可以使用此指令启用： ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• 在加载 OpenSSL 配置时提供nginx appName - 使用OPENSSL_init_ssl()接口时，NGINX 现在会测试OPENSSL_INIT_LOAD_CONFIG是否已定义且为真，而不是检查OPENSSL_VERSION_NUMBER 。 这确保了该接口不与 BoringSSL 和 LibreSSL 一起使用，因为它们不提供额外的库初始化设置（特别是OPENSSL_INIT_set_config_appname()调用）。

更改

• 更改 NGINX 队列排序算法– 如上所述，NGINX 现在使用合并排序，其时间复杂度为O(n*log n) 。 这会创造更好的 NGINX 启动体验，尤其是当配置中的“位置”数量非常多时。
• HTTP/2 迭代流处理限制- 此改进通过对一个事件循环中可引入的新流的数量施加限制，确保及早检测到对 NGINX 的洪水攻击。 此限制是该值的两倍，并使用http2_max_concurrent_streams配置。 即使从未达到允许的并发流的最大阈值，它也会应用于解释在发送请求后立即重置流的情况。

问题修复

• 使用 HTTP/2 自动检测修复缓冲区管理- 作为普通 TCP 连接上 HTTP/2 自动检测的一部分，初始数据首先读入由client_header_buffer_size指令指定的没有状态保留的缓冲区中。 这导致了在保存状态时缓冲区可能被覆盖的问题。 当前修复允许仅读取可用的缓冲区大小，而不是固定的缓冲区大小。 该错误首次出现在 NGINX 主线版本 1.25.1（NGINX Plus R30）中。
• OpenSSL 兼容模式中的传输模式不正确– 在此版本之前，如果客户端发送了不正确的传输参数，OpenSSL 兼容层就会导致连接延迟。 该修复程序通过首先通知用户有关不正确的参数然后关闭连接来轻松处理此行为。
• 修复了没有原因短语的状态标头的处理- 带有空“原因短语”的状态标头，如状态： 404按照通用网关接口 (CGI) 规范有效，但在解析过程中丢失了尾随空格。 这导致响应中出现HTTP/1.1 404状态行，由于缺少尾随空格，违反了 HTTP 规范。 修复此错误后，此类短状态标头行中仅使用状态代码，因此 NGINX 将使用空格和适当的原因短语（如果可用）生成状态行本身。
• 修复了使用 PCRE2 重新加载配置时发生的内存泄漏- 当 NGINX 配置为使用版本 1.21.5 或更高版本的 PCRE2 时会出现此问题。

有关从最新版本继承的新更改、功能、错误修复和解决方法的完整列表，请参阅 NGINX CHANGES文件。

NGINX JavaScript 模块的变更

NGINX Plus R31 吸收了 NGINX JavaScript (njs) 模块版本 0.8.2 的变化。 以下是自 0.8.0（NGINX Plus R30 版本的一部分）以来 njs 中显著变化的列表。

特征

• 引入控制台对象。 引入了这些方法： error() 、 info() 、 log() 、 time() 、 timeEnd()和warn() 。
• 引入了http和stream的js_periodic指令，允许指定以固定间隔运行的 JS 处理程序。
• 实现了共享字典的items()方法。 该方法返回所有未过期的键值对。

更改

• 扩展“fs”模块。 添加了existSync()方法。

问题修复

• 修复了“xml”模块。 修复了parse()方法中损坏的 XML 异常处理。
• 使用全局正则表达式（regexp）和 Unicode 输入修复了RegExp.prototype.exec() 。
• 固定共享字典的size()和keys()方法。
• 修复了 0.8.0 中引入的r.internalRedirect()中的错误异常。
• 修复了Object.getOwnPropertyNames()中键的错误顺序。
• 修复了在 fetch API 中对 HEAD 响应处理较大 Content-Length 的问题。
• 修复了共享字典的items()方法。

有关所有功能、更改和错误修复的完整列表，请参阅 njs更改日志。

升级或尝试 NGINX Plus

如果您正在运行 NGINX Plus，我们强烈建议您尽快升级到 NGINX Plus R31。 除了所有出色的新功能之外，您还将获得一些额外的修复和改进，并且保持更新将有助于 NGINX 帮助您提出支持单。

如果您还没有尝试过 NGINX Plus，我们鼓励您尝试一下。 您可以将其用于安全、负载平衡和 API 网关用例，或将其用作具有增强的监控和管理 API 的完全支持的 Web 服务器。 立即开始30 天免费试用。