Dopo un anno di sviluppo, è stata presentata una nuova versione stabile del server HTTP ad alte prestazioni e del proxy multi-protocollo nginx 1.20.0, che raccoglie le modifiche accumulate nella versione principale 1.19.x. In futuro, tutte le modifiche nella versione stabile 1.20 saranno legate alla correzione di gravi bug e vulnerabilità. A breve sarà formata la versione principale nginx 1.21, in cui continuerà lo sviluppo di nuove funzionalità. Per gli utenti comuni, che non devono garantire compatibilità con moduli di terze parti, si consiglia di utilizzare la versione principale, su cui ogni tre mesi vengono rilasciate le versioni del prodotto commerciale Nginx Plus.
Secondo il report di marzo dell'azienda Netcraft, nginx è utilizzato nel 20,15% di tutti i siti attivi (un anno fa 19,56%, due anni fa 20,73%), il che corrisponde al secondo posto in termini di popolarità in questa categoria (la quota di Apache è del 25,38% (un anno fa 27,64%), Google - 10,09%, Cloudflare - 8,51%. Inoltre, considerando tutti i siti, nginx mantiene la leadership con il 35,34% del mercato (un anno fa 36,91%, due anni fa - 27,52%), mentre la quota di Apache è del 25,98%, OpenResty (piattaforma basata su nginx e LuaJIT.) - 6,55%, Microsoft IIS - 5,96%.
Tra il milione di siti più visitati al mondo, la quota di nginx è del 25,55% (un anno fa 25,54%, due anni fa 26,22%). Attualmente, circa 419 milioni di siti sono gestiti da nginx (un anno fa 459 milioni). Secondo i dati di W3Techs, nginx è utilizzato nel 33,7% dei siti tra i mille più visitati; ad aprile dello scorso anno questo valore era del 31,9%, mentre due anni fa era del 41,8% (il calo è spiegato dal passaggio a un conteggio separato del server http di Cloudflare). La quota di Apache è diminuita in un anno dal 39,5% al 34%, mentre quella di Microsoft IIS è scesa dall'8,3% al 7%. La quota di LiteSpeed è aumentata dal 6,3% all'8,4%, e quella di Node.js dallo 0,8% all'1,2%. In Russia, nginx è utilizzato nel 79,1% dei siti più visitati (un anno fa - 78,9%).
Le migliorie più significative aggiunte durante la formazione della versione principale 1.19.x:
- È stata aggiunta la possibilità di verifica dei certificati client con l'ausilio di servizi esterni basati sul protocollo OCSP (Online Certificate Status Protocol). Per attivare la verifica è stata proposta la direttiva ssl_ocsp, per impostare la dimensione della cache - ssl_ocsp_cache, per sovrascrivere l'URL del gestore OCSP specificato nel certificato - ssl_ocsp_responder.
- È stato incluso il modulo ngx_stream_set_module, che consente di assegnare un valore a una variabile server { listen 12345; set $true 1; }
- È stata aggiunta la direttiva proxy_cookie_flags per la specifica dei flag per i cookie nelle connessioni proxy. Ad esempio, per aggiungere al cookie «one» il flag «httponly», e per tutti gli altri cookie i flag «nosecure» e «samesite=strict», si può utilizzare la seguente struttura: proxy_cookie_flags one httponly; proxy_cookie_flags ~ nosecure samesite=strict;
Una direttiva simile userid_flags per aggiungere flag ai cookie è stata anch'essa implementata per il modulo ngx_http_userid.
- Sono state aggiunte le direttive «ssl_conf_command», «proxy_ssl_conf_command», «grpc_ssl_conf_command» e «uwsgi_ssl_conf_command», attraverso le quali è possibile specificare parametri arbitrari per la configurazione di OpenSSL. Ad esempio, per dare priorità ai cifrari ChaCha e configurare in modo avanzato i cifrari TLSv1.3, si può indicare ssl_conf_command Options PrioritizeChaCha; ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
- È stata aggiunta la direttiva «ssl_reject_handshake», che impone di rifiutare tutti i tentativi di negoziazione SSL-connessioni (ad esempio, può essere utilizzata per rifiutare tutte le richieste con nomi host sconosciuti nel campo SNI). server { listen 443 ssl; ssl_reject_handshake on; } server { listen 443 ssl; server_name example.com; ssl_certificate example.com.crt; ssl_certificate_key example.com.key; }
- Nel proxy di posta è stata aggiunta la direttiva proxy_smtp_auth, che consente di autenticare l'utente sul backend tramite il comando AUTH e meccanismo PLAIN SASL.
- È stata aggiunta la direttiva «keepalive_time», che limita il tempo massimo di vita di ciascuna connessione keep-alive, dopo il quale la connessione verrà chiusa (non confondere con keepalive_timeout, che definisce il tempo di inattività dopo il quale la connessione keep-alive viene chiusa).
- È stata aggiunta la variabile $connection_time, tramite la quale è possibile ottenere informazioni sulla durata della connessione in secondi con precisione millisecondi.
- Nelle direttive «proxy_cache_path», «fastcgi_cache_path», «scgi_cache_path» e «uwsgi_cache_path» è stato aggiunto il parametro «min_free», che regola la dimensione della cache in base alla determinazione della dimensione minima dello spazio libero su disco.
- Le direttive «lingering_close», «lingering_time» e «lingering_timeout» sono state adattate per funzionare con HTTP/2.
- Il codice di gestione delle connessioni in HTTP/2 è simile all'implementazione di HTTP/1.x. Il supporto per le impostazioni specifiche «http2_recv_timeout», «http2_idle_timeout» e «http2_max_requests» è stato eliminato a favore delle direttive generali «keepalive_timeout» e «keepalive_requests». Sono state rimosse le impostazioni «http2_max_field_size» e «http2_max_header_size», per le quali si dovrebbe invece utilizzare «large_client_header_buffers».
- È stata aggiunta una nuova opzione della riga di comando «-e», che consente di specificare un file alternativo per la registrazione degli errori, che verrà utilizzato al posto del log specificato nelle impostazioni. Al posto del nome del file, è possibile indicare il valore speciale stderr.
Fonte: opennet.ru
