宣布推出 NGINX Plus R27

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

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

• 保持健康检查的连接- 在以前的版本中，NGINX Plus 为每次健康检查建立一个新连接。 HTTP health_check指令中的新keepalive_time参数可启用保持连接以进行健康检查并设置其生存期。 建立新连接的计算成本很高，因此当上游服务器数量较多时，重用连接可以大大减少 CPU 的使用率。
• 支持内核 TLS - NGINX Plus 现在在三种满足支持要求的操作系统上支持内核 TLS (kTLS)： FreeBSD 13、RHEL 9.0+ 和Ubuntu 22.04 LTS 。
• 上游和虚拟服务器的 TLS 指标- 除了在以前的版本中生成的全局统计数据外，NGINX Plus 现在还会在启用 HTTPS 代理时为各个上游和虚拟服务器生成 TLS 统计数据。 在解决 TLS 握手问题时，拥有来自客户端和服务器端的指标很有帮助。
• 自定义 JWT 验证失败的错误代码——在NGINX Plus R25 和 R26中，你可以定义自定义 JWT 验证检查，但验证失败返回的错误代码始终是401（未授權） 。 NGINX Plus R27在auth_jwt_require指令中引入了error参数，使你可以将代码设置为401或者403（禁止）进行每次检查，以更好地区分身份验证和授权错误。
• NGINX JavaScript 和Prometheus-njs 模块的增强- NGINX JavaScript 模块的增强包括用于微调ngx.fetch函数行为的新指令和以十六进制数报告 njs 版本的新对象。 Prometheus-njs模块现在可以将额外的 NGINX Plus 指标转换为符合 Prometheus 的格式：代码字段（报告上游和虚拟服务器的各个 HTTP 状态代码的数量）以及由限制连接和限制请求模块生成的指标。

该版本推出了NGINX Plus API的新版本号 (8)，并且在 Linux 内核中使用 EPOLLEXCLUSIVE 模式时连接分布更加均匀。

行为方面的重要变化

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

支持的新操作系统：

• Alpine Linux 3.16
• RHEL 9.0+（首次发布后添加到NGINX Plus R26 ）
• Ubuntu 22.04 LTS（首次发布后添加到NGINX Plus R26 ）

删除了较旧的操作系统和体系结构：

• Alpine 3.12，于2022 年 5 月 1 日终止使用 (EOL)
• CentOS 8.1+，于2021 年 12 月 31 日达到 EOL（RHEL 8.1+ 仍受支持，因为其 EOL 日期不同）
• Power 8 架构（ppc64le；影响 CentOS 和 RHEL）

NGINX Plus R28 中已弃用并计划删除的旧操作系统和体系结构：

• Debian 10 将于 2022 年 8 月达到 EOL

新功能详情

用于健康检查的保持连接

NGINX Plus 与上游服务器之间的保持连接显著提高了反向代理和负载均衡用例的性能。 特别是对于通过 HTTPS 的代理，每个新连接所需的完整 TLS 握手的计算费用可能会给您的计算资源带来压力，尤其是在具有大量上游服务器的生产环境中。

在以前的版本中，NGINX Plus 没有使用保持连接进行健康检查，而是为每个健康探测建立一个新连接。 NGINX Plus R27为 HTTP 健康检查引入了保持连接。 health_check指令的新keepalive_time参数设置每个保持连接的有效期，此后将建立新的连接。 我们的测试表明，对于通过 HTTPS 的代理，保持活动连接可将 NGINX Plus 服务器上的健康检查的 CPU 使用率降低 10 到 20 倍。 它们还节省上游服务器上的 CPU 资源。

以下示例启用了生存期为 60 秒的保持连接。 鉴于间隔参数设置的健康检查频率为 1 秒，NGINX Plus 每 60 次健康检查仅会产生一次 TLS 握手和建立连接的开销。

支持内核 TLS

