博客 | NGINX

宣布推出 NGINX Plus R15

Liam Crilly 缩略图
利亚姆·克里利
2018 年 4 月 10 日发布

我们很高兴地宣布,我们的旗舰产品 NGINX Plus 第十五版本现已推出。 自2013 年首次发布以来,NGINX Plus 在功能集和商业吸引力方面都取得了长足的进步。 目前,NGINX Plus 客户超过 [ngx_snippet name='nginx-plus-customers'] 个, NGINX Open Source 用户超过 [ngx_snippet name='number-sites']个。

NGINX Plus 基于 NGINX 开源,是唯一负载均衡器、内容缓存、Web 服务器和 API 网关于一体的套件。 NGINX Plus 包含独有的增强功能,旨在降低构建现代应用的复杂性,同时还提供屡获殊荣的支持。

NGINX Plus R15引入了新的 gRPC 支持、HTTP/2 服务器推送、改进的集群支持、增强的 API 网关功能等:

  • 原生 gRPC 支持– gRPC 是 Google 开发的新型远程过程调用 (RPC) 标准。 它是客户端和服务器进行通信的一种轻量且高效的方式。 借助此新功能,NGINX Plus 可以通过 SSL 终止、路由和负载平衡 gRPC 流量到您的后端服务器。
  • HTTP/2 服务器推送- 通过 HTTP/2 服务器推送,NGINX Plus 可以在客户端实际请求之前发送资源,从而提高性能并减少往返。
  • 集群内的状态共享——在此版本中,用于 Sticky Learn 会话持久性的共享内存数据可以在集群中的所有 NGINX Plus 实例之间共享。 NGINX Plus 的接下来几个版本将以我们的集群功能为基础,并引入新的集群感知功能。
  • OpenID Connect 集成——您现在可以使用 NGINX Plus 为任何 Web应用提供单点登录 (SSO),使用 OpenID Connect 授权码流并向客户端发出 JSON Web 令牌 (JWT)。 NGINX Plus 与 CA Single Sign‑On(以前称为 SiteMinder)、ForgeRock OpenAM、Keycloak、Okta、OneLogin、Ping Identity 以及其他流行的身份提供商集成。
  • NGINX JavaScript (njs) 模块增强功能- njs 模块(以前称为 nginScript)使您能够在 NGINX Plus 请求处理期间运行 JavaScript 代码。 HTTP 的 njs 模块现在提供对发出独立于客户端请求且异步于客户端请求的 HTTP 子请求的支持。 这在 API 网关用例中很有用,使您可以灵活地使用 JavaScript 修改和合并 API 调用。 HTTP 和 TCP/UDP 的 njs 模块现在还包括能够实现常见哈希函数的加密库。

该版本还包含更多新功能,包括新的 ALPN 变量、多个动态模块的更新等等。

行为变化

  • NGINX Plus R13 引入了全新的 NGINX Plus API,它实现了以前在单独的 API 中实现的功能,包括上游组和扩展指标的动态配置。 以前使用upstream_confstatus指令配置的API已被弃用。 我们鼓励您检查这些指令的配置并尽快转换为新的api指令(有关详细信息,请参阅我们博客上的“宣布 NGINX Plus R13” )。 从下一个版本NGINX Plus R16开始,将不再提供弃用的 API。
  • NGINX Plus API 在此版本中更新至版本 3。 以前的版本仍然受支持。 如果您正在考虑更新您的 API 客户端,请查阅API 兼容性文档
  • 官方存储库中提供的 NGINX Plus 包现在有了新的编号方案。 NGINX Plus 包和所有动态模块现在都指示 NGINX Plus 版本号。 每个软件包版本现在都对应 NGINX Plus 版本,以便更清楚地了解安装了哪个版本并简化模块依赖关系。 除非您使用按版本号引用包的自动化系统,否则此更改是透明的。 在这种情况下,请首先在非生产环境中测试升级过程。

NGINX Plus R15 功能详情

gRPC 支持

在此版本中,NGINX Plus 可以代理和负载平衡 gRPC 流量,许多组织已在使用 gRPC 与微服务进行通信。gRPC 是一个开源的、高性能的远程过程调用 (RPC) 框架,由 Google 设计,可实现高效、低延迟的服务到服务通信。gRPC 要求使用 HTTP/2 而不是 HTTP 1.1 作为其传输机制,因为 HTTP/2 的功能(流量控制、多路复用和低延迟的双向流量流)非常适合大规模连接微服务。

NGINX 将 gRPC 流量从单个端点路由到多个服务并进行负载平衡
NGINX 路由并 SSL 终止 gRPC 流量

