Anunciando o NGINX Plus R31

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 31 (R31). Baseado no NGINX Open Source, o NGINXPlus é o único software tudo-em-um de servidor web, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os recursos novos e aprimorados do NGINX Plus R31 incluem:

• Relatórios de uso nativo do NGINX – O NGINX Plus agora tem suporte nativo para relatórios sobre implantações do NGINX em sua organização, permitindo uma visão consolidada da sua infraestrutura NGINX no NGINX Instance Manager. Esse recurso permite governança aprimorada de instâncias do NGINX para fins de conformidade.
• Melhorias na configuração SNI – Anteriormente, o nome do servidor que passava pela Identificação de Nome do Servidor (SNI) usava a diretiva proxy_ssl_name e era usado por todos os servidores no grupo upstream. O NGINX Plus R31 permite que este SNI seja definido em um servidor upstream selecionado.
• Execução periódica de tarefas com NGINX JavaScript – O NGINX JavaScript introduz a diretiva js_periodic para permitir a execução de conteúdo em intervalos periódicos. Esse aprimoramento elimina a necessidade de configurar uma tarefa cron e pode ser configurado para ser executado em todos os processos de trabalho ou em processos específicos para desempenho ideal.
• Uma melhor experiência de inicialização do NGINX – O NGINX Plus R31 traz melhorias na experiência geral de inicialização do NGINX em casos onde há um grande número de “locais” na configuração.
• Otimizações e melhorias do QUIC+HTTP/3 – O NGINX Plus R31 adiciona muitos aprimoramentos e otimizações de desempenho à implementação do QUIC, incluindo suporte para descoberta de unidade máxima de transmissão (MTU) do caminho, melhorias no controle de congestionamento e a capacidade de reutilizar o contexto criptográfico em toda a sua sessão QUIC.

Completando o lançamento, estão novos recursos e correções de bugs herdados do NGINX Open Source e atualizações do módulo JavaScript do NGINX.

Mudanças importantes no comportamento

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

Descontinuação do módulo OpenTracing

O módulo OpenTracing que foi introduzido no NGINX Plus R18 está sendo descontinuado. Ele está marcado para ser removido a partir da versão futura do NGINX Plus R34. O pacote estará disponível com todas as versões do NGINX Plus até então. É altamente recomendável usar o módulo OpenTelemetry que foi introduzido no NGINX Plus R29.

Mensagem de aviso por não relatar o uso do NGINX

Os usuários do NGINX Plus devem relatar seu uso do NGINX à F5 para fins de conformidade. Com o lançamento do NGINX Plus R31, a capacidade de relatar o uso do NGINX ao NGINX Instance Manager está presente nativamente e é habilitada por padrão. Uma mensagem de aviso será registrada se a instância do NGINX não conseguir fornecer suas informações de uso ao NGINX Instance Manager por qualquer motivo.

Consulte a seção Relatórios de uso nativo do NGINX para obter detalhes sobre como configurar esse recurso em seu ambiente.

Mudanças no suporte da plataforma

Novos sistemas operacionais suportados:

• FreeBSD 14
• Alpino 3.19

Sistemas operacionais mais antigos removidos:

• Alpine 3.15, que atingiu o fim de sua vida útil (EOL) em 1º de novembro de 2023

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

• FreeBSD 12 que chegará ao EOL em 31 de dezembro de 2023

Novos recursos em detalhes

Relatório de uso nativo do NGINX

O NGINX Plus R31 introduz comunicação nativa com o NGINX Instance Manager na sua rede para automatizar a conformidade de licenciamento. Se você participar do Programa de Consumo Flex do F5 , não precisará mais rastrear manualmente suas instâncias do NGINX Plus.