传输层安全性（TLS）是互联网上数据加密的事实标准协议。 不幸的是，保护数据也会增加延迟。 在内核中实现 TLS（kTLS）可显著减少在用户空间和内核之间复制操作的需要，从而提高提供静态内容时的性能。

结合 kTLS 和sendfile()系统调用意味着数据在传递到网络堆栈进行传输之前直接在内核空间加密，而不是使用 TLS 库复制到用户空间进行加密，然后在传输之前复制回内核空间。kTLS 还支持将 TLS 处理卸载到硬件，包括将 TLS 对称加密处理卸载到网络设备。

支持 kTLS 有三个要求：

1. 操作系统内核支持它
2. 操作系统发行版包含使用 kTLS 支持编译的 OpenSSL 3.0+ 加密库
3. NGINX Plus（或 NGINX Open Source）是使用 OpenSSL 3.0+ 加密库构建的

2021 年 10 月，我们在满足要求 1 和 2 的平台上为 NGINX Open Source 1.21.4 添加了对 kTLS 的支持。 现在我们在以下平台上的 NGINX Plus 中添加了对 kTLS 的支持：

• FreeBSD 13（ NGINX Plus R26及更高版本）
• RHEL 9.0+
• Ubuntu 22.04 LTS

上游和虚拟服务器的 TLS 指标

当 NGINX Plus 部署为反向代理或负载均衡器时， NGINX Plus API为每个上游和虚拟服务器提供了一组有关流量、响应代码和延迟的丰富指标，使客户能够观察和监控服务器的性能和可用性。

在以前的版本中，当 NGINX Plus 和上游服务器之间在http和stream上下文中使用 HTTPS 连接时（分别使用proxy_pass https: //path-to-upstream和proxy_ssl on指令建立），NGINX Plus 会在系统范围级别生成有关 TLS 活动和错误的指标。 统计数据涵盖握手、失败和会话重用（使用proxy_ssl_session_reuse指令配置）。

NGINX Plus R27为配置包含zone指令的各个上游服务器和配置包含status_zone指令的虚拟服务器生成这些 TLS 指标。 在解决 TLS 握手问题时，拥有来自客户端和服务器端的指标很有帮助。

以下示例在上游服务器upper1和代理流量到它的虚拟服务器上启用统计信息收集。

此输出表明第一个上游服务器参与了四次 TLS 握手和两次重用会话（为简洁起见，我们显示第一个服务器的部分输出并省略其他上游服务器的输出）：

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { “peers”：[{ “id”： 0，“服务器”： “127.0.0.1:8081”,“名称”: “127.0.0.1:8081”, “备份”: false, “权重”: 1、“状态”：“启动”，“活动”： 0， "ssl": {"握手": 4，“握手失败”： 0，“session_reuses”： 2 } ，“请求”： 4、“header_time”： 4，“响应时间”： 4，... } ... ] }

此输出表明 NGINX Plus 参与了七次 TLS 握手：

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { “处理”： 0，“请求”： 7，“响应”：{“1xx”： 0，“2xx”： 7、“3xx”： 0，“4xx”： 0，“5xx”： 0，"代码": { "200": 7 }, “总计”: 7 }, “丢弃”: 0，“已收到”： 546，“已发送”： 1134， "ssl": {"握手": 7，“握手失败”： 0，“session_reuses”： 0 } ... }

请注意， NGINX Plus API仍然收集以前的 NGINX Plus 版本中可用的全局 TLS 指标：

$ curl http://127.0.0.1:8000/api/8/ssl | jq { “握手”： 21，“handshakes_failed”： 0，“session_reuses”： 6 }

自定义 JWT 验证失败的错误代码

NGINX Plus R25引入了<.htmla> auth_jwt_require指令，用于在 JWT 验证过程中定义自定义检查。 在NGINX Plus R25 和 R26中，验证失败返回的错误代码始终为401（未授權） 。