NGINX Open Source 1.13.10 中引入了对 gRPC 的支持,现在已包含在NGINX Plus R15中。 您现在可以检查和路由 gRPC 方法调用,从而使您能够:

  • 将 NGINX Plus 功能(包括 HTTP/2 TLS 加密、速率限制、基于 IP 地址的访问控制列表和日志记录)应用于已发布的 gRPC 服务。
  • 通过检查和代理与内部服务的 gRPC 连接,通过单个端点发布多个 gRPC 服务。
  • 当需要额外容量时,通过将 gRPC 连接负载均衡到上游后端池来扩展您的 gRPC 服务。
  • 使用 NGINX Plus 作为 gRPC 和 RESTful 端点的 API 网关。

要了解更多信息,请参阅我们博客上的“通过 NGINX 1.13.10 引入 gRPC 支持”

HTTP/2 服务器推送

第一印象很重要,页面加载时间是决定用户是否会再次访问您的网站的关键因素。 为用户提供更快响应的一种方法是使用 HTTP/2 服务器推送,这减少了用户必须等待的 RTT(往返时间,即请求和响应所需的时间)数量。

NGINX 可以预先将资源推送给客户端以提高性能

HTTP/2 服务器推送是 NGINX 开源社区高度要求和期待的功能,于 NGINX Open Source 1.13.9 中引入。 现在包含在NGINX Plus R15中,它允许服务器预先发送可能需要完成先前客户端发起的请求的数据。 例如,浏览器需要一系列资源(样式表、图像等)来呈现网站页面,因此当客户端首次访问该页面时立即发送这些资源可能是有意义的,而不是等待浏览器明确请求它们。

在下面的配置示例中,我们使用http2_push指令为客户端提供呈现演示网页所需的样式表和图像:

然而,在某些情况下,无法确定客户端所需的确切资源集,因此在 NGINX 配置文件中列出特定文件是不切实际的。 在这些情况下,NGINX 可以拦截 HTTP链接标头并推送其中标记为预加载的资源。 要启用Link标头的拦截,请将http2_push_preload指令设置为on

要了解更多信息,请参阅我们博客上的使用 NGINX 1.13.9 介绍 HTTP/2 服务器推送

集群间状态共享

将多个 NGINX Plus 服务器配置为高可用性集群,可以使您的应用更具弹性,并消除应用堆栈中的单点故障。 NGINX Plus 集群专为任务关键型生产部署而设计,其中弹性和高可用性至关重要。 使用 NGINX Plus 部署高可用性集群有很多解决方案。

NGINX Plus 的先前版本中引入了集群支持,提供两层集群:

NGINX Plus R15引入了第三层集群——运行时状态共享,允许您同步集群节点之间共享内存区域中的数据。 更具体地说,现在可以使用用于 TCP/UDP 流量的新zone_sync模块在集群中的所有节点之间同步用于 Sticky Learn 会话持久性的共享内存区域中存储的数据。

新的zone_sync模块

通过状态共享,不存在主节点——所有节点都是对等的,并在全网状拓扑中交换数据。 此外,状态共享集群解决方案独立于网络弹性的高可用性解决方案。 因此,状态共享集群可以跨越物理位置。

NGINX Plus 状态共享集群必须满足三个要求:

  • 所有集群节点之间的网络连接
  • 同步时钟
  • 每个节点上的配置都启用zone_sync模块,如下所示:

zone_sync指令可以实现集群中共享内存区域的同步。 zone_sync_server指令标识集群中的其他 NGINX Plus 实例。 NGINX Plus 支持 DNS 服务发现,因此可以通过主机名识别集群成员,并且每个集群成员的配置都是相同的。

上述最低配置缺乏保护生产部署中的同步数据所需的安全控制。 以下配置片段采用了几种这样的保护措施:

  • 同步数据SSL/TLS加密
  • 客户端证书认证,因此每个集群节点都可以向其他节点表明自己的身份(相互 TLS)
  • 使用 IP 地址的访问控制列表 (ACL),以便只有同一物理网络上的 NGINX Plus 节点才能连接进行同步

粘性学习会话持久性的状态共享

第一个支持的使用跨集群共享状态数据的 NGINX Plus 功能是Sticky Learn 会话持久性。 会话持久性意味着来自客户端的请求总是被转发到满足客户端第一个请求的服务器,这在会话状态存储在后端时很有用。

在以下配置中, sticky learn指令定义了一个名为session的共享内存区域。 sync参数通过指示 NGINX Plus 向集群中的其他节点发布有关其共享内存区域内容的消息,实现集群范围的状态共享。

请注意,为了使状态数据同步正确工作,集群中每个 NGINX Plus 节点上的配置都必须包含具有sticky learn指令的相同上游块,以及启用zone_sync模块的指令(如上所述)。

