BLOG | NGINX

Apresentando NGINX 1.18 e 1.19

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Libby Meren
Libby Meren
Publicado em 26 de maio de 2020

Hoje lançamos o NGINX 1.19, a versão mais recente do NGINX Open Source, o servidor web mais popular da Internet . Este lançamento sinaliza o lançamento da ramificação de desenvolvimento do NGINX 1.19, após o lançamento da ramificação estável do NGINX 1.18 no mês passado.

Neste blog, discutimos o esquema de controle de versão do NGINX, relembramos o que aconteceu durante o ciclo de desenvolvimento do NGINX 1.17 e esperamos o que está por vir com o NGINX 1.19.

Explicação do versionamento do NGINX

Na NGINX, mantemos duas ramificações no repositório de código-fonte aberto do NGINX, chamadas mainline e stable :

  • Mainline é o ramo de desenvolvimento ativo onde os recursos mais recentes e correções de bugs são adicionados. É indicado por um número ímpar na segunda parte do número da versão, por exemplo 1.19.0.
  • A versão estável recebe correções para bugs de alta gravidade, mas não é atualizada com novos recursos. É indicado por um número par na segunda parte do número da versão, por exemplo 1.18.0.

O que significa ser “estável”

Para o NGINX Open Source, a palavra “estável” se refere à funcionalidade e frequência de atualização, não à qualidade do software. O branch estável nunca recebe novas funcionalidades durante seu ciclo de vida e normalmente recebe apenas uma ou duas atualizações para correções de bugs críticos.

O ramo estável tem um ciclo de vida anual. Todo mês de abril, descontinuamos a versão estável atual e, depois disso, nenhuma outra correção de bugs é feita. Isso aciona dois eventos:

  1. O ramo principal atual é bifurcado para criar o próximo ramo estável. O novo branch estável herda todas as correções de bugs, recursos e outras alterações que foram feitas no branch principal no ano anterior. No mês passado, o NGINX 1.17.10 foi bifurcado para produzir o NGINX 1.18.0. Observe que, até o lançamento da nova ramificação principal, "estável" é idêntico à ramificação principal atual e pode incluir novos recursos com apenas alguns dias de existência (esse estado termina hoje para a ramificação NGINX 1.18).
  2. O branch da linha principal recebe um “aumento de versão”; ou seja, a segunda parte do número da versão é incrementada para o próximo número ímpar. O desenvolvimento contínuo continua na versão principal, com novos lançamentos criados a partir da versão principal a cada quatro a seis semanas. Hoje marca o primeiro lançamento na linha principal do NGINX 1.19 com o NGINX 1.19.0.
A edição de 2020 do “version bump” anual para branches NGINX Open Source

Qual branch o NGINX Plus usa?

O NGINX Plus , a versão comercial do NGINX, é mantido em um repositório de código privado e separado. Ele é sempre baseado na versão mais recente do NGINX mainline, mesclado com os recursos e funcionalidades proprietários adicionais do NGINX Plus. No momento em que este artigo foi escrito, a versão mais recente é o NGINX Plus R21 , baseado no NGINX 1.17.10.

Qual filial devo usar?

Geralmente recomendamos usar o branch principal. É aqui que aplicamos todos os novos recursos, melhorias de desempenho e aprimoramentos. Testamos e controlamos ativamente a ramificação principal e, à medida que a fonte do NGINX Plus é construída, ela é completamente adequada para uso em produção.

Se você estiver preocupado com a sobrecarga de monitorar o branch principal para novos recursos e correções de bugs, usar o branch estável significa que você só precisa revisar novas funcionalidades uma vez por ano e correções de bugs com pouca frequência.

NGINX 1.17 em análise, também conhecido como o que há de novo no NGINX 1.18 Stable Branch

O ciclo de desenvolvimento do NGINX 1.17 introduziu alguns novos recursos e melhorias, incluindo melhorias na taxa de solicitação e limitação de conexão em ngx_http_limit_req_module e ngx_http_limit_conn_module respectivamente, adicionando uma diretiva de atraso de autenticação em ngx_http_core_module , introduzindo suporte a variáveis para a diretiva grpc_pass e variáveis que capturam o endereço e a porta do servidor com o Protocolo PROXY e muito mais. Antes de analisarmos as melhorias mais significativas em mais detalhes, aqui está o NGINX 1.17, em números:

  • 10 lançamentos principais
  • 37 correções de bugs
  • 11 novos recursos

Melhorias na taxa de solicitação HTTP e limitação de conexão

As diretivas limit_rate e limit_rate_after controlam a largura de banda (taxa em bytes por segundo) na qual o NGINX responde às solicitações. No NGINX 1.17.0 e posteriores, o parâmetro que define a taxa pode ser uma variável, o que permite o controle dinâmico com base nos atributos da solicitação. Para ver um exemplo, consulte Controle dinâmico de largura de banda .