Por padrão, o NGINX Plus tentará descobrir o NGINX Instance Manager na inicialização por meio de uma pesquisa de DNS do nome do host nginx-mgmt.local . Embora o nome do host seja configurável, sugerimos (para simplificar) adicionar um registro A ao seu DNS local, associando o nome do host padrão ao endereço IP do sistema que executa o NGINX Instance Manager. O NGINX Plus estabelecerá uma conexão TLS com o NGINX Instance Manager, relatando seu número de versão, nome do host e identificador exclusivo a cada trinta minutos.

Para uma camada adicional de segurança, também sugerimos provisionar essa conexão com mTLS usando o bloco de configuração mgmt opcional. Em uma cadência regular, o NGINX Instance Manager relatará o uso total de instâncias do NGINX Plus para um serviço F5.

Você verá uma mensagem de aviso no seu log de erros se o NGINX Plus tiver problemas para resolver o nome do host nginx-mgmt.local ou se comunicar com o NGINX Instance Manager.

Este é um exemplo de uma mensagem de erro indicando que a instância do NGINX Plus não consegue resolver nginx-mgmt.local :

2023/12/21 21:02:01 [aviso] 3050#3050: relatório de uso: host não encontrado resolvendo endpoint "nginx-mgmt.local”

E aqui está um exemplo de uma mensagem de erro indicando que a instância do NGINX Plus está tendo dificuldades de comunicação com o NGINX Instance Manager:

2023/12/21 21:02:01 [aviso] 3184#3184: relatório de uso: conexão com tempo limite esgotado

Personalizando as configurações do bloco de configuração mgmt

Se você preferir ajustar como sua instância do NGINX Plus se comunica com o NGINX Instance Manager, você pode optar por usar o novo bloco de configuração mgmt e as diretivas associadas. Isso permite que você defina um resolvedor personalizado, use um endereço IP ou nome de host alternativo para identificar seu sistema NGINX Instance Manager, especifique opções de TLS, use mTLS para maior segurança e especifique outros parâmetros personalizados.

A seguir está um exemplo de configuração personalizada:

mgmt {
usage_report endpoint=instance-manager.local interval=30m;
resolver 192.168.0.2; # IP DNS interno de exemplo

uuid_file /var/lib/nginx/nginx.id;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers PADRÃO;

ssl_certificate client.pem;
ssl_certificate_key client.key;

ssl_trusted_certificate trusted_ca_cert.crt;
ssl_verify on;
ssl_verify_depth 2;
}

Para obter detalhes adicionais sobre essas diretivas, consulte a documentação do produto .

Para obter mais informações sobre como baixar e instalar o NGINX Instance Manager, consulte o guia de instalação .

Observação:  Se você estiver usando uma versão anterior do NGINX Plus, ainda poderá relatar suas instâncias seguindo estas instruções .

Melhorias na configuração SNI

Antes deste lançamento, o NGINX Plus presumia que todos os servidores em um grupo upstream eram idênticos. Isso significa que eles precisavam ser capazes de responder às mesmas solicitações, responder ao mesmo nome SNI (quando proxy_ssl_server_name é usado) e retornar certificados SSL correspondentes ao mesmo nome.

Entretanto, existem cenários em que esse comportamento não é suficiente. Por exemplo, se vários servidores virtuais forem compartilhados por trás de um servidor upstream e precisarem ser diferenciados por um SNI e/ou cabeçalho de host diferente para rotear solicitações para recursos específicos. Também é possível que o mesmo certificado não possa ser usado em todos os servidores no grupo upstream ou que haja limitações para colocar servidores upstream em grupos upstream separados.

O NGINX Plus R31 introduz suporte para que SNI seja configurado por servidor upstream. A variável $upstream_last_server_name refere-se ao nome do servidor upstream selecionado, que pode então ser passado para o servidor proxy usando as diretivas proxy_ssl_server_name e proxy_ssl_name .

Veja como definir proxy_ssl_server_name como on , permitindo que um nome de servidor passe pelo SNI:
proxy_ssl_server_name ativado;

E é assim que se passa o nome do servidor upstream selecionado usando proxy_ssl_name :
proxy_ssl_name $upstream_last_server_name;

Execução periódica de tarefas com NGINX JavaScript

O NGINX JavaScript v0.8.1 introduziu uma nova diretiva js_periodic que está disponível nos contextos http e stream . Esta diretiva permite especificar um manipulador de conteúdo JavaScript para ser executado em intervalos regulares. Isso é útil em casos em que o código personalizado precisa ser executado em intervalos periódicos e pode exigir acesso às variáveis NGINX. O manipulador de conteúdo recebe um objeto de sessão como argumento e também tem acesso a objetos globais.

Por padrão, o manipulador de conteúdo é executado no processo de trabalho 0, mas pode ser configurado para ser executado em processos de trabalho específicos ou em todos os processos de trabalho.

Esta diretiva está disponível no contexto de localização :

example.conf:

location @periodics {

# a ser executado em intervalos de 15 minutos nos processos de trabalho 1 e 3
js_periodic main.handler interval=900s worker_affinity=0101;

resolver 10.0.0.1;
js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

manipulador(es) de função assíncrona {
let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
let body = await reply.text();

ngx.log(ngx.INFO, body);
}

Para obter detalhes de sintaxe e configuração, consulte a documentação do NGINX JavaScript .

Uma melhor experiência de inicialização do NGINX

Em cenários em que uma configuração NGINX contém um grande número de “locais”, o tempo de inicialização do NGINX pode levar um tempo considerável. Em muitos casos, isso pode não ser aceitável. O problema raiz está no algoritmo de classificação usado para classificar a lista de locais.

O NGINX R31 apresenta um aprimoramento que troca o algoritmo de classificação existente da classificação por inserção , que tem uma complexidade de tempo de O(n2) , para a classificação por mesclagem com uma complexidade de tempo de O(n*log n) .

Em uma configuração de teste com 20.000 locais, observou-se que o tempo total de inicialização foi reduzido de 8 segundos para 0,9 segundos após essa atualização.

Otimizações e melhorias do QUIC+HTTP/3

O NGINX Plus R31 introduz vários aprimoramentos e otimizações de desempenho na implementação QUIC+HTTP/3, como:

• Descoberta da unidade máxima de transmissão (MTU) do caminho ao usar QUIC+HTTP/3 – A MTU do caminho é uma medida em bytes do maior tamanho de quadro ou pacote de dados que pode ser transmitido por uma rede. Antes dessa mudança, a implementação do QUIC usava um MTU de caminho de 1200 bytes para todos os datagramas. O NGINX Plus agora tem suporte para descobrir o tamanho do MTU do caminho, que é então usado para todos os datagramas de saída.
• Reutilizar contexto criptográfico em toda a sessão QUIC – Essa otimização está relacionada ao comportamento de criptografia e descriptografia de pacotes QUIC. Anteriormente, um contexto criptográfico separado era criado para cada operação de criptografia ou descriptografia. Agora, o mesmo contexto é usado em toda a sessão QUIC, resultando em melhor desempenho.

Otimizações adicionais de desempenho incluem a redução de possíveis atrasos ao enviar pacotes de confirmação, colocando quadros de confirmação (ACK) na frente da fila para reduzir retransmissões de quadros e atrasos na entrega de quadros ACK, e melhorias no comportamento de controle de congestionamento no modo Generic Segmentation Offload (GSO).

Outras melhorias e correções de bugs no NGINX Plus R31

Módulo mgmt adicional

No NGINX Plus R31, o ngx_mgmt_module permite que você relate informações de uso do NGINX ao NGINX Instance Manager. Essas informações incluem o nome do host NGINX, a versão do NGINX e um identificador de instância exclusivo.

O módulo fornece diversas diretivas para ajustar como sua instância NGINX se comunica com o NGINX Instance Manager. Para uma lista completa de diretivas e opções de configuração disponíveis, consulte a documentação do NGINX .

Correções de bugs no módulo MQTT

O suporte ao Message Queuing Telemetry Transport (MQTT) foi introduzido no NGINX Plus R29 e esta versão contém algumas correções de bugs para problemas observados no módulo MQTT.

Uma correção importante aborda um problema de mensagens CONNECT sendo rejeitadas quando uma senha não era fornecida. Anteriormente, esperávamos incondicionalmente que o campo de nome de usuário fosse seguido pela senha. Existem, no entanto, casos especiais na especificação MQTT – como autenticação anônima – em que fornecer uma senha não é obrigatório. A correção verifica condicionalmente se a senha é esperada ou não, observando o campo cflags do pacote. Se o sinalizador não estiver definido, isso significa que a senha não é obrigatória.

Outra correção de bug interrompe a análise de mensagens MQTT CONNECT quando o comprimento da mensagem é menor que o número de bytes recebidos.

Suporte a HTTP/3 server_tokens com variáveis

O NGINX Plus R31 adiciona suporte para variáveis server_tokens ausentes para conexões HTTP/3. O campo de string pode ser usado para definir explicitamente a assinatura em páginas de erro e o valor do campo de cabeçalho de resposta “Servidor”. Se o campo string estiver vazio, desabilita a emissão do campo “Servidor”.

Alterações herdadas do NGINX Open Source

O NGINX Plus R31 é baseado no NGINX Open Source 1.25.3 e herda alterações funcionais, recursos e correções de bugs feitos desde o lançamento do NGINX Plus R30 (no NGINX 1.25.2 e 1.25.3).

Recursos

• Descoberta de MTU de caminho ao usar QUIC – Anteriormente, um tamanho padrão de 1200 MTU era usado para todos os datagramas. Como parte das melhorias do QUIC+HTTP/3, adicionamos suporte para descobrir o tamanho do MTU do caminho, que é então usado para todos os datagramas de saída.
• Otimizações de desempenho no QUIC – A versão principal 1.25.2 do NGINX introduziu otimizações na implementação do QUIC para reutilizar o contexto criptográfico para toda a sessão QUIC. Isso reduz atrasos no envio de pacotes ACK e coloca os quadros ACK na frente da fila para diminuir as retransmissões de quadros e atrasos na entrega de quadros ACK.
• Suporte para o conjunto de cifras TLS_AES_128_CCM_SHA256 ao usar HTTP/3 – Este aprimoramento adiciona suporte TLS_AES_128_CCM_SHA256 ao QUIC, que atualmente é o único conjunto de cifras não suportado pela implementação NGINX QUIC. Ele é desabilitado por padrão no OpenSSL e pode ser habilitado com esta diretiva: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Forneça nginx appName ao carregar configurações OpenSSL – Ao usar a interface OPENSSL_init_ssl() , em vez de verificar OPENSSL_VERSION_NUMBER , o NGINX agora testa se OPENSSL_INIT_LOAD_CONFIG está definido e é verdadeiro. Isso garante que a interface não seja usada com BoringSSL e LibreSSL, pois eles não fornecem configurações adicionais de inicialização de biblioteca (principalmente, a chamada OPENSSL_INIT_set_config_appname() ).

Mudanças

• Mudança no algoritmo de classificação de filas do NGINX – Conforme detalhado acima, o NGINX agora usa a classificação por mesclagem , que tem uma complexidade de tempo de O(n*log n) . Isso cria uma melhor experiência de inicialização do NGINX , especialmente quando há um número muito alto de “locais” na configuração.
• Limite de manipulação de fluxo de iteração HTTP/2 – Esta melhoria garante a detecção antecipada de ataques de inundação no NGINX, impondo um limite no número de novos fluxos que podem ser introduzidos em um loop de eventos. Este limite é o dobro do valor e é configurado usando http2_max_concurrent_streams . Ele é aplicado mesmo que o limite máximo de fluxos simultâneos permitidos nunca seja atingido para contabilizar casos em que os fluxos são redefinidos imediatamente após o envio das solicitações.

Correções de bugs

• Gerenciamento de buffer fixo com autodetecção HTTP/2 – Como parte da autodetecção HTTP/2 em conexões TCP simples, os dados iniciais são lidos primeiro em um buffer especificado pela diretiva client_header_buffer_size que não tem reserva de estado. Isso causou um problema em que o buffer poderia ser sobrelido ao salvar o estado. A correção atual permite ler apenas o tamanho do buffer disponível em vez do tamanho fixo do buffer. Este bug apareceu pela primeira vez na versão principal 1.25.1 do NGINX (NGINX Plus R30).
• Modo de transporte incorreto no modo de compatibilidade OpenSSL – Antes desta versão, a Camada de Compatibilidade OpenSSL causava atraso na conexão, caso um parâmetro de transporte incorreto fosse enviado pelo cliente. A correção lida facilmente com esse comportamento, primeiro notificando o usuário sobre o parâmetro incorreto e, posteriormente, fechando a conexão.
• Manipulação fixa de cabeçalhos de status sem frase-razão – Um cabeçalho de status com uma “frase-razão” vazia como Status: 404 era válido de acordo com a especificação da Common Gateway Interface (CGI), mas perdia o espaço final durante a análise. Isso resultou em uma linha de status HTTP/1.1 404 na resposta, o que viola a especificação HTTP devido à ausência de um espaço final. Com essa correção de bug, apenas o código de status é usado nessas linhas curtas de cabeçalho de status, então o NGINX gerará a própria linha de status com o espaço e a frase de motivo apropriada, se disponível.
• Vazamento de memória corrigido em recargas de configuração com PCRE2 – Esse problema ocorria quando o NGINX era configurado para usar PCRE2 na versão 1.21.5 ou superior.

Para obter a lista completa de novas alterações, recursos, correções de bugs e soluções alternativas herdadas de versões recentes, consulte o arquivo NGINX CHANGES .

Alterações no módulo JavaScript NGINX

O NGINX Plus R31 incorpora alterações do módulo NGINX JavaScript (njs) versão 0.8.2. Aqui está a lista de mudanças perceptíveis no njs desde a versão 0.8.0 (que fazia parte do lançamento do NGINX Plus R30).

Recursos

• Introduzido objeto console. Esses métodos foram introduzidos: error() , info() , log() , time() , timeEnd() e warn() .
• Foi introduzida a diretiva js_periodic para http e stream que permite especificar um manipulador JS para ser executado em intervalos regulares.
• Método items() implementado de um dicionário compartilhado . Este método retorna todos os pares chave-valor não expirados.

Mudanças

• Estendeu o módulo “fs”. Adicionado método existsSync() .

Correções de bugs

• Corrigido o módulo “xml”. Corrigida a manipulação de exceção XML quebrada no método parse() .
• Corrigido RegExp.prototype.exec() com expressão regular global (regexp) e entrada Unicode.
• Métodos size() e keys() corrigidos de um dicionário compartilhado .
• Corrigida exceção errônea em r.internalRedirect() que foi introduzida na versão 0.8.0.
• Corrigida a ordem incorreta das chaves em Object.getOwnPropertyNames() .
• Tratamento de resposta HEAD corrigido com Content-Length grande na API de busca.
• Método items() corrigido para um dicionário compartilhado.

Para uma lista abrangente de todos os recursos, alterações e correções de bugs, consulte o log de alterações do njs.

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que você atualize para o NGINX Plus R31 o mais rápido possível. Além de todos os excelentes novos recursos, você também obterá diversas correções e melhorias adicionais, e estar atualizado ajudará o NGINX a ajudá-lo caso precise abrir um tíquete de suporte.

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