笔记: 集群支持和 Sticky Learn 会话持久性是 NGINX Plus 独有的。

OpenID Connect 集成

许多企业使用身份和访问权限管理(IAM) 解决方案来管理用户帐户并为多个应用提供单点登录 (SSO) 环境。 他们经常希望在新的和现有的应用之间扩展 SSO,以最大限度地降低复杂性和成本。

使用 OpenID Connect 和 NGINX Plus 使我们能够快速轻松地与我们的身份提供商集成,同时简化我们的应用架构。
– Scott Macleod,NHS Digital 软件工程师

NGINX Plus R10引入了对验证 OpenID Connect 令牌的支持。 在此版本中,我们扩展了该功能,以便 NGINX Plus 还可以控制使用OpenID Connect 1.0进行身份验证的授权码流、与身份提供者进行通信以及向客户端发出访问令牌。 这使得能够与大多数主要身份提供商集成,包括 CA Single Sign-On(以前称为 SiteMinder)、ForgeRock OpenAM、Keycloak、Okta、OneLogin 和 Ping Identity。 新扩展的功能还可以让您:

  • 将 SSO 扩展到旧版应用,无需修改或更新这些应用
  • 将 SSO 集成到新应用中,而无需在应用代码中实现 SSO 或身份验证
  • 消除供应商锁定;您可以获得基于标准的 SSO,而无需在应用中部署专有的 IAM 供应商代理软件

OpenID Connect 与 NGINX Plus 的集成可作为 GitHub 上的参考实现。 GitHub repo包含示例配置,其中包含有关特定用例的安装、配置和微调的说明。

NGINX JavaScript 模块的增强功能

[编辑器– 以下示例只是 NGINX JavaScript 模块众多用例中的一部分。 有关完整列表,请参阅NGINX JavaScript 模块的用例

本节中的代码更新如下,以反映自博客最初发布以来 NGINX JavaScript 实现的变化:

  • 使用 NGINX JavaScript 0.2.4中引入的 Stream 模块的重构会话对象。
  • 使用js_import指令,它取代了 NGINX Plus R23 及更高版本中的js_include指令。 有关更多信息,请参阅NGINX JavaScript 模块的参考文档 -示例配置部分显示了 NGINX 配置和 JavaScript 文件的正确语法。

]

使用 NGINX JavaScript 模块 njs (以前称为 nginScript),您可以在 NGINX 配置中包含 JavaScript 代码,以便在处理 HTTP 或 TCP/UDP 请求时在运行时对其进行评估。 这使得广泛的潜在用例成为可能,例如更好地控制流量、跨应用整合 JavaScript 功能以及防御安全威胁。

NGINX Plus R15对 njs 进行了两项重要更新:子请求哈希函数

子请求

您现在可以发出独立于客户端请求且异步的同步 HTTP 请求。 这使得多种高级用例成为可能。

以下示例 JavaScript 代码同时向两个不同的后端发出 HTTP 请求。 第一个响应被发送到 NGINX Plus 以转发到客户端,第二个响应被忽略。

相应 NGINX Plus 配置中的js_import指令从fastest_wins.js读取 JavaScript 代码。 所有与根位置( / )匹配的请求都将传递给sendFastest()函数,该函数会生成对/server_one/server_two位置的子请求。 带有查询参数的原始 URI 被传递给相应的后端服务器。 两个子请求都执行done回调函数。 但是,由于此函数包含r.return() ,因此只有首先完成的子请求才会将其响应发送给客户端。

哈希函数

HTTP 和 TCP/UDP 流量的 njs 模块现在包括一个加密库,其实现如下:

  • 哈希函数: MD5、SHA-1、SHA-256
  • HMAC 使用: MD5、SHA-1、SHA-256
  • 摘要格式: Base64、Base64URL、十六进制

哈希函数的一个示例用例是向应用cookie 添加数据完整性。 以下 njs 代码示例包括一个signCookie()函数用于向 cookie 添加数字签名,以及一个validateCookieSignature()函数用于验证已签名的 cookie。

以下 NGINX Plus 配置利用 njs 代码来验证传入的 HTTP 请求中的 cookie 签名,并在验证失败时向客户端返回错误消息。 如果验证成功或不存在 cookie,NGINX Plus 将代理请求。

NGINX Plus R15 中的其他新功能

流模块的 ALPN 变量

application层协议协商 (ALPN) 是 TLS 的扩展,它允许客户端和服务器在 TLS 握手期间协商将使用哪种协议来建立连接,从而避免可能导致延迟并降低用户体验的额外往返。 ALPN 最常见的用例是当客户端和服务器都支持 HTTP/2 时自动将连接从 HTTP 升级到 HTTP/2。

