Anunciando o NGINX Plus R27

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 27 (R27) . Baseado no NGINX Open Source, o NGINX Plus é o único servidor web de software completo , balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os recursos novos e aprimorados do NGINX Plus R27 incluem:

• Conexões Keepalive para verificações de integridade – Em versões anteriores, o NGINX Plus estabelecia uma nova conexão para cada verificação de integridade. O novo parâmetro keepalive_time para a diretiva HTTP health_check habilita conexões keepalive para verificações de integridade e define seu tempo de vida. Estabelecer novas conexões é computacionalmente caro, portanto, reutilizar conexões pode reduzir consideravelmente o uso da CPU quando há um grande número de servidores upstream.
• Suporte para Kernel TLS – O NGINX Plus agora oferece suporte para Kernel TLS (kTLS) em três sistemas operacionais que atendem aos requisitos para suportá-lo: FreeBSD 13, RHEL 9.0+ e Ubuntu 22.04 LTS .
• Métricas TLS para servidores upstream e virtuais – O NGINX Plus agora gera estatísticas TLS para servidores upstream e virtuais individuais quando o proxy por HTTPS está habilitado, além das estatísticas globais geradas em versões anteriores. Ter métricas do lado do cliente e do lado do servidor é útil ao solucionar problemas com handshakes TLS.
• Personalizando o código de erro de falhas de validação de JWT – No NGINX Plus R25 e R26 , você pode definir verificações de validação de JWT personalizadas, mas o código de erro retornado para uma falha de validação é sempre 401(Não autorizado) . O NGINX Plus R27 introduz o parâmetro de erro na diretiva auth_jwt_require , permitindo que você defina o código para401 ou 403(Proibido) para cada verificação para melhor distinguir entre erros de autenticação e autorização.
• Melhorias nos módulos NGINX JavaScript e Prometheus-njs – As melhorias no módulo NGINX JavaScript incluem novas diretivas para ajustar o comportamento da função ngx.fetch e um novo objeto que relata a versão njs como um número hexadecimal. O módulo Prometheus-njs agora pode converter métricas adicionais do NGINX Plus em um formato compatível com o Prometheus: o campo de códigos (que relata contagens de códigos de status HTTP individuais para servidores upstream e virtuais) e métricas geradas pelos módulos Limit Connections e Limit Requests.

Completando o lançamento, há um novo número de versão (8) para a API NGINX Plus e uma distribuição mais uniforme de conexões quando o modo EPOLLEXCLUSIVE é usado em kernels Linux.

Mudanças importantes no comportamento

Observação:  Se você estiver atualizando de uma versão diferente do NGINX Plus R26 , não deixe de conferir a seção Mudanças importantes no comportamento nos blogs de anúncios para todas as versões entre a versão atual e esta.

Novos sistemas operacionais suportados:

• Alpine Linux 3.16
• RHEL 9.0+ (adicionado ao NGINX Plus R26 após o lançamento inicial)
• Ubuntu 22.04 LTS (adicionado ao NGINX Plus R26 após o lançamento inicial)

Sistemas operacionais e arquiteturas mais antigos removidos:

• Alpine 3.12, que atingiu o fim da vida útil (EOL) em 1º de maio de 2022
• CentOS 8.1+, que atingiu o EOL em 31 de dezembro de 2021 (o RHEL 8.1+ ainda é compatível porque sua data de EOL é diferente)
• Arquitetura Power 8 (ppc64le; afeta CentOS e RHEL)

Sistemas operacionais e arquiteturas mais antigos foram descontinuados e programados para remoção no NGINX Plus R28:

• Debian 10, que chegará ao EOL em agosto de 2022

Novos recursos em detalhes

Conexões Keepalive para verificações de saúde

As conexões Keepalive entre o NGINX Plus e os servidores upstream melhoram significativamente o desempenho para casos de uso de proxy reverso e balanceamento de carga. Para proxy sobre HTTPS em particular, o custo computacional do handshake TLS completo necessário para cada nova conexão pode sobrecarregar seus recursos de computação, especialmente em ambientes de produção com um grande número de servidores upstream.

Em versões anteriores, o NGINX Plus não usava conexões keepalive para verificações de integridade, em vez disso, estabelecia uma nova conexão para cada verificação de integridade. O NGINX Plus R27 apresenta conexões keepalive para verificações de integridade HTTP. O novo parâmetro keepalive_time na diretiva health_check define o tempo de vida de cada conexão keepalive, após o qual uma nova conexão é estabelecida. Nossos testes indicam que, para proxy sobre HTTPS, as conexões keepalive reduzem o uso da CPU para verificações de integridade por um fator de 10 a 20 em servidores NGINX Plus. Eles também economizam recursos de CPU em servidores upstream.

