Após um ano de desenvolvimento, foi introduzida uma nova ramificação estável do servidor HTTP de alto desempenho e do servidor proxy multiprotocolo nginx 1.20.0, que incorpora as alterações acumuladas na ramificação principal 1.19.x. No futuro, todas as mudanças no branch estável 1.20 estarão relacionadas à eliminação de erros e vulnerabilidades graves. Em breve será formado o ramo principal do nginx 1.21, no qual o desenvolvimento de novos recursos continuará. Para usuários comuns que não têm a tarefa de garantir a compatibilidade com módulos de terceiros, recomenda-se a utilização do branch principal, a partir do qual são formados os lançamentos do produto comercial Nginx Plus a cada três meses.
De acordo com um relatório de março da Netcraft, o nginx é usado em 20.15% de todos os sites ativos (há um ano 19.56%, há dois anos 20.73%), o que corresponde ao segundo lugar em popularidade nesta categoria (a participação do Apache corresponde a 25.38% (há um ano 27.64%), Google - 10.09%, Cloudflare - 8.51%.Ao mesmo tempo, ao considerar todos os sites, o nginx mantém a liderança e ocupa 35.34% do mercado (há um ano 36.91%, há dois anos - 27.52%), enquanto a participação do Apache corresponde a 25.98%, OpenResty (plataforma baseada em nginx e LuaJIT.) - 6.55%, Microsoft IIS - 5.96%.
Entre os milhões de sites mais visitados do mundo, a participação do nginx é de 25.55% (há um ano 25.54%, há dois anos 26.22%). Atualmente, cerca de 419 milhões de sites rodam Nginx (459 milhões há um ano). De acordo com a W3Techs, o nginx é usado em 33.7% dos sites dos milhões mais visitados, em abril do ano passado esse número era de 31.9%, no ano anterior - 41.8% (o declínio é explicado pela transição para a contabilidade separada do Cloudflare http servidor). A participação do Apache caiu ao longo do ano de 39.5% para 34%, e a participação do Microsoft IIS de 8.3% para 7%. A participação do LiteSpeed cresceu de 6.3% para 8.4% e do Node.js de 0.8% para 1.2%. Na Rússia, o nginx é usado em 79.1% dos sites mais visitados (há um ano - 78.9%).
As melhorias mais notáveis adicionadas durante o desenvolvimento da ramificação upstream 1.19.x:
- Adicionada a capacidade de verificar certificados de cliente usando serviços externos baseados no protocolo OCSP (Online Certificate Status Protocol). Para habilitar a verificação, é proposta a diretiva ssl_ocsp, para configurar o tamanho do cache - ssl_ocsp_cache, para redefinir a URL do manipulador OCSP especificado no certificado - ssl_ocsp_responder.
- O módulo ngx_stream_set_module está incluído, que permite atribuir um valor à variável server { listen 12345; defina $true 1; }
- Adicionada a diretiva proxy_cookie_flags para especificar sinalizadores para cookies em conexões com proxy. Por exemplo, para adicionar o sinalizador “httponly” ao Cookie “one”, e os sinalizadores “nosecure” e “samesite=strict” para todos os outros Cookies, você pode usar a seguinte construção: proxy_cookie_flags one httponly; proxy_cookie_flags ~ noscure samesite=strict;
Uma diretiva userid_flags semelhante para adicionar sinalizadores a cookies também é implementada para o módulo ngx_http_userid.
- Adicionadas diretivas “ssl_conf_command”, “proxy_ssl_conf_command”, “grpc_ssl_conf_command” e “uwsgi_ssl_conf_command”, com as quais você pode definir parâmetros arbitrários para configurar OpenSSL. Por exemplo, para priorizar cifras ChaCha e configuração avançada de cifras TLSv1.3, você pode especificar ssl_conf_command Opções PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
- Adicionada a diretiva "ssl_reject_handshake", que instrui a rejeitar todas as tentativas de negociação de conexões SSL (por exemplo, pode ser usada para rejeitar todas as chamadas com nomes de host desconhecidos no campo SNI). servidor {ouvir 443 ssl; ssl_reject_handshake ativado; } servidor {ouvir 443 ssl; nome_servidor exemplo.com; ssl_certificate exemplo.com.crt; ssl_certificate_key exemplo.com.key; }
- A diretiva proxy_smtp_auth foi adicionada ao proxy de correio, permitindo autenticar o usuário no backend usando o comando AUTH e o mecanismo PLAIN SASL.
- Adicionada a diretiva "keepalive_time", que limita o tempo de vida total de cada conexão keep-alive, após o qual a conexão será fechada (não confundir com keepalive_timeout, que define o tempo de inatividade após o qual a conexão keep-alive é fechada).
- Adicionada a variável $connection_time, através da qual você pode obter informações sobre a duração da conexão em segundos com precisão de milissegundos.
- Um parâmetro “min_free” foi adicionado às diretivas “proxy_cache_path”, “fastcgi_cache_path”, “scgi_cache_path” e “uwsgi_cache_path”, que regula o tamanho do cache com base na determinação do tamanho mínimo de espaço livre em disco.
- As diretivas "lingering_close", "lingering_time" e "lingering_timeout" foram adaptadas para funcionar com HTTP/2.
- O código de processamento de conexão em HTTP/2 é próximo da implementação HTTP/1.x. O suporte para as configurações individuais "http2_recv_timeout", "http2_idle_timeout" e "http2_max_requests" foi descontinuado em favor das diretivas gerais "keepalive_timeout" e "keepalive_requests". As configurações "http2_max_field_size" e "http2_max_header_size" foram removidas e "large_client_header_buffers" deve ser usado em seu lugar.
- Adicionada uma nova opção de linha de comando “-e”, que permite especificar um arquivo alternativo para gravar o log de erros, que será usado no lugar do log especificado nas configurações. Em vez do nome do arquivo, você pode especificar o valor especial stderr.
Fonte: opennet.ru