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.
Na NGINX, mantemos duas ramificações no repositório de código-fonte aberto do NGINX, chamadas mainline e stable :
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:
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.
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.
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:
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
]ATRASADO
]REJEITADO
]DELAYED_DRY_RUN
]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
]REJEITADO
]REJECTED_DRY_RUN
]Para uma configuração de exemplo, consulte Melhorias na limitação de conexão .
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:
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.
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:
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.
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.
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.
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 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."