Po roku rozwoju wprowadzono nową stabilną gałąź wysokowydajnego serwera HTTP i wieloprotokołowego serwera proxy nginx 1.20.0, która uwzględnia zmiany zgromadzone w głównej gałęzi 1.19.x. W przyszłości wszystkie zmiany w stabilnej gałęzi 1.20 będą związane z eliminacją poważnych błędów i podatności. Wkrótce powstanie główna gałąź nginx 1.21, w której kontynuowany będzie rozwój nowych funkcji. Dla zwykłych użytkowników, którzy nie mają za zadanie zapewnić kompatybilności z modułami firm trzecich, zaleca się skorzystanie z głównej gałęzi, na bazie której co trzy miesiące powstają wydania komercyjnego produktu Nginx Plus.
Według marcowego raportu Netcrafta, nginx jest używany na 20.15% wszystkich aktywnych stron (rok temu 19.56%, dwa lata temu 20.73%), co daje drugie miejsce pod względem popularności w tej kategorii (udział Apache'a odpowiada 25.38% (rok temu 27.64%), Google – 10.09%, Cloudflare – 8.51%. Jednocześnie biorąc pod uwagę wszystkie serwisy, nginx utrzymuje pozycję lidera i zajmuje 35.34% rynku (rok temu 36.91%, dwa lata temu – 27.52%), natomiast udział Apache wynosi 25.98%, OpenResty (platforma oparta na nginx i LuaJIT.) – 6.55%, Microsoft IIS – 5.96%.
Wśród miliona najczęściej odwiedzanych witryn na świecie udział nginx wynosi 25.55% (rok temu 25.54%, dwa lata temu 26.22%). Obecnie około 419 milionów stron internetowych korzysta z Nginx (459 milionów rok temu). Według W3Techs z nginx korzysta 33.7% stron spośród miliona najczęściej odwiedzanych, w kwietniu ubiegłego roku odsetek ten wynosił 31.9%, rok wcześniej – 41.8% (spadek tłumaczy się przejściem na odrębną księgowość Cloudflare http serwer). Udział Apache'a spadł w ciągu roku z 39.5% do 34%, a Microsoft IIS z 8.3% do 7%. Udział LiteSpeed wzrósł z 6.3% do 8.4%, a Node.js z 0.8% do 1.2%. W Rosji nginx jest używany na 79.1% najczęściej odwiedzanych stron (rok temu - 78.9%).
Najbardziej godne uwagi ulepszenia dodane podczas opracowywania gałęzi upstream 1.19.x:
- Dodano możliwość weryfikacji certyfikatów klienta przy pomocy usług zewnętrznych w oparciu o protokół OCSP (Online Certyfikat Status Protocol). Aby umożliwić kontrolę, zaproponowano dyrektywę ssl_ocsp, aby skonfigurować rozmiar pamięci podręcznej - ssl_ocsp_cache, aby przedefiniować adres URL procedury obsługi OCSP określonej w certyfikacie - ssl_ocsp_responder.
- W zestawie znajduje się moduł ngx_stream_set_module, który umożliwia przypisanie wartości do serwera zmiennych {słuchaj 12345; ustaw $true 1; }
- Dodano dyrektywę proxy_cookie_flags, aby określić flagi dla plików cookie w połączeniach proxy. Na przykład, aby dodać flagę „httponly” do pliku cookie „one” oraz flagi „nosecure” i „samesite=strict” do wszystkich innych plików cookie, możesz zastosować następującą konstrukcję: proxy_cookie_flags one httponly; proxy_cookie_flags ~ lekarstwo na nos samesite=strict;
Podobna dyrektywa userid_flags dotycząca dodawania flag do plików cookie jest również zaimplementowana dla modułu ngx_http_userid.
- Dodano dyrektywy „ssl_conf_command”, „proxy_ssl_conf_command”, „grpc_ssl_conf_command” i „uwsgi_ssl_conf_command”, za pomocą których można ustawić dowolne parametry konfiguracji OpenSSL. Na przykład, aby nadać priorytet szyfrom ChaCha i zaawansowanej konfiguracji szyfrów TLSv1.3, możesz określić opcje ssl_conf_command PrioritizeChaCha; ssl_conf_command Zestawy szyfrów TLS_CHACHA20_POLY1305_SHA256;
- Dodano dyrektywę „ssl_reject_handshake”, która instruuje odrzucanie wszelkich prób negocjowania połączeń SSL (na przykład można jej użyć do odrzucenia wszystkich połączeń z nieznanymi nazwami hostów w polu SNI). serwer {słuchaj 443 ssl; ssl_reject_handshake włączone; } serwer {słuchaj 443 ssl; nazwa_serwera przykład.com; certyfikat_ssl przykład.com.crt; ssl_certificate_key przykład.com.key; }
- Do serwera proxy poczty dodana została dyrektywa proxy_smtp_auth, umożliwiająca uwierzytelnienie użytkownika na backendzie za pomocą polecenia AUTH i mechanizmu PLAIN SASL.
- Dodano dyrektywę „keepalive_time”, która ogranicza całkowity czas życia każdego połączenia utrzymywania aktywności, po którym połączenie zostanie zamknięte (nie mylić z dyrektywą keepalive_timeout, która określa czas bezczynności, po którym połączenie utrzymywania aktywności zostanie zamknięte).
- Dodano zmienną $connection_time, dzięki której można uzyskać informację o czasie trwania połączenia w sekundach z dokładnością do milisekund.
- Do dyrektyw „proxy_cache_path”, „fastcgi_cache_path”, „scgi_cache_path” i „uwsgi_cache_path” dodano parametr „min_free”, który reguluje wielkość pamięci podręcznej w oparciu o określenie minimalnej wielkości wolnego miejsca na dysku.
- Dyrektywy „lingering_close”, „lingering_time” i „lingering_timeout” zostały przystosowane do pracy z protokołem HTTP/2.
- Kod przetwarzania połączenia w HTTP/2 jest zbliżony do implementacji HTTP/1.x. Obsługa indywidualnych ustawień „http2_recv_timeout”, „http2_idle_timeout” i „http2_max_requests” została przerwana na rzecz ogólnych dyrektyw „keepalive_timeout” i „keepalive_requests”. Ustawienia „http2_max_field_size” i „http2_max_header_size” zostały usunięte i zamiast nich należy użyć „large_client_header_buffers”.
- Dodano nową opcję wiersza poleceń „-e”, która umożliwia określenie alternatywnego pliku do zapisywania dziennika błędów, który będzie używany zamiast dziennika określonego w ustawieniach. Zamiast nazwy pliku można podać wartość specjalną stderr.
Źródło: opennet.ru