Anunciando o NGINX Plus R27

Prabhat Dixit

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 27 (R27). Baseado no NGINX Open Source, o NGINX Plus é o único software completo que reúne servidor web, 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 – Nas versões anteriores, o NGINX Plus estabelecia uma nova conexão para cada verificação de integridade. O novo parâmetro keepalive_time da diretiva HTTP health_check habilita conexões keepalive para verificações de integridade e define seu tempo de vida. Estabelecer novas conexões exige muitos recursos computacionais; portanto, reutilizar conexões pode reduzir consideravelmente o uso da CPU quando há um grande número de servidores upstream.
• Suporte a TLS no kernel – O NGINX Plus agora oferece suporte a TLS no kernel (kTLS) em três sistemas operacionais que atendem aos requisitos necessários: FreeBSD 13, RHEL 9.0+ e Ubuntu 22.04 LTS.
• Métricas de TLS para servidores upstream e virtuais – O NGINX Plus agora gera estatísticas de TLS para upstreams e servidores virtuais individuais quando o proxy via HTTPS está habilitado, além das estatísticas globais que já gerava em versões anteriores. Ter métricas tanto do lado do cliente quanto do lado do servidor ajuda a solucionar problemas com handshakes de TLS.
• Personalização do código de erro para falhas de validação de JWT – No NGINX Plus R25 e R26, você pode definir verificações personalizadas de validação de JWT, mas o código de erro retornado em caso de falha de validação é sempre 401 (Não autorizado). O NGINX Plus R27 introduz o parâmetro error na diretiva auth_jwt_require, permitindo definir o código como 401 ou 403 (Proibido) para cada verificação, a fim de distinguir melhor entre erros de autenticação e de autorização.
• Aprimoramentos nos módulos NGINX JavaScript e Prometheus-njs – Os aprimoramentos no módulo NGINX JavaScript incluem novas diretivas para ajustar com precisão o comportamento da função ngx.fetch e um novo objeto que informa a versão do njs como um número hexadecimal. O módulo Prometheus-njs agora pode converter outras métricas do NGINX Plus para um formato compatível com o Prometheus: o campo codes (que informa as contagens de códigos de status HTTP individuais para servidores upstream e virtuais) e as métricas geradas pelos módulos Limit Connections e Limit Requests.

Para completar a versão estão um novo número de versão (8) para a API do NGINX Plus e uma distribuição mais uniforme das conexões quando o modo EPOLLEXCLUSIVE é usado em kernels Linux.

Mudanças importantes de comportamento

Observação: Se você estiver atualizando de uma versão diferente do NGINX Plus R26, consulte a seção Alterações importantes de comportamento nos blogs de anúncio de todas as versões entre a sua versão atual e esta.

Novos sistemas operacionais compatíveis:

• 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 chegou ao fim da vida útil (EOL) em 1º de maio de 2022
• CentOS 8.1+, que chegou ao fim da vida útil (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 o CentOS e o RHEL)

Sistemas operacionais e arquiteturas mais antigos, descontinuados e com remoção programada para o NGINX Plus R28:

• Debian 10, que chegará ao fim da vida útil (EOL) em agosto de 2022

Novos recursos em detalhes

Conexões persistentes para verificações de integridade

Conexões keepalive entre o NGINX Plus e os servidores upstream melhoram significativamente o desempenho em casos de uso de proxy reverso e balanceamento de carga. No caso específico de proxy via HTTPS, o custo computacional do handshake TLS completo exigido para cada nova conexão pode sobrecarregar seus recursos computacionais, especialmente em ambientes de produção com um grande número de servidores upstream.

Nas 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 sondagem de integridade. O NGINX Plus R27 introduz conexões keepalive para verificações de integridade HTTP. O novo parâmetro keepalive_time da 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 por HTTPS, as conexões keepalive reduzem o uso de CPU nas verificações de integridade por um fator de 10 a 20 nos servidores NGINX Plus. Elas também economizam recursos de CPU nos servidores upstream.

O exemplo a seguir habilita conexões keepalive com uma vida útil de 60 segundos. Considerando a frequência de verificação de integridade de 1 segundo definida pelo parâmetro interval, o NGINX Plus incorre no custo do handshake TLS e do estabelecimento da conexão apenas uma vez a cada 60 verificações de integridade.

Carregando exemplo de código…

Suporte a TLS no kernel

