Реліз nginx 1.18.0

Після року розробки представлена нова стабільна гілка високопродуктивного HTTP-сервера та багатопротокольного проксі-сервера nginx 1.18.0, яка увібрала зміни, накопичені в рамках основної гілки 1.17.x. Надалі всі зміни у стабільній гілці 1.18 будуть пов'язані з усуненням серйозних помилок та вразливостей. Незабаром буде сформовано основну гілку nginx 1.19, в рамках якої буде продовжено розвиток нових можливостей. Для звичайних користувачів, які не мають завдання забезпечити сумісність зі сторонніми модулями, рекомендується Використовувати основну гілку, на основі якої один раз на три місяці формуються випуски комерційного товару Nginx Plus.

У відповідності з квітневим звітом компанії Netcraft nginx використовується на 19.56% всіх активних сайтів (рік тому 20.73%, два роки тому 21.02%), що відповідає другому місцю за популярністю в даній категорії (частка Apache відповідає 27.64%, Google - 10.03%, Microsoft IIS - 4.77%) . При цьому при розгляді всіх сайтів nginx зберігає лідерство і займає 36.91% ринку (рік тому 27.52%), тоді як частка Apache відповідає 24.73%, Microsoft IIS - 12.85%, Google - 3.42%.

Серед мільйона відвідуваних сайтів у світі частка nginx становить 25.54% (рік тому 26.22%, два роки тому 23.76%). В даний час під управлінням nginx працює близько 459 млн. сайтів (рік тому 397 млн.). за даними W3Techs nginx використовується на 31.9% сайтах з мільйона відвідуваних, у квітні минулого року цей показник становив 41.8%, позаминулого — 38% (спад пояснюється переходом до окремого обліку http-сервера Cloudflare). Частка Apache протягом року знизилася з 43.6% до 38.9%, а частка Microsoft IIS з 8.6% до 8.3%. У Росії nginx використовується на 78.9% відвідуваних сайтів (рік тому — 81%).

Найбільш помітні покращення, додані у процесі формування основної гілки 1.17.x:

  • Додано директиву limit_req_dry_run, яка активує режим пробного запуску, в якому не застосовуються обмеження на інтенсивність обробки запитів (без rate limit), але продовжується облік числа запитів, що виходить за ліміти, в розділяється пам'яті;
  • Додано директиву limit_conn_dry_run, що переводить модуль ngx_http_limit_conn_module в режим пробного запуску, при якому кількість з'єднань не обмежується, але враховується;
  • Додано директиву «затримка авторизації«, що дозволяє додати затримку неавторизованих запитів із кодом відповіді 401 для скорочення інтенсивності підбору паролів та захисту від атак, що маніпулюють виміром часу виконання операцій (timing attack) при зверненні до систем, доступ до яких обмежений паролем, результатом підзапиту або JWT (JSON Web Token);
  • Додано підтримку змінних у директивах «limit_rate» та «limit_rate_after», а також у директивах «proxy_upload_rate» та «proxy_download_rate» модуля stream;
  • У директиві grpc_pass додано підтримку використання змінної у параметрі, що визначає адресу. Якщо адреса вказана як доменне ім'я, ім'я шукається серед описаних груп серверів, і, якщо не знайдено, то визначається за допомогою resoldre'а;
  • Додані нові змінні $proxy_protocol_server_addr и $proxy_protocol_server_port, які містять адресу та порт сервера, отримані із заголовка протоколу PROXY;
  • У модулі ngx_stream_limit_conn_module додано змінну $limit_conn_statusяка зберігає результат обмеження числа з'єднань: PASSED, REJECTED або REJECTED_DRY_RUN;
  • У модулі ngx_http_limit_req_module додано змінну $limit_req_statusяка зберігає результат обмеження швидкості надходження запитів: PASSED, DELAYED, REJECTED, DELAYED_DRY_RUN або REJECTED_DRY_RUN;
  • За замовчуванням забезпечено складання модуля ngx_http_postpone_filter_module;
  • Додано підтримку перемикання іменованих блоків «location» за допомогою методу $r->internal_redirect(), що надається вбудованим інтерпретатором Perl. Даний метод тепер має на увазі обробку URI з екранованими символами;
  • При використанні в блоці налаштувань «upstream» директиви «мішанина» для організації балансування навантаження з прив'язкою клієнта до сервера, у разі вказівки порожнього значення ключа активується режим рівномірного балансування (round-robin);
  • Додана підтримка виклику ioctl(FIONREAD), якщо він доступний, щоб уникнути читання швидкого з'єднання протягом тривалого часу.

Джерело: opennet.ru

Додати коментар або відгук