适用于 Azure 的 NGINXaaS使企业能够安全地在云中交付高性能应用。 由 NGINX Plus 提供支持,这是一项完全托管的服务,于 2023 年 1 月全面上市。 自发布以来,我们将通过添加新功能不断增强 Azure 的 NGINXaaS。
在这篇博客中,我们重点介绍了一些最新的性能和安全功能,让您享受更多 NGINX Plus 优势,而无需部署、维护和更新您自己的 NGINX Plus 实例。 有关 NGINXaaS for Azure 及其总体功能的一般信息,请阅读使用 F5 NGINXaaS for Azure 简化和加速云迁移。
图 1: NGINXaaS for Azure 概述
虽然反向代理需要 SSL/TLS 来加密公共互联网上的客户端流量,但相互 TLS (mTLS) 对于在服务器端进行身份验证和确保机密性至关重要。 随着向零信任的转变,还需要验证上游服务器流量没有被更改或拦截。
图 2:使用 NGINXaaS 的 mTLS
NGINXaaS for Azure 现在支持 NGINX 指令,以使用 SSL/TLS 证书保护上游流量。 通过这些指令,您不仅可以通过 mTLS 加密上游流量,还可以验证上游服务器是否提供来自受信任证书颁发机构的有效证书。
在 Azure 上使用 NGINXaaS 的 TLS 证书的一个关键部分(双关语)是通过使用Azure Key Vault (AKV)安全地管理这些证书。 AKV 可确保敏感的加密材料的安全,并允许 NGINXaaS for Azure 使用这些证书,同时防止通过 Azure 门户意外或故意泄露密钥材料。
图 3: 使用 Azure Key Vault 进行证书轮换
现在,每当 AKV 中更新证书时,NGINXaaS for Azure 都可以自动在您的 NGINX 部署中轮换证书。新版本的证书将在四小时内轮换到您的部署中。
闭上眼睛,回想一下 1997 年。 我们和 Chumbawamba 一起跳着 Tubthumping,穿着 JNCO 牛仔裤(或者加拿大同胞们穿的 Modrobes),HTTP/1.1 发布了。 当时,大多数终端用户通过拨号调制解调器访问互联网,网页仅包含几十个元素,当谈到用户体验时,带宽比延迟更令人担忧。
二十五年后,相当一部分网络应用仍然使用 HTTP/1.1 来传递内容。 这可能是一个问题。 虽然 HTTP/1.1 仍然有效,但它只允许每个连接一次传送一个资源。 同时,现代网络应用程序可能会发出数百个请求来更新用户界面。
虽然大多数用户拥有更多的可用带宽,但数据传输速度(受光的基本速度限制)并没有那么快地提高。 因此,所有这些请求的累积延迟会对应用的感知性能产生重大影响。 现代浏览器会向同一台服务器打开多个 TCP 连接,但这些连接上的每个请求仍然是连续的,这意味着一个缓慢的资源可能会延迟其后面的所有其他资源。
看一下仅使用 HTTP/1.1 加载的 F5 主页:
图4: 通过 HTTP/1.1 访问 F5.com
看到那些灰色的条了吗? 这是浏览器在等待会话建立、阻止单个缓慢的资源或寻找新的 TCP 连接时浪费的宝贵时间。
让我们启用 HTTP/2 并重试:
图5: 相同请求,但使用 HTTP/2
好多了。 仍然存在一些缓慢的资源,但它们不会阻碍其他请求,并且等待排队相关延迟的时间也明显减少。 HTTP/2 保留了 Web 浏览器和服务器所熟悉的 HTTP/1.1 中的相同语义,同时添加了新功能来解决一些导致应用性能不佳的原因(例如,请求优先级、标头压缩和请求多路复用)。
鉴于如此明显的差异,Azure 的 NGINXaaS 现在支持通过HTTP/2处理客户端请求。 客户端连接更容易受到较长的往返时间的影响,因此您可以利用 HTTP/2 的降低延迟的优势来传输该流量,同时保持上游服务器不变。
尽管 Web应用业务中的某些人可能愿意相信这一点,但我们确实认识到,除了 HTTP 之外,还有其他协议可供您选择。 这就是为什么NGINX gRPC 模块现在也可以在 Azure 的 NGINXaaS 中使用。 它提供了几个用于处理 gRPC 流量的配置指令,包括错误拦截、标头操作等。
对于非 HTTP/gRPC 流量,流模块现在可在 Azure 的 NGINXaaS 中使用。 该模块支持代理和负载均衡 TCP 和 UDP 流量。
适用于 Azure 的 NGINXaaS 现在可以用作第 4 层 TCP/UDP 和第 7 层 HTTP/HTTP 云原生负载均衡器。 为什么这很重要? 您无需部署两个不同的服务或负载均衡器,只需部署一个负载均衡器并将其配置为同时在两个层上运行,即可使用 NGINXaaS for Azure,从而简化您的云架构并降低成本。
您可以在此处了解配置。
NGINXaaS for Azure 是一种基于消费的服务,按小时计量并按月按NGINX 容量单位 (NCU)计费。 我们最近将部署容量从 80 个 NCU 增加了一倍至 160 个 NCU。 客户可以部署一个由 20 个 NCU 组成的小型系统,如果工作量增加,则可以扩展到 160 个 NCU。 此外,客户还可以选择在开始时部署多达 160 个 NCU。
为了提供从本地到完全托管的云产品的简便的升级配置体验,我们添加了许多 NGINX Plus 指令。 请在此处参考我们在 NGINXaaS for Azure 中支持的所有 NGINX Plus 指令。
我们始终在改进和扩展您使用 NGINX 和 F5 技术的方式,以便在任何地点保护、交付和优化每个应用程序和 API。 通过上述功能以及其他添加到 Azure 的 NGINXaaS 的新功能,更多的 Azure 用户可以借助 NGINX Plus 的强大功能解决大量应用程序和 API 问题,而无需管理额外的 VM 或容器基础设施的开销。
如果您想了解有关 Azure 的 NGINXaaS 的更多信息,我们鼓励您查看产品文档。 如果您准备尝试 Azure 的 NGINXaaS,请访问Azure 市场或联系我们讨论您的用例。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”