新的 NGINX 变量$ssl_preread_alpn_protocols首次出现在 NGINX Open Source 1.13.10 中,它捕获客户端在 ALPN 预读阶段在其ClientHello消息中通告的协议列表。 鉴于以下配置,XMPP 客户端可以通过 ALPN 进行自我介绍,以便 NGINX Plus 将 XMPP 流量路由到xmpp_backend上游组,将 gRPC 流量路由到grpc_backend ,并将所有其他流量路由到http_backend ,所有这些都通过单个端点进行。

为了使 NGINX Plus 能够从ClientHello消息中提取信息并填充$ssl_preread_alpn_protocols变量,您还必须包含ssl_preread on指令。

要了解更多信息,请参阅ngx_stream_ssl_preread模块的文档。

排队时间变量

NGINX Plus 支持上游排队,这样当上游组中的所有服务器都无法接受新请求时,不必立即拒绝客户端请求。

上游排队的典型用例是保护后端服务器免于过载,而不必在所有服务器都繁忙时立即拒绝请求。 您可以使用服务器指令的max_conns参数定义每个上游服务器的最大同时连接数。 当没有可用的后端时,队列指令会将请求放入队列中,因为它们已经达到其连接限制,或者因为它们未通过健康检查

在此版本中,新的 NGINX 变量$upstream_queue_time (首次引入于 NGINX Open Source 1.13.9)可捕获请求在队列中花费的时间。 下面的配置包括一个自定义日志格式,可以捕获每个请求的各种时间指标;然后可以作为性能调整的一部分离线分析这些指标。 我们将my_backend上游组的排队请求数限制为 20。 超时参数设置在向客户端返回错误消息之前请求在队列中保留的时间(503默认情况下)。 这里我们设置为5秒(默认是60秒)。

要了解更多信息,请参阅队列指令的文档。

无需转义即可访问日志

您现在可以在 NGINX Plus 访问日志中禁用转义。 NGINX Open Source 1.13.10 中首次引入了log_format指令的新escape=none参数,指定不对变量中的特殊字符应用转义。

LDAP Auth 参考实现更新

我们使用 LDAP 身份验证系统对用户进行身份验证的参考实现已更新,以解决问题和修复错误。 在 GitHub 上查看

无需 root 权限的透明代理

您可以通过将transparent参数添加到proxy_bind指令来使用 NGINX Plus 作为透明代理。 工作进程现在可以从主进程继承CAP_NET_RAW Linux 功能,因此 NGINX Plus 不再需要透明代理的特殊权限。

笔记: 此功能仅适用于Linux平台。

JWT 宽限期

如果 JWT 包含基于时间的声明 - nbf (不早于日期)、 exp (到期日期)或两者 - NGINX Plus 对 JWT 的验证包括检查当前时间是否在指定的时间间隔内。 但是,如果身份提供者的时钟与 NGINX Plus 实例的时钟不同步,则令牌可能会意外过期或似乎在将来启动。 要设置两个时钟之间可接受的最大偏差,请使用auth_jwt_leeway指令。

Cookie 标志动态模块

用于设置 cookie 标志的第三方模块现在可作为 NGINX 存储库中的Cookie-Flag动态模块使用,并且受 NGINX Plus 支持协议的约束。 您可以使用包管理工具来安装它:

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

NGINX ModSecurity WAF 模块更新

NGINX ModSecurity WAF是基于 ModSecurity 3.0 的 NGINX Plus 动态模块,现已更新,具有以下增强功能:

  • libmodsecurity中的性能改进
  • ModSecurity-nginx中的内存泄漏修复

[编辑– NGINX ModSecurity WAF 于2022 年 4 月 1 日正式停止销售,并将于2024 年 3 月 31 日停止使用。 有关更多详细信息,请参阅我们博客上的“F5 NGINX ModSecurity WAF 正在过渡到终止使用<.htmla>”。]

升级或尝试 NGINX Plus

NGINX Plus R15包括针对客户端应用的改进的身份验证功能、额外的集群功能、njs 增强功能以​​及显著的错误修复

如果您正在运行 NGINX Plus,我们强烈建议您尽快升级到 Release 15。 您将获得许多修复和改进,升级将帮助我们在您需要提出支持单时为您提供帮助。 NGINX Plus R15的安装和升级说明可在客户门户上找到。

在继续升级之前,请仔细查看本博客文章中描述的新功能行为变化

如果您还没有使用过NGINX Plus ,我们鼓励您尝试一下——用于 Web 加速、负载均衡和应用交付,或作为具有增强监控和管理 API 的完全支持的 Web 服务器。 您今天就可以免费开始使用30 天免费评估版。 亲自了解 NGINX Plus 如何帮助您交付和扩展您的应用。


“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”