O Transport Layer Security (TLS) é o protocolo padrão de fato para criptografia de dados na Internet. Infelizmente, a proteção dos dados também aumenta a latência. A implementação do TLS no kernel (kTLS) melhora o desempenho ao fornecer 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 com a chamada de sistema sendfile() faz com que os dados sejam criptografados diretamente no espaço do kernel antes de serem encaminhados à pilha de rede para transmissão, em vez de serem copiados para o espaço do usuário para criptografia por meio de bibliotecas TLS e, depois, copiados de volta para o espaço do kernel antes da transmissão. O kTLS também permite transferir o processamento de TLS para o hardware, incluindo o processamento de criptografia simétrica TLS por dispositivos de rede.

Há 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 criptográfica OpenSSL 3.0+, compilada com suporte a kTLS
3. O NGINX Plus (ou NGINX Open Source) é compilado com a biblioteca criptográfica OpenSSL 3.0+

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

• FreeBSD 13 (no NGINX Plus R26 e versões posteriores)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Métricas de TLS para servidores upstream e virtuais

Quando o NGINX Plus é implantado como proxy reverso ou balanceador de carga, a API do NGINX Plus fornece um amplo 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 dos servidores.

Em versões anteriores, o NGINX Plus gerava métricas sobre atividades e erros de TLS em todo o sistema quando conexões HTTPS eram usadas entre o NGINX Plus e os servidores upstream, tanto nos contextos http quanto stream (estabelecidas, respectivamente, com as diretivas proxy_pass https://path-to-upstream e proxy_ssl on). 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 de 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 tanto do lado do cliente quanto do lado do servidor ajuda a solucionar problemas com handshakes de TLS.

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

Carregando exemplo de código…

Essa saída indica que o primeiro servidor upstream participou de quatro handshakes TLS e de duas sessões reutilizadas (para fins de concisão, mostramos apenas parte da saída do primeiro servidor e omitimos a saída dos demais servidores upstream):

$ 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,
      ...
    }
    ...
  ]
}

Essa 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{
  "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 }
  ...
}

Observe que a API do NGINX Plus ainda coleta as métricas globais de TLS disponíveis em versões anteriores do NGINX Plus:

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

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

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 em caso de falha na validação é sempre 401 (Não autorizado).

NGINX Plus R27 apresenta o parâmetro error para a diretiva auth_jwt_require, que pode ser usado para definir o código como 401 ou 403 (Proibido) de forma independente para cada diretiva. Quando a solicitação de acesso de um usuário falha, a escolha dos códigos permite indicar a diferença entre uma falha de autenticação (o JWT é inválido) e uma falha de autorização (a declaração obrigatória está ausente). Também é possível 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 redirecionar a solicitação para um local interno nomeado para processamento adicional.

O código de status padrão continua sendo 401 para falhas nos seguintes tipos de verificações de JWT:

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

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

Neste exemplo, a diretiva auth_jwt_require retorna 403 se $req1 ou $req2 for avaliada como um valor vazio ou 0 (zero).

Carregando exemplo de código…

Aprimoramentos nos módulos NGINX JavaScript e Prometheus-njs

O NGINX Plus R27 incorpora as versões 0.7.3 e 0.7.4 do módulo NGINX JavaScript e inclui os seguintes aprimoramentos.

Diretivas adicionais para a API Fetch do njs

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

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

• js_fetch_buffer_size[HTTP][Stream] – Define o tamanho do buffer usado para leitura e gravação.
• 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 gravação entre duas operações sucessivas de leitura ou gravação (não para a resposta inteira). 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 informado como um número hexadecimal

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

Módulo Prometheus-njs converte métricas adicionais

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

• /http/limit_conns
• /http/limit_reqs
• O campo codes (que informa as 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 do 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 de TLS para servidores upstream e virtuais. Os números das versões anteriores ainda funcionam, mas a saída não inclui as métricas adicionadas em versões posteriores da API.

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

O NGINX Plus R27 distribui as conexões de maneira mais uniforme entre os processos de trabalho do NGINX quando o modo EPOLLEXCLUSIVE é usado em kernels Linux. Normalmente, nesse 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 é processada pelo primeiro processo de trabalho. Agora, o NGINX readiciona periodicamente o soquete para dar aos outros processos de trabalho a oportunidade de aceitar conexões.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R27 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que o teste – para segurança, balanceamento de carga e gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre o autor

Prabhat Dixit

Mais publicações de Prabhat Dixit