O NGINX 1.17.1 adicionou o modo de execução a seco para limitação da taxa de solicitação, com a diretiva limit_req_dry_run . No modo de teste, o NGINX Plus não impõe limites de taxa, mas ainda rastreia a taxa de solicitações excessivas na zona de memória compartilhada e grava uma entrada no log de erros para cada solicitação que excede o limite configurado. Isso permite que você determine mais facilmente qual limite de taxa é apropriado para os padrões de tráfego em seu site. Para obter mais detalhes, consulte Testando limites de taxa no modo de teste .

Para tornar o modo de execução a seco ainda mais útil, o NGINX 1.17.6 adicionou a variável $limit_req_status , que pode ser incluída nas entradas do log de acesso para capturar o efeito da limitação de taxa no processamento de solicitações – especificamente, se uma solicitação:

  • Aprovado (foi encaminhado para os servidores de backend sem demora) [ APROVADO ]
  • Foi atrasado [ ATRASADO ]
  • Foi rejeitado [ REJEITADO ]
  • Foi contado como atrasado no modo de teste [ DELAYED_DRY_RUN ]
  • Foi contado como rejeitado no modo de teste [ REJECTED_DRY_RUN ]

O NGINX 1.17.6 também adicionou o modo de teste para limitação de conexão com a diretiva limit_conn_dry_run e a variável $limit_conn_status para capturar quando uma solicitação de conexão:

  • Aprovado (foi encaminhado para os servidores de backend) [ APROVADO ]
  • Foi rejeitado [ REJEITADO ]
  • Foi contado como rejeitado no modo de teste [ REJECTED_DRY_RUN ]

Para uma configuração de exemplo, consulte Melhorias na limitação de conexão .

Nova diretiva auth_delay

A diretiva auth_delay (adicionada no NGINX 1.17.10) permite o processamento atrasado de solicitações não autorizadas, com código de status 401(Não autorizado) devolvido ao cliente. Isso evita ataques de temporização ao processar solicitações de acesso. Os métodos de autenticação disponíveis incluem:

Suporte a variáveis para a diretiva grpc_pass

O suporte nativo para tráfego gRPC foi adicionado no NGINX 1.13.10, incluindo a diretiva grpc_pass , que especifica os servidores para os quais o NGINX passa solicitações gRPC. No NGINX 1.17.8, adicionamos a capacidade de incluir nomes de domínio no identificador do servidor, para dar suporte à pesquisa entre grupos de servidores upstream . Se o nome de domínio não for encontrado, o NGINX volta a usar um resolvedor para identificar endereços de servidor.

Variáveis adicionais do protocolo PROXY

O Protocolo PROXY permite que um proxy da Camada 4 forneça informações originais do cliente ao próximo proxy ou balanceador de carga que manipula a solicitação. Isso é importante para casos de uso em que você precisa saber o endereço IP do cliente – por exemplo, para limitar o número de conexões para cada cliente (usando a diretiva least_conn ). Esses dados estão disponíveis na variável $proxy_protocol_addr ( HTTP | Stream ).

Quando vários proxies de Camada 4 são implantados, pode ser importante para o NGINX saber o endereço IP e a porta do servidor proxy ao qual o cliente se conectou originalmente. Os metadados do protocolo PROXY incluem essas informações, e o NGINX 1.17.6 adicionou as seguintes variáveis aos módulos HTTP e Stream para capturá-las:

  • $proxy_protocol_server_addr ( HTTP | Fluxo )
  • $proxy_protocol_server_port ( HTTP | Fluxo )

Observação:  As variáveis serão preenchidas somente se você também incluir o parâmetro proxy_protocol na diretiva listen para habilitar o manuseio do Protocolo PROXY.

Suporte a variáveis adicionado às diretivas proxy_upload_rate e proxy_download_rate

As diretivas proxy_upload_rate e proxy_download_rate no módulo Stream controlam a taxa na qual o NGINX lê dados de um cliente ou servidor proxy, respectivamente. No NGINX 1.17.0 e posteriores, as diretivas aceitam um parâmetro variável, permitindo que você defina taxas específicas da condição.

Adicionado suporte para a chamada de sistema ioctl(FIONREAD)

Em sistemas Linux, a chamada de sistema ioctl() fornece o número de bytes legíveis do dispositivo host. O NGINX 1.17.5 adicionou ioctl(FIONREAD) para evitar loops quando dados são adicionados ao buffer de soquete mais rápido do que o NGINX consegue lê-los e processá-los. Quando o kernel não fornece o número de bytes disponíveis, podemos usar ioctl(FIONREAD) para obter essas informações de um buffer preenchido.

Especificando um local nomeado na função Perl internal_redirect

No NGINX 1.17.2 e posteriores, o parâmetro uri para a função internal_redirect no módulo Perl do NGINX pode ser um URI de escape ou um local nomeado.

O que está por vir no NGINX 1.19

O primeiro lançamento na linha principal NGINX 1.19 será lançado em breve. O NGINX 1.19.0 inclui suporte para QUIC (HTTP/3), a próxima atualização significativa dos protocolos de transporte para comunicação entre clientes e sites, aplicativos e APIs.

Se você quiser experimentar os recursos aprimorados do NGINX Plus, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."