Anunciando o NGINX Plus R31

Prabhat Dixit

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 31 (R31). Baseado no NGINX Open Source, o NGINX Plus é a única solução de software completa 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 R31 incluem:

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

Completando a versão, há novos recursos e correções de bugs herdados do NGINX Open Source, além de atualizações no módulo JavaScript do NGINX.

Mudanças importantes de comportamento

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

Descontinuação do módulo OpenTracing

O módulo OpenTracing, introduzido no NGINX Plus R18, está sendo descontinuado. Sua remoção está prevista a partir da futura versão NGINX Plus R34. Até lá, o pacote será disponibilizado com todas as versões do NGINX Plus. É altamente recomendável usar o módulo OpenTelemetry introduzido no NGINX Plus R29.

Mensagem de aviso sobre a ausência de relatórios de uso do NGINX

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

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

Alterações no suporte a plataformas

Novos sistemas operacionais compatíveis:

• FreeBSD 14
• Alpine 3.19

Sistemas operacionais mais antigos removidos:

• Alpine 3.15, que chegou ao fim da vida útil (EOL) em 1º de novembro de 2023

Sistemas operacionais mais antigos descontinuados e com remoção programada no NGINX Plus R32:

• FreeBSD 12, que chegará ao fim da vida útil (EOL) em 31 de dezembro de 2023

Novos recursos em detalhes

Relatórios nativos de uso do NGINX

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

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

Para adicionar uma camada extra de segurança, também sugerimos provisionar essa conexão com mTLS usando o mgmt bloco de configuração opcional. Em intervalos regulares, o NGINX Instance Manager informará a um serviço da F5 o uso total das instâncias do NGINX Plus.

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

Este é um exemplo de 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 ao resolver o endpoint "nginx-mgmt.local”

E aqui está um exemplo de mensagem de erro indicando que a instância do NGINX Plus está enfrentando dificuldades para se comunicar com o NGINX Instance Manager:

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

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

Se preferir ajustar detalhadamente 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 definir um resolvedor personalizado, usar um endereço IP ou nome de host alternativo para identificar seu sistema NGINX Instance Manager, especificar opções de TLS, usar mTLS para reforçar a segurança e especificar outros parâmetros personalizados.

Veja a seguir um exemplo de configuração personalizada:

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP

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

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers DEFAULT;

    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 mais detalhes sobre essas diretivas, consulte a documentação do produto.

Para 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á reportar suas instâncias seguindo estas instruções.

Aprimoramentos na configuração de SNI

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

No entanto, há cenários em que esse comportamento não é suficiente. Por exemplo, quando vários servidores virtuais são compartilhados por trás de um servidor upstream e precisam ser diferenciados por um SNI e/ou cabeçalho de host distinto para encaminhar as solicitações a recursos específicos. Também é possível que o mesmo certificado não possa ser usado em todos os servidores do grupo upstream ou que haja limitações para colocar os servidores upstream em grupos upstream separados.

O NGINX Plus R31 introduz suporte à configuração de SNI por servidor upstream. A variável $upstream_last_server_name refere-se ao nome do servidor upstream selecionado, que pode então ser passado ao servidor que recebe o 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 seja transmitido por meio do SNI:
proxy_ssl_server_name on;

E é assim que você 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 JavaScript do NGINX

O NGINX JavaScript v0.8.1 introduziu uma nova diretiva, js_periodic, disponível nos contextos http e stream. Essa diretiva permite especificar um manipulador de conteúdo JavaScript para ser executado em intervalos regulares. Isso é útil quando um código personalizado precisa ser executado periodicamente e pode exigir acesso às variáveis do 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 eles.

Esta diretiva está disponível no contexto location:

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 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:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();

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

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

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

Em cenários em que uma configuração do NGINX contém um grande número de “locations”, a inicialização do NGINX pode levar um tempo considerável. Em muitos casos, isso pode não ser aceitável. A causa principal está no algoritmo de ordenação usado para organizar a lista de locations.

