NGINX Plus R31正式发布

Prabhat Dixit

我们很高兴地宣布，NGINX Plus Release 31 (R31)现已发布。NGINX Plus基于NGINX Open Source构建，是一款集软件Web服务器、负载均衡器、反向代理、内容缓存和API网关于一体的解决方案。

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

• 原生NGINX使用情况报告，NGINX Plus现已原生支持报告整个组织内的NGINX部署情况，可在NGINX Instance Manager中集中查看NGINX基础设施。此功能可加强对NGINX实例的治理，以满足合规要求。
• SNI配置增强：此前，通过服务器名称指示（SNI）传递的服务器名称使用proxy_ssl_name指令，并由上游组中的所有服务器共用。NGINX Plus R31支持将此SNI设置为选定的上游服务器。
• 使用NGINX JavaScript定期执行任务：NGINX JavaScript引入了js_periodic指令，可按固定时间间隔运行内容。此增强功能无需设置cron作业，并可配置为在所有或特定工作进程上运行，以优化性能。
• 更出色的NGINX启动体验，当配置中包含大量“location”时，NGINX Plus R31可改善NGINX的整体启动体验。
• QUIC+HTTP/3优化与改进，NGINX Plus R31对QUIC实现进行了多项增强和性能优化，包括支持路径最大传输单元（MTU）发现、改进拥塞控制，以及在整个QUIC会话中复用加密上下文。

本次发布还包含继承自NGINX Open Source的新功能和错误修复，以及对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 Instance Manager报告NGINX使用情况的功能已原生提供，并默认启用。如果NGINX实例因任何原因无法向NGINX Instance Manager提供使用情况信息，系统会记录一条警告消息。

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

平台支持变更

新增支持的操作系统：

• FreeBSD 14
• Alpine 3.19

已移除的旧版操作系统：

• Alpine 3.15，已于2023年11月1日终止生命周期（EOL）

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

• FreeBSD 12，其生命周期将于2023年12月31日结束

新功能详解

原生NGINX使用情况报告

NGINX Plus R31新增了与网络中的NGINX Instance Manager直接通信的功能，可自动满足许可证合规要求。如果您参与了F5 Flex Consumption Program，则无需再手动跟踪NGINX Plus实例。

默认情况下，NGINX Plus将在启动时尝试通过DNS查询发现NGINX Instance Manager，查询的主机名为nginx-mgmt.local。虽然该主机名可以配置，但为简化操作，建议在本地DNS中添加一条A记录，将默认主机名与运行NGINX Instance Manager的系统IP地址关联。随后，NGINX Plus将与NGINX Instance Manager建立TLS连接，并每30分钟报告一次其版本号、主机名和唯一标识符。

为进一步增强安全性，我们还建议使用可选的mgmt 配置块，为此连接配置mTLS。之后，NGINX Instance Manager将定期向F5服务报告NGINX Plus实例的总使用量。

如果NGINX Plus在解析nginx-mgmt.local主机名或与NGINX Instance Manager通信时遇到任何问题，错误日志中将显示一条警告消息。

以下错误消息示例表明NGINX Plus实例无法解析nginx-mgmt.local：

2023/12/21 21:02:01 [warn] 3050#3050: usage report: host not found resolving endpoint "nginx-mgmt.local”

以下错误消息示例表明，NGINX Plus实例与NGINX Instance Manager通信时遇到问题：

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

自定义mgmt配置块设置

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

以下是一个自定义配置示例：

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal 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  trusted_ca_cert.crt;
    ssl_verify               on;
    ssl_verify_depth         2;
}

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

有关下载和安装 NGINX Instance Manager 的更多信息，请参阅《安装指南》。

注意：如果使用的是较早版本的NGINX Plus，仍可按照这些说明报告实例。

SNI配置增强

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

但是，在某些场景下，这种行为并不能满足需求。例如，当一个上游服务器后面共享有多个虚拟服务器时，需要使用不同的SNI和/或Host标头来区分这些虚拟服务器，以便将请求路由到特定资源。此外，同一证书可能无法用于上游组中的所有服务器，或者将上游服务器划分到不同的上游组可能受到限制。

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 on;

以下是使用proxy_ssl_name传递所选上游服务器名称的方法：
proxy_ssl_name $upstream_last_server_name;

使用NGINX JavaScript定期执行任务

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

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

此指令可在location上下文中使用：

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 3
    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配置中包含大量“location”时，NGINX可能需要很长时间才能启动。在许多情况下，这可能难以接受。根本原因在于用于对location列表进行排序的算法。

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

在包含20,000个location的测试配置中，更新后的总启动时间从8秒缩短至0.9秒。

QUIC+HTTP/3 优化与改进

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

• 使用QUIC+HTTP/3时的路径最大传输单元（MTU）发现：路径MTU以字节为单位，用于衡量可通过网络传输的最大帧或数据包大小。在此项更改之前，QUIC实现对所有数据报均使用1,200字节的路径MTU。NGINX Plus现在支持发现路径MTU大小，并将其用于所有传出数据报。
• 在整个QUIC会话中复用加密上下文：此项优化涉及QUIC数据包的加密和解密行为。此前，每次执行加密或解密操作时都会创建单独的加密上下文。现在，整个QUIC会话会复用同一上下文，从而提升性能。

其他性能优化包括：减少发送确认数据包时可能出现的延迟；将确认（ACK）帧置于队列前端，以减少帧重传和ACK帧传送延迟；改进通用分段卸载（GSO）模式下的拥塞控制行为。

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

新增mgmt模块

在NGINX Plus R31中，ngx_mgmt_module支持向NGINX Instance Manager报告NGINX使用情况信息。这些信息包括NGINX主机名、NGINX版本和唯一实例标识符。

该模块提供多项指令，用于精细调整NGINX实例与NGINX Instance Manager的通信方式。有关可用指令和配置选项的完整列表，请参阅NGINX文档。

MQTT模块中的错误修复

消息队列遥测传输（MQTT）支持已在NGINX Plus R29中引入，此版本修复了MQTT模块中发现的一些问题。

一项重要修复解决了未提供密码时CONNECT消息被拒绝的问题。此前，系统始终预期用户名字段后会有密码。但MQTT规范中存在一些特殊情况，例如匿名身份验证，此时不强制要求提供密码。此修复通过查看数据包的cflags字段，有条件地检查是否应提供密码。如果未设置该标志，则表示密码并非必填项。

另一项错误修复会在消息长度小于已接收的字节数时停止解析MQTT CONNECT消息。

HTTP/3 server_tokens 支持变量

NGINX Plus R31新增了对HTTP/3连接中缺失的server_tokens变量的支持。string字段可用于显式设置错误页面上的签名和“Server”响应标头字段值。如果string字段为空，则不会发送“Server”字段。

继承自NGINX Open Source的变更

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_VERSION_NUMBER，而是检测OPENSSL_INIT_LOAD_CONFIG是否已定义且值为true。这样可确保该接口不会与BoringSSL和LibreSSL搭配使用，因为它们不提供额外的库初始化设置（尤其是OPENSSL_INIT_set_config_appname()调用）。

变更

• 更改NGINX队列排序算法：如上所述，NGINX现在使用归并排序，其时间复杂度为O(n*log n)。这可以改善NGINX启动体验，尤其是在配置中包含大量“location”时。
• 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 Compatibility Layer会导致连接延迟。此修复会先通知用户参数错误，然后关闭连接，从而妥善处理此情况。
• 修复了对不含原因短语的状态标头的处理：根据通用网关接口（CGI）规范，类似Status: 404这样“原因短语”为空的状态标头是有效的，但在解析过程中会丢失末尾空格。因此，响应中会出现HTTP/1.1 404状态行，由于缺少末尾空格，不符合HTTP规范。修复此错误后，对于此类简短的Status标头行，只使用其中的状态码，由NGINX自行生成状态行，并添加空格以及适当的原因短语（如有）。
• 修复了使用PCRE2时重新加载配置导致的内存泄漏。当NGINX 1.21.5或更高版本配置为使用PCRE2时，会出现此问题。

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

NGINX JavaScript Module 的变更

NGINX Plus R31 纳入了 NGINX JavaScript（njs）模块 0.8.2 版本中的变更。以下是 njs 自 0.8.0 版本（该版本随 NGINX Plus R30 发布）以来的主要变更。

功能

• 引入了console对象，并新增了以下方法：error()、info()、log()、time()、timeEnd()和warn()。
• 引入了用于js_periodic的指令，适用于http和stream，可指定按固定时间间隔运行的JS处理程序。
• 实现了items()方法，用于共享字典。此方法返回所有未过期的键值对。

变更

• 扩展了“fs”模块。新增了existsSync()方法。

错误修复

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

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

升级或试用NGINX Plus

如果您正在运行NGINX Plus，强烈建议尽快升级到NGINX Plus R31。除了各项实用的新功能外，此版本还包含多项修复和改进。保持版本为最新状态，也有助于NGINX在您需要提交支持工单时提供帮助。

如果尚未试用NGINX Plus，建议您体验一下。NGINX Plus可用于安全、负载均衡和API网关等用例，也可用作获得全面支持的Web服务器，并提供增强的监控和管理API。立即开始30天免费试用。

关于作者

Prabhat Dixit

Prabhat Dixit 的更多博客文章