NGINX Plus R27在auth_jwt_require指令中引入了error参数，你可以使用该参数将代码设置为401或者403（禁止）针对每个指令独立进行。 当用户的访问请求失败时，通过代码的选择，您可以区分身份验证失败（JWT 无效）和授权失败（缺少必需的声明）。 您还可以为错误代码创建自定义处理程序，例如返回解释错误的特殊页面（使用error_page指令）或将请求重定向到指定的内部位置进行进一步处理。

默认状态代码保持不变401以下类型的 JWT 检查失败：

• 始终执行的（非定制）检查
• 使用auth_jwt_require配置的自定义检查，但没有使用错误参数

如果位置块中有多个auth_jwt_require指令，则按照它们出现的顺序进行评估。 第一次失败时处理停止并返回指定的错误代码。

在此示例中， auth_jwt_require指令返回403如果$req1或$req2计算结果为空值，或者0（零）。

NGINX JavaScript 和 Prometheus-njs 模块的增强

NGINX Plus R27包含版本0.7.3和0.7.4NGINX JavaScript 模块，并包括以下增强功能。

njs Fetch API 的附加指令

NGINX Javascript 0.5.3 融入了NGINX Plus R24 ，引入了ngx.fetch函数（也称为 Fetch API），用于在 TCP/UDP 连接上下文中实例化一个简单的 HTTP 客户端。 （有关该功能的用例的讨论，请参阅我们博客上的使用简单 HTTP 客户端利用 TCP.htmlUDP 的 HTTP 服务。）

NGINX Plus R27引入了以下指令来微调 Fetch API 的行为：

• js_fetch_buffer_size [ HTTP ][ Stream ] - 设置用于读写的缓冲区的大小。
• js_fetch_max_response_buffer_size [ HTTP ][ Stream ] – 设置使用 Fetch API 接收的响应的最大大小。
• js_fetch_timeout [ HTTP ][ Stream ] - 定义两个连续读取或写入操作之间的读取和写入超时（而不是整个响应）。 如果在超时时间内没有传输任何数据，则连接被关闭。
• js_fetch_verify [ HTTP ][ Stream ] – 启用或禁用 HTTPS 服务器证书验证。

以十六进制数报告的版本号

新的njs.version_number对象以十六进制数报告 njs 模块版本。 （现有的njs.version对象以字符串形式返回版本。）

Prometheus-njs 模块转换附加指标

Prometheus-njs模块将 NGINX Plus 指标转换为符合 Prometheus 标准的格式，现在可以转换在以下附加端点公开的指标：

• /http/limit_conns
• /http/limit_reqs
• /http/server_zones和/http/upstreams下的代码字段（报告各个 HTTP 状态代码 <.htmla> 的数量）
• /流/limit_conns

NGINX Plus R27 中的其他增强功能

NGINX Plus API 版本变更

NGINX Plus API的版本号从 7 更新为 8，以反映在上游和虚拟服务器报告的指标中添加了ssl字段，如上游和虚拟服务器的 TLS 指标中所述。 以前的版本号仍然有效，但输出不包含在后续 API 版本中添加的指标。

Linux EPOLLEXCLUSIVE 模式下的连接分配更优

当 Linux 内核使用 EPOLLEXCLUSIVE 模式时， NGINX Plus R27在 NGINX 工作进程之间更均匀地分配连接。 正常情况下，在这种模式下，内核只通知第一个将监听套接字添加到 EPOLL 实例的进程。 因此，大多数连接都由第一个工作进程处理。 NGINX 现在会定期重新添加套接字，以便其他工作进程有机会接受连接。

升级或尝试 NGINX Plus

如果您正在运行 NGINX Plus，我们强烈建议您尽快升级到NGINX Plus R27 。 您还将获得一些额外的修复和改进，当您需要提出支持单时，它将帮助 NGINX 为您提供帮助。

如果您还没有尝试过 NGINX Plus，我们鼓励您尝试一下 – 为了安全、负载均衡和 API 网关，或者作为具有增强监控和管理 API 的完全支持的 Web 服务器。 您今天就可以开始享受30 天免费试用。