NGINX Plus R27 正式发布

NGINX | 2022年6月28日

Prabhat Dixit

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

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

用于健康检查的长连接。在以前的版本中，NGINX Plus会为每次健康检查建立新连接。HTTP keepalive_time 指令的新参数health_check可为健康检查启用长连接并设置其生命周期。建立新连接会消耗大量计算资源，因此，当上游服务器数量较多时，复用连接可以显著降低CPU使用率。
支持内核TLS：NGINX Plus现已在3种满足支持要求的操作系统上支持内核TLS（kTLS）：FreeBSD 13、RHEL 9.0+和Ubuntu 22.04 LTS。
上游和虚拟服务器的TLS指标：启用HTTPS代理后，NGINX Plus现在除了生成以往版本中已有的全局统计信息外，还会为各个上游和虚拟服务器生成TLS统计信息。客户端和服务器端的指标有助于排查TLS握手问题。
自定义JWT验证失败时的错误代码：在NGINX Plus R25和R26中，可以定义自定义JWT验证检查，但验证失败时返回的错误代码始终为401 （未经身份验证）。NGINX Plus R27为error参数引入了auth_jwt_require指令，可为每项检查将代码设置为401或403 （禁止访问），以便更清楚地区分身份验证错误和授权错误。
NGINX JavaScript和Prometheus-njs模块增强功能：NGINX JavaScript模块的增强功能包括用于微调ngx.fetch函数行为的新指令，以及一个以十六进制数报告njs版本的新对象。Prometheus-njs模块现在可以将更多NGINX Plus指标转换为符合Prometheus规范的格式，包括codes字段（用于报告上游服务器和虚拟服务器各HTTP状态码的计数），以及Limit Connections和Limit Requests模块生成的指标。

本次版本更新还包括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日终止生命周期（RHEL 8.1+的生命周期终止日期不同，因此仍受支持）
Power 8架构（ppc64le；影响CentOS和RHEL）

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

Debian 10，将于2022年8月终止支持

新功能详解

用于运行状况检查的 Keepalive 连接

长连接可显著提升NGINX Plus与上游服务器之间反向代理和负载均衡用例的性能。尤其是通过HTTPS进行代理时，每个新连接都需要执行完整的TLS握手，其计算开销可能会给计算资源带来压力，在包含大量上游服务器的生产环境中尤其如此。

在之前的版本中，NGINX Plus未使用长连接执行健康检查，而是为每次健康探测建立新连接。NGINX Plus R27为HTTP健康检查引入了长连接。新增的keepalive_time参数用于health_check指令，可设置每个长连接的生命周期，生命周期结束后将建立新连接。我们的测试表明，对于HTTPS代理，长连接可将NGINX Plus服务器上健康检查的CPU使用量降至原来的1/10至1/20，同时还能节省上游服务器的CPU资源。

以下示例启用生命周期为60秒的keepalive连接。根据interval参数设置的1秒健康检查频率，NGINX Plus每进行60次健康检查只需执行一次TLS握手和连接建立。

正在加载代码示例…

支持内核TLS

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

结合使用kTLS和sendfile()系统调用后，数据会直接在内核空间中加密，再传递到网络协议栈进行传输，而无需先复制到用户空间并使用TLS库加密，然后在传输前再复制回内核空间。kTLS还支持将TLS处理卸载到硬件，包括将TLS对称加密处理卸载到网络设备。

支持kTLS需要满足以下3项要求：

操作系统内核支持kTLS
操作系统发行版包含编译时已启用kTLS支持的OpenSSL 3.0+加密库
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与上游服务器之间使用HTTPS连接时，NGINX Plus会在系统级别生成TLS活动和错误指标。这适用于http和stream上下文（分别通过proxy_pass https://path-to-upstream和proxy_ssl on指令建立连接）。这些统计信息涵盖握手、失败和会话复用（通过proxy_ssl_session_reuse指令配置）。

NGINX Plus R27会为配置中包含zone指令的各个上游服务器，以及配置中包含status_zone指令的虚拟服务器生成这些TLS指标。同时获取客户端和服务器端的指标，有助于排查TLS握手问题。

以下示例为上游服务器upstream1以及将流量代理到该服务器的虚拟服务器启用统计信息收集。

正在加载代码示例…

此输出表明，第一个上游服务器参与了4次TLS握手，并有2个会话被复用（为简洁起见，此处仅显示第一个服务器的部分输出，并省略其他上游服务器的输出）：

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq{
  "peers": [
    {
      "id": 0,
      "server": "127.0.0.1:8081",
      "name": "127.0.0.1:8081",
      "backup": false,
      "weight": 1,
      "state": "up",
      "active": 0,
      "ssl": { "handshakes": 4, "handshakes_failed": 0, "session_reuses": 2 },
      "requests": 4,
      "header_time": 4,
      "response_time": 4,
      ...
    }
    ...
  ]
}

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

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq{
  "processing": 0,
  "requests": 7,
  "responses": {
    "1xx": 0,
    "2xx": 7,
    "3xx": 0,
    "4xx": 0,
    "5xx": 0,
    "codes": {
      "200": 7
    },
    "total": 7
  },
  "discarded": 0,
  "received": 546,
  "sent": 1134,
  "ssl": { "handshakes": 7, "handshakes_failed": 0, "session_reuses": 0 }
  ...
}

请注意，NGINX Plus API仍会收集先前NGINX Plus版本中提供的全局TLS指标：

$ curl http://127.0.0.1:8000/api/8/ssl | jq{
  "handshakes": 21,
  "handshakes_failed": 0,
  "session_reuses": 6
}

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

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

NGINX Plus R27 为error 参数引入了 auth_jwt_require 指令，可用于为每条指令单独将错误代码设置为 401 或 403 （禁止访问）。当用户的访问请求失败时，可通过选择不同的代码来区分身份验证失败（JWT 无效）和授权失败（缺少必需的声明）。还可以为这些错误代码创建自定义处理程序，例如使用 error_page 指令返回说明错误的专用页面，或将请求重定向到命名内部位置以供进一步处理。

对于以下类型的JWT检查失败，默认状态码仍为401：

始终执行的（非自定义）检查
使用auth_jwt_require配置但未配置error参数的自定义检查

如果auth_jwt_require指令在location块中出现多次，则会按出现顺序进行求值。首次失败时将停止处理，并返回指定的错误代码。

在此示例中，如果auth_jwt_require指令中的403任一条件，即$req1或$req2的求值结果为空值或0（零），则返回。

正在加载代码示例…

NGINX JavaScript和Prometheus-njs模块增强功能

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

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
The codes field (which reports counts of individual HTTP status codes<.htmla>) under /http/server_zones and /http/upstreams
/stream/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会定期重新添加该套接字，让其他工作进程也有机会接受连接。