O exemplo a seguir habilita conexões keepalive com uma duração de 60 segundos. Dada a frequência de verificação de integridade de 1 segundo definida pelo parâmetro de intervalo , o NGINX Plus incorre na despesa do handshake TLS e do estabelecimento de conexão apenas uma vez a cada 60 verificações de integridade.

Suporte para Kernel TLS

Transport Layer Security (TLS) é o protocolo padrão de fato para criptografia de dados na Internet. Infelizmente, proteger dados também aumenta a latência. A implementação do TLS no kernel (kTLS) melhora o desempenho ao servir conteúdo estático, reduzindo significativamente a necessidade de operações de cópia entre o espaço do usuário e o kernel.

A combinação do kTLS e da chamada de sistema sendfile() significa que os dados são criptografados diretamente no espaço do kernel antes de serem passados para a pilha de rede para transmissão, em vez de serem copiados para o espaço do usuário para criptografia usando bibliotecas TLS e então copiados de volta para o espaço do kernel antes da transmissão. O kTLS também permite o descarregamento do processamento TLS para o hardware, incluindo o descarregamento do processamento criptográfico simétrico TLS para dispositivos de rede.

Existem três requisitos para oferecer suporte ao kTLS:

1. O kernel do sistema operacional oferece suporte a ele
2. A distribuição do sistema operacional inclui a biblioteca de criptografia OpenSSL 3.0+ compilada com suporte a kTLS
3. O NGINX Plus (ou NGINX Open Source) é construído com a biblioteca de criptografia OpenSSL 3.0+

Em outubro de 2021, adicionamos suporte para kTLS ao NGINX Open Source 1.21.4 em plataformas que atendem aos requisitos 1 e 2. Agora estamos adicionando suporte para kTLS no NGINX Plus nestas plataformas:

• FreeBSD 13 (no NGINX Plus R26 e posterior)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Métricas TLS para servidores upstream e virtuais

Quando o NGINX Plus é implantado como um proxy reverso ou balanceador de carga, a API do NGINX Plus fornece um rico conjunto de métricas sobre tráfego, códigos de resposta e latência para cada servidor upstream e virtual, permitindo que os clientes observem e monitorem o desempenho e a disponibilidade do servidor.

Em versões anteriores, o NGINX Plus gerava métricas sobre a atividade e os erros de TLS em todo o sistema quando conexões HTTPS eram usadas entre o NGINX Plus e os servidores upstream, nos contextos http e stream (estabelecidos com as diretivas proxy_pass https: //path-to-upstream e proxy_ssl on , respectivamente). As estatísticas abrangem handshakes, falhas e reutilizações de sessão (conforme configurado com a diretiva proxy_ssl_session_reuse ).

O NGINX Plus R27 gera essas métricas TLS para servidores upstream individuais cuja configuração inclui a diretiva zone e para servidores virtuais cuja configuração inclui a diretiva status_zone . Ter métricas do lado do cliente e do lado do servidor é útil ao solucionar problemas com handshakes TLS.

O exemplo a seguir habilita a coleta de estatísticas no servidor upstream upstream1 e no servidor virtual que envia o tráfego para ele.

Esta saída indica que o primeiro servidor upstream participou de quatro handshakes TLS e duas sessões reutilizadas (para resumir, estamos mostrando a saída parcial para o primeiro servidor e omitindo a saída para os outros servidores upstream):

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "pares": [ { "id": 0, "servidor": "127.0.0.1:8081", "nome": "127.0.0.1:8081", "backup": falso, "peso": 1, "estado": "ativo", "ativo": 0, "ssl": { "apertos de mão": 4, "handshakes_failed": 0, "session_reuses": 2 } , "solicitações": 4, "header_time": 4, "tempo_de_resposta": 4, ... } ... ] }

Esta saída indica que o NGINX Plus participou de sete handshakes TLS:

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "processando": 0, "solicitações": 7, "respostas": { "1xx": 0, "2xx": 7, "3xx": 0, "4xx": 0, "5xx": 0, "códigos": { "200": 7 }, "total": 7 }, "descartado": 0, "recebido": 546, "enviado": 1134, "ssl": { "apertos de mão": 7, "handshakes_failed": 0, "session_reuses": 0 } ... }

Observe que a API do NGINX Plus ainda reúne as métricas globais de TLS disponíveis nas versões anteriores do NGINX Plus:

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "apertos de mão": 21, "handshakes_failed": 0, "session_reuses": 6 }

Personalizando o código de erro para falhas de validação do JWT

