Wydanie nginx 1.30.0 i fork FreeNginx 1.30.0

Po roku rozwoju wydano nową, stabilną gałąź wysokowydajnego serwera HTTP i wieloprotokołowego serwera proxy – nginx 1.30.0. Zawiera ona zmiany zgromadzone w głównej gałęzi 1.29.x. W przyszłości wszystkie zmiany w stabilnej gałęzi 1.30 będą koncentrować się na naprawie poważnych błędów i luk w zabezpieczeniach. Wkrótce zostanie wydana główna gałąź nginx 1.31, w której nadal będą rozwijane nowe funkcje. Dla zwykłych użytkowników, którzy nie muszą dbać o kompatybilność z modułami innych firm, zalecamy korzystanie z głównej gałęzi, która stanowi podstawę komercyjnych wydań Nginx Plus co trzy miesiące. Nginx jest napisany w języku C i dystrybuowany na licencji BSD.

Według lutowego raportu Netcraft, około 321 milionów stron internetowych korzysta z Nginx (245 milionów rok temu, 243 miliony dwa lata temu i 289 milionów trzy lata temu). Nginx jest używany przez 16.08% wszystkich aktywnych stron internetowych (17.89% rok temu, 18.15% dwa lata temu i 18.94% trzy lata temu), co plasuje go na drugim miejscu pod względem popularności w tej kategorii (udział Apache'a wynosi 13.27% (16.03% rok temu, 20.09% dwa lata temu i 20.52% trzy lata temu), Cloudflare'a 20.62% (17.81%, 14.12%, 11.32%) i Google'a 10.65% (9.89%, 10.41%, 9.89%).

Biorąc pod uwagę wszystkie strony, nginx utrzymuje pozycję lidera i zajmuje 22.65% rynku (rok temu 20.48%, dwa lata temu - 22.31%, trzy lata temu - 25.94%), podczas gdy udział Apache'a wynosi 12.19% (16.03%, 20.17%, 20.58%), Cloudflare - 15.27% (12.87%, 11.24%, 10.17%), OpenResty (platforma oparta na nginx i LuaJIT) - 8.01% (9.36%, 7.93%, 7.94%).

Wśród miliona najczęściej odwiedzanych stron internetowych na świecie, NGINX zajmuje drugie miejsce z udziałem 19.85% (20.37% rok temu, 20.63% dwa lata temu i 21.37% trzy lata temu). Cloudflare zajmuje pierwsze miejsce z udziałem 26.84% (22.32%, 22.59% i 21.62%). Udział Apache httpd wynosi 15.84% (17.95%, 20.09% i 21.18%).  Wydanie nginx 1.30.0 i fork FreeNginx 1.30.0

Według W3Techs, NGINX jest używany przez 32.8% z miliona najpopularniejszych witryn internetowych (w kwietniu ubiegłego roku odsetek ten wynosił 33.8%, a rok wcześniej 34.3%). Udział Apache'a spadł w ciągu roku z 26.3% do 23.9%, udział Microsoft IIS spadł z 4% do 3.4%, a Caddy z 0.3% do 0.2%. Udział Node.js wzrósł z 4.4% do 6.0%, a LiteSpeed ​​z 14.6% do 15.2%.

Najbardziej godne uwagi ulepszenia dodane podczas opracowywania gałęzi upstream 1.29.x:

  • Dodano obsługę rozszerzenia TLS ECH (Encrypted ClientHello), będącego rozwinięciem rozszerzenia ESNI (Encrypted Server Name Indication) używanego do szyfrowania informacji o parametrach sesji TLS, takich jak żądana nazwa domeny. Kluczowa różnica między ECH a ESNI polega na tym, że ECH szyfruje całą wiadomość ClientHello TLS, zamiast szyfrować pojedyncze pola. Pomaga to blokować wycieki przez pola nieobjęte ESNI, takie jak pole PSK (Pre-Shared Key). ECH włącza się poprzez określenie dyrektywy „ssl_ech_file” w pliku konfiguracyjnym ECHConfig w formacie PEM. Obsługa jest dostępna w przypadku korzystania z kompilacji OpenSSL z ECH.
  • Dodano obsługę protokołu Multipath TCP (MPTCP), który umożliwia jednoczesne dostarczanie pakietów wieloma trasami i różnymi interfejsami sieciowymi. Do dyrektywy „listen” dodano parametr „multipath”.
  • Dodano możliwość powiązania sesji klientów z tymi samymi serwerami w grupie. Dostępne są trzy metody: „cookie” – przesyła dane o wybranym serwerze. serwer poprzez określony plik cookie; „route” — serwer proxy przypisuje klientowi trasę po otrzymaniu pierwszego żądania; „learn” — nginx analizuje odpowiedzi z serwera nadrzędnego i zapamiętuje sesje zainicjowane przez serwer. Aby skonfigurować powiązanie, dyrektywa „sticky” została dodana do bloku „upstream” modułu „http”, a parametry „route” i „drain” do dyrektywy „server”.
  • Dodano dyrektywę „early_hints”, a także wprowadzono obsługę kodu HTTP 103 w odpowiedziach z serwerów proxy i zaplecza gRPC. Kod 103 umożliwia klientowi uzyskanie informacji o zawartości określonych nagłówków HTTP natychmiast po żądaniu, bez oczekiwania na zakończenie wszystkich operacji związanych z żądaniem i rozpoczęcie serwowania treści przez serwer. Można to wykorzystać do dostarczania wskazówek dotyczących elementów powiązanych ze zwróconą stroną, które mogą być wstępnie załadowane (na przykład linki do CSS i JavaScript używane na stronie). Po otrzymaniu informacji o takich zasobach przeglądarka rozpocznie ich pobieranie bez oczekiwania na zakończenie serwowania strony głównej, co skraca całkowity czas przetwarzania żądania.
  • Dodano dyrektywy add_header_inherit i add_trailer_inherit. Umożliwiają one zmianę reguł dziedziczenia dla wartości określonych w dyrektywach add_header i add_trailer. Parametr „off” wyłącza dziedziczenie wartości, natomiast parametr „merge” umożliwia dodawanie wartości z poprzedniego poziomu do wartości na bieżącym poziomie.
  • Dodano dyrektywę „ssl_certificate_compression” w celu kontrolowania kompresji Certyfikaty TLS.
  • Dodano dyrektywę max_headers, ograniczającą maksymalną liczbę nagłówków HTTP w żądaniu. Przekroczenie limitu powoduje zwrócenie błędu 400 (błędne żądanie). Ta funkcja została przeniesiona z FreeNginx.
  • Dodano zmienne $request_port i $is_request_port. Pierwsza zmienna zawiera numer portu z komponentu URI lub nagłówka „Host”, a druga zawiera znak „:”, jeśli zmienna $request_port nie jest pusta.
  • Dodano zmienne $ssl_sigalg i $ssl_client_sigalg, które zawierają nazwę algorytmu generowania podpisu cyfrowego dla połączenia TLS.
  • Do dyrektywy „geo” dodano parametr „volatile”, który wyłącza buforowanie zmiennych. Symbole wieloznaczne są teraz dozwolone w dyrektywie „include” określonej w bloku „geo”.
  • Dyrektywa „keepalive” jest domyślnie włączona w bloku „upstream”. Dyrektywa „keepalive” używana w bloku „upstream” została zaktualizowana i zawiera parametr „local”. Po określeniu tego parametru, zamiast współdzielenia jednego połączenia ze wspólnym serwerem upstream, do którego odwołują się różne lokalizacje i bloki serwerów, każdy blok utrzymuje oddzielne połączenie upstream.
  • W trybie proxy domyślną wersją protokołu jest HTTP/1.1 z włączonym trybem keep-alive (obsługa keep-alive jest domyślnie włączona w module ngx_http_proxy_module, w dyrektywie „proxy_http_version” ustawiona jest wartość „1.1”, a domyślne wysyłanie nagłówka „Connection” jest zatrzymane).
  • Moduł ngx_http_proxy obsługuje teraz protokół HTTP/2, co pozwala na używanie HTTP/2 podczas dostępu do zaplecza.
  • Możliwość ładowania kluczy kryptograficznych z tokenów sprzętowych została zapewniona dzięki wykorzystaniu biblioteki OpenSSL.
  • Zaktualizowano implementację protokołu QUIC, aby zapewnić obsługę trybu 0-RTT, dostępnego w systemach z OpenSSL 3.5.1 i nowszymi wersjami.
  • Dodano możliwość kompilacji przy użyciu biblioteki kryptograficznej AWS-LC opracowanej przez Amazon.
  • Kompresja certyfikatu TLSv1.3 jest domyślnie wyłączona.
  • Zapewniono zgodność z biblioteką OpenSSL 4.0.

Dodatkowo, warto odnotować wydanie FreeNginx 1.30.0, forka Nginx. Rozwój forka jest prowadzony przez Maxima Dunina, jednego z kluczowych deweloperów Nginx. FreeNginx pozycjonuje się jako projekt niekomercyjny, zapewniając rozwój bazy kodu Nginx bez ingerencji korporacji. Kod FreeNginx jest nadal dystrybuowany na licencji BSD. Zmiany w FreeNginx 1.30 obejmują: dodaną obsługę rozszerzenia TLS ECH (Encrypted Client Hello); ulepszone przetwarzanie dyrektywy limit_rate; dodane dyrektywy send_min_rate i client_body_min_rate; zaimplementowano możliwość ograniczenia liczby połączeń i szybkości żądań w serwerze proxy poczty; dodano obsługę bazy danych GeoIP2 w module GeoIP; oraz wzmocniono bezpieczeństwo modułu XSLT.

Źródło: opennet.ru

Kup niezawodny hosting dla stron z ochroną DDoS, serwery VPS VDS 🔥 Kup niezawodny hosting stron internetowych z ochroną DDoS, serwery VPS VDS | ProHoster