O NGINX R31 apresenta uma melhoria que substitui o algoritmo de ordenação existente, de ordenação por inserção, que tem complexidade de tempo de O(n2), para ordenação por intercalação, com complexidade de tempo de O(n*log n).

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

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

O NGINX Plus R31 apresenta diversos aprimoramentos e otimizações de desempenho na implementação de 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 alteração, a implementação do QUIC usava uma MTU de caminho de 1.200 bytes para todos os datagramas. Agora, o NGINX Plus oferece suporte à descoberta do tamanho da MTU do caminho, que passa a ser usado para todos os datagramas de saída.
• Reutilização do contexto criptográfico durante toda a sessão QUIC – Essa otimização está relacionada ao comportamento de criptografia e descriptografia dos pacotes QUIC. Anteriormente, um contexto criptográfico separado era criado para cada operação de criptografia ou descriptografia. Agora, o mesmo contexto é usado durante toda a sessão QUIC, resultando em melhor desempenho.

Otimizações adicionais de desempenho incluem a redução de possíveis atrasos no envio de pacotes de confirmação, a colocação de quadros de confirmação (ACK) no início da fila para reduzir retransmissões de quadros e atrasos na entrega de quadros ACK, além de melhorias no comportamento do 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, ngx_mgmt_module permite enviar informações de uso do NGINX ao NGINX Instance Manager. Essas informações incluem o nome do host do NGINX, a versão do NGINX e um identificador exclusivo da instância.

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

Correções de bugs no módulo MQTT

O suporte ao protocolo 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 resolve um problema em que as mensagens CONNECT eram rejeitadas quando uma senha não era fornecida. Anteriormente, esperávamos incondicionalmente que o campo de nome de usuário fosse seguido por uma senha. No entanto, há casos especiais na especificação MQTT — como a autenticação anônima — em que o fornecimento de uma senha não é obrigatório. A correção verifica condicionalmente se uma senha é esperada ou não, consultando 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 tamanho da mensagem é menor que o número de bytes recebidos.

Suporte a server_tokens do HTTP/3 com variáveis

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

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 implementados desde o lançamento do NGINX Plus R30 (no NGINX 1.25.2 e 1.25.3).

Recursos

• Descoberta da MTU do caminho ao usar QUIC – Anteriormente, um tamanho padrão de MTU de 1200 era usado para todos os datagramas. Como parte das melhorias no QUIC+HTTP/3, adicionamos suporte à descoberta do tamanho da MTU do caminho, que passa a ser usado em todos os datagramas de saída.
• Otimizações de desempenho no QUIC – A versão 1.25.2 da linha principal do NGINX introduziu otimizações na implementação do QUIC para reutilizar o contexto criptográfico durante toda a sessão QUIC. Isso reduz os atrasos no envio de pacotes ACK e coloca os quadros ACK no início da fila para diminuir as retransmissões de quadros e os atrasos na entrega de quadros ACK.
• Suporte ao conjunto de cifras TLS_AES_128_CCM_SHA256 ao usar HTTP/3 – Esse aprimoramento adiciona suporte a TLS_AES_128_CCM_SHA256 no QUIC, que atualmente é o único conjunto de cifras não compatível com a implementação de QUIC do NGINX. Ele vem desabilitado por padrão no OpenSSL e pode ser habilitado com esta diretiva: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Fornecer o appName do nginx ao carregar as configurações do 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 da biblioteca (principalmente a chamada OPENSSL_INIT_set_config_appname()).

Alterações

• Alteração no algoritmo de ordenação da fila do NGINX – Conforme detalhado acima, o NGINX agora usa ordenação por intercalação, que tem uma complexidade de tempo de O(n*log n). Isso proporciona uma melhor experiência de inicialização do NGINX, especialmente quando há um número muito elevado de “locations” na configuração.
• Limite de processamento de streams por iteração do HTTP/2 – Essa melhoria garante a detecção antecipada de ataques de inundação ao NGINX ao impor um limite ao número de novos streams que podem ser introduzidos em um único loop de eventos. Esse limite corresponde ao dobro do valor configurado por meio de http2_max_concurrent_streams. Ele é aplicado mesmo que o limite máximo de streams simultâneos permitidos nunca seja atingido, a fim de contemplar os casos em que os streams são redefinidos imediatamente após o envio das solicitações.

Correções de bugs

• Correção do gerenciamento de buffer com detecção automática de HTTP/2 – Como parte da detecção automática de HTTP/2 em conexões TCP simples, os dados iniciais são primeiro lidos em um buffer especificado pela diretiva client_header_buffer_size que não possui reserva de estado. Isso causava um problema em que a leitura podia ultrapassar os limites do buffer ao salvar o estado. A correção atual permite ler apenas o tamanho disponível do buffer, em vez de um tamanho fixo. Esse bug surgiu pela primeira vez na versão 1.25.1 da linha principal do NGINX (NGINX Plus R30).
• Modo de transporte incorreto no modo de compatibilidade com OpenSSL – Antes desta versão, a Camada de Compatibilidade com OpenSSL causava um atraso na conexão quando o cliente enviava um parâmetro de transporte incorreto. A correção trata esse comportamento de forma simples, primeiro notificando o usuário sobre o parâmetro incorreto e, em seguida, encerrando a conexão.
• Correção do tratamento de cabeçalhos de status sem frase de motivo – Um cabeçalho de status com uma “frase de motivo” vazia, como Status: 404 era válido de acordo com a especificação Common Gateway Interface (CGI), mas perdia o espaço final durante a análise. Isso resultava 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 no final. Com essa correção, apenas o código de status é usado em linhas curtas do cabeçalho Status desse tipo, permitindo que o próprio NGINX gere a linha de status com o espaço e a frase de motivo apropriada, se disponível.
• Corrigido o vazamento de memória ao recarregar configurações com PCRE2 – Esse problema ocorria quando o NGINX estava configurado para usar o PCRE2 na versão 1.21.5 ou posterior.

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

Alterações no módulo JavaScript do NGINX

O NGINX Plus R31 incorpora alterações do módulo NGINX JavaScript (njs) versão 0.8.2. Veja a lista de alterações relevantes no njs desde a versão 0.8.0 (que fazia parte da versão NGINX Plus R30).

Recursos

• Foi introduzido o objeto console. Estes métodos foram adicionados: error(), info(), log(), time(), timeEnd(), e warn().
• Foi introduzida a diretiva js_periodic para http e stream, que permite especificar um manipulador JS a ser executado em intervalos regulares.
• Implementado o método items() de um dicionário compartilhado. Esse método retorna todos os pares de chave-valor que ainda não expiraram.

Alterações

• O módulo “fs” foi ampliado. Foi adicionado o método existsSync().

Correções de bugs

• Corrigido o módulo “xml”. Corrigido o tratamento de exceções XML com falha no método parse().
• Corrigido o método RegExp.prototype.exec() com expressão regular global (regexp) e entrada Unicode.
• Corrigidos os métodos size(), e keys() de um dicionário compartilhado.
• Corrigida a exceção incorreta em r.internalRedirect() introduzida na versão 0.8.0.
• Corrigida a ordem incorreta das chaves em Object.getOwnPropertyNames().
• Corrigido o tratamento de respostas HEAD com Content-Length grande na API fetch.
• Corrigido o método items() de um dicionário compartilhado.

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

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 R31 o mais rápido possível. Além de todos os excelentes novos recursos, você também terá acesso a várias correções e melhorias adicionais. Manter-se em dia com as atualizações ajudará a NGINX a oferecer suporte caso você precise abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que o conheça. Você pode usá-lo para segurança, balanceamento de carga e casos de uso de gateway de API, ou como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Comece hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre o autor

Prabhat Dixit

Mais publicações de Prabhat Dixit