O NGINX Plus R25 introduziu<.htmla> a diretiva auth_jwt_require para definir verificações personalizadas durante o processo de validação do JWT. No NGINX Plus R25 e R26 , o código de erro retornado para uma falha de validação é sempre 401(Não autorizado) .

O NGINX Plus R27 introduz o parâmetro de erro na diretiva auth_jwt_require , que você pode usar para definir o código para401 ou403 (Proibido) para cada diretiva independentemente. Quando a solicitação de acesso de um usuário falha, a escolha dos códigos permite que você transmita a distinção entre uma falha de autenticação (JWT é inválido) e uma falha de autorização (declaração necessária ausente). Você também pode criar manipuladores personalizados para os códigos de erro, por exemplo, para retornar uma página especial explicando o erro (com a diretiva error_page ) ou para redirecionar a solicitação para um local interno nomeado para processamento posterior.

O código de status padrão permanece401 para falha dos seguintes tipos de verificações JWT:

• As verificações (não personalizadas) que são sempre realizadas
• Verificações personalizadas configuradas com auth_jwt_require , mas não com o parâmetro de erro

Se houver várias diretivas auth_jwt_require em um bloco de localização , elas serão avaliadas na ordem em que aparecem. O processamento para na primeira falha e o código de erro especificado é retornado.

Neste exemplo, a diretiva auth_jwt_require retorna403 se $req1 ou $req2 for avaliado como um valor vazio ou0 (zero).

Melhorias nos módulos NGINX JavaScript e Prometheus-njs

NGINX Plus R27 incorpora versões0.7.3 e0.7.4 do módulo JavaScript NGINX e inclui os seguintes aprimoramentos.

Diretivas adicionais para a API njs Fetch

O NGINX Javascript 0.5.3, incorporado ao NGINX Plus R24 , introduziu a função ngx.fetch (também chamada de Fetch API) para instanciar um cliente HTTP simples dentro do contexto de uma conexão TCP/UDP. (Para uma discussão sobre casos de uso da função, consulte Aproveitando serviços HTTP para TCP.htmlUDP com um cliente HTTP simples em nosso blog.)

O NGINX Plus R27 apresenta as seguintes diretivas para ajustar o comportamento da API Fetch:

• js_fetch_buffer_size [ HTTP ][ Stream ] – Define o tamanho do buffer usado para leitura e escrita.
• js_fetch_max_response_buffer_size [ HTTP ][ Stream ] – Define o tamanho máximo da resposta recebida com a API Fetch.
• js_fetch_timeout [ HTTP ][ Stream ] – Define o tempo limite para leitura e escrita entre duas operações sucessivas de leitura ou escrita (não para toda a resposta). Se nenhum dado for transmitido dentro do período de tempo limite, a conexão será encerrada.
• js_fetch_verify [ HTTP ][ Stream ] – Habilita ou desabilita a verificação do certificado do servidor HTTPS.

Número da versão relatado como um número hexadecimal

O novo objeto njs.version_number relata a versão do módulo njs como um número hexadecimal. (O objeto njs.version existente retorna a versão como uma sequência de caracteres.)

Módulo Prometheus-njs converte métricas adicionais

O módulo Prometheus-njs , que converte métricas do NGINX Plus em um formato compatível com o Prometheus, agora pode converter métricas expostas nestes endpoints adicionais:

• /http/limit_conns
• /http/limit_reqs
• O campo de códigos (que relata contagens de códigos de status HTTP individuais<.htmla>) em /http/server_zones e /http/upstreams
• /stream/limit_conns

Outras melhorias no NGINX Plus R27

Alteração da versão da API do NGINX Plus

O número da versão da API NGINX Plus foi atualizado de 7 para 8 para refletir a adição do campo ssl às métricas relatadas para servidores upstream e virtuais, conforme descrito em Métricas TLS para servidores upstream e virtuais . Os números de versões anteriores ainda funcionam, mas a saída não inclui métricas adicionadas em versões posteriores da API.

Melhor distribuição de conexões no modo Linux EPOLLEXCLUSIVE

O NGINX Plus R27 distribui conexões de forma mais uniforme entre os processos de trabalho do NGINX quando o modo EPOLLEXCLUSIVE é usado em kernels Linux. Normalmente, neste modo, o kernel notifica apenas o processo que foi o primeiro a adicionar o soquete de escuta à instância EPOLL. Como resultado, a maioria das conexões são manipuladas pelo primeiro processo de trabalho. O NGINX agora adiciona novamente o soquete periodicamente para dar a outros processos de trabalho a chance de aceitar conexões.

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R27 o mais rápido possível. Você também receberá diversas correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias .