Вышел релиз nginx 1.20.0


    С момента выхода прошлой версии nginx прошел целый год. Сейчас представлена новая стабильная ветка nginx 1.20.0. По словам разработчиков, в нее вошли все изменения, которые ранее были накоплены в ветке 1.19.x. В новой ветке изменения будут связаны с ликвидацией серьезных ошибок и уязвимостей.

    В ближайшее время разработчики сформируют основную ветку 1.21, которая будет получать новые возможности. Тем пользователям, кому не нужна совместимость со сторонними модулями, рекомендуется использовать основную ветку. На ее основе раз в квартал формируются выпуски коммерческого продукта Nginx Plus.

    Немного статистики


    Согласно данным компании Netcraft, nginx используется на 20,15% всех активных сайтов. Год назад этот показатель составлял 19,56%, два года назад — 20,73%. Nginx находится на втором месте после Apache, доля которого составляет 25,38% (год назад — 27,64%). На третьем месте находится Google с 10,09%, а на четвертом — Cloudflare (8,51%).

    Если учитывать все сайты, то nginx является лидером с 35,34% рынка. У Apache — 25,98%, у OpenResty (платформа на базе nginx и LuaJIT.) — 6.55%, Microsoft IIS — 5.96%.

    Если же оценивать использование nginx самыми посещаемыми сайтами в мире, то доля nginx составляет 25,55% (год назад — 25,54%, два года назад — 26,22%). Количество сайтов, которые работают под управлением nginx, составляет 419 млн. В России nginx используется на 79,1% самых посещаемых сайтов (год назад — 78,9%).

    Ну а теперь — об изменениях


    Новый релиз получил сразу несколько заметных улучшений:

    • Возможность проверки клиентских сертификатов с привлечением внешних служб на базе протокола OCSP (Online Certificate Status Protocol). Для включения проверки предложена директива “ssl_ocsp”, для настройки размера кэша — “ssl_ocsp_cache”, для переопределения URL OCSP-обработчика, указанного в сертификате, — “ssl_ocsp_responder”.
    • В состав новой версии вошел модуль “ngx_stream_set_module”, позволяющий присвоить значение переменной:

        server {
            listen 12345;
            set    $true 1;
        }


    • Разработчики добавили директиву “proxy_cookie_flags” для указания флагов для Cookie в проксируемых соединениях.
    • Добавлены и директивы «ssl_conf_command», «proxy_ssl_conf_command», «grpc_ssl_conf_command» и «uwsgi_ssl_conf_command», при помощи которых можно задать произвольные параметры для настройки OpenSSL. Так, при необходимости приоритизировать шифры ChaCha и выполнить расширенную настройку шифров TLSv1.3 можно указать:

       ssl_conf_command Options PrioritizeChaCha;
       ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

    • Еще одно важное обновление — добавление директивы «ssl_reject_handshake», которая предписывает отвергать все попытки согласования SSL-соединений (например, можно использовать для отклонения всех обращений с неизвестными именами хостов в поле 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;
        }

    • В почтовый прокси вошла директива “proxy_smtp_auth”, которая дает возможность аутентифицировать пользователя на бэкенде при помощи команды AUTH и механизма PLAIN SASL.
    • Добавлена директива «keepalive_time». Ее задача — ограничение общего времени жизни каждого keep-alive соединения, по истечении которого соединение будет закрыто (не путать с директивой “keepalive_timeout”, определяющей время неактивности, после которого keep-alive соединение закрывается).
    • Появилась переменная $connection_time, через которую можно получить информацию о продолжительности соединения в секундах с миллисекундной точностью.
    • В уже имеющиеся директивы «proxy_cache_path», «fastcgi_cache_path», «scgi_cache_path» и «uwsgi_cache_path» добавлен параметр «min_free», регулирующий размер кэша на основе определения минимального размера свободного дискового пространства.
    • Директивы «lingering_close», «lingering_time» и «lingering_timeout» адаптированы для работы с HTTP/2.
    • Разработчики также приблизили код обработки соединений в HTTP/2 к реализации HTTP/1.x. Поддержка отдельных настроек «http2_recv_timeout», «http2_idle_timeout» и «http2_max_requests» прекращена в пользу общих директив «keepalive_timeout» и «keepalive_requests». Удалены настройки «http2_max_field_size» и «http2_max_header_size», вместо них нужно использовать «large_client_header_buffers».
    • Появилась новая опция командной строки "-e". Она дает возможность указать альтернативный файл для записи лога ошибок, который будет использоваться вместо лога, заданного в настройках. Вместо имени файла можно указать специальное значение stderr.

    Selectel
    IT-инфраструктура для бизнеса

    Комментарии 12

      +1
      http/2 это, конечно, хорошо, но в целом релиз не особо примечательный, как ни жаль.
      io_uring, похоже, ещё долго ждать придется ((
        0

        В совершенно несвязной области (блочное IO), переключение на io_uring дало прирост порядка 15% на baremetal, так что я бы не стал возлагать на io_uring слишком много надежд. Быстрее, да, но не радикально.

          0
          Ну ничоси, 15% это очень даже ощутимо. Представь, что тебе могли бы платить на 15% больше, но не платят пока у менеджмента не дошли руки оптимизировать твои документы. И ты получаешь меньше, но не радикально.
            +1

            Это не "платят на 15% больше", это "накладывают в офисной столовой на 15% больше". Речь про синтетику, и про очень специфичную синтетику с высоким уровнем kernel-userspace interaction. В реальной нагрузке этого почти не заметно.


            (Если что, речь идёт про сравнение libaio и io_uring на random read/write).

        0
        Спасибо за OCSP
          0
          ssl_reject_handshake on;
          Мне показалось, или «listen default_server; return 444;» можно закопать?
            0
            После того, как пофиксили работу TLS 1.3 — вроде да, можно закопать.
            0

            Скажите, а какие альтернативы есть тому кому перфоманс не так важен и нужно попроще?

              0
              Пока лучше не придумали. Можно, конечно, использовать Apache, но это не проще, а сравнимо.
              Как вариант, есть готовые сборки с nginx.
              Если сайт на Битриксе — есть Bitrix Env.
              Если готовы попробовать неизведанное — я для себя пилил (не судите строго!) генератор контейнеризованного окружения на Ansible, можете воспользоваться — github.com/digitalvintage/compose-gen.role
                +1
                не уверен, что проще, но есть ещё lighttpd. тоже шустрый.
                  0
                  haproxy и traefik?
                  0
                  Простите за тупой вопрос, но как правильно понять:
                  «Nginx находится на втором месте после Apache, доля которого составляет 25,38% (год назад — 27,64%). На третьем месте находится Google с 10,09%, а на четвертом — Cloudflare (8,51%).»

                  Первые два — веб сервера, и на третьем месте я больше ожидал увидеть какие-нить tomcat/jetty или IIS, а не Google и CLoudflare?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое