The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз HTTP-сервера nginx 1.12.0

12.04.2017 19:18

После года разработки представлена новая стабильная ветка высокопроизводительного HTTP-сервера nginx 1.12.0, которая вобрала в себя изменения, накопленные в рамках основной ветки 1.11.x. В дальнейшем все изменения в стабильной ветке 1.12 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.13, в рамках которой будет продолжено развитие новых возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus.

По данным W3Techs 33.3% из миллиона самых посещаемых сайтов в мире используют nginx, в апреле прошлого года этот показатель составлял 29.8%, позапрошлого - 23.8%. Доля Apache впервые опустилась ниже 50%, а доля Microsoft IIS составила 11.3%. Если рассматривать только 10 тысяч наиболее крупных сайтов, то доля nginx составляет 39.7%, а Apache - 42.8%. В России nginx используется на 76.9% самых посещаемых сайтов (год назад - 75.2%).

В соответствии с мартовским отчетом компании Netcraft nginx используется на 19.55% (год назад 16.81%, два года назад 14.24%) всех активных сайтов, что соответствует третьему месту по популярности в данной категории (доля Apache соответствует 41.06%, а Microsoft IIS - 24.46% (доля IIS выросла за счёт парковки неиспользуемых доменов)). Доля nginx среди всех сайтов составляет 19.91% (год назад 13.23%, два года назад 14.87%), среди миллиона самых посещаемых сайтов в мире - 25.64% (год назад 25.64%, два года назад 21.43%). В настоящее время под управлением nginx работает около 350 млн сайтов (год назад 143 млн).

Из улучшений, добавленных в процессе формирования основной ветки 1.11.x, можно отметить:

  • Обеспечена возможность указания нескольких SSL-сертификатов разных типов. Для загрузки сертификатов разных типов (RSA, ECDSA) директивы "ssl_certificate" и "ssl_certificate_key" можно указывать несколько раз;
  • Добавлена возможность ограничения максимального числа соединений к upstream-серверам. Для задания лимита для директивы server в блоке upstream представлен параметр max_conns;
  • С движка nginScript (ngx_http_js_module), предоставляющего средства для выполнения скриптов, написанных на языке JavaScript, снят флаг экспериментальной разработки. nginScript теперь позиционируется как штатная возможность для обработки запросов на стороне сервера;
  • Добавлена новая директива absolute_redirect, которая отвечает за абсолютное или относительное перенаправление в nginx;
  • Добавлена директива "worker_shutdown_timeout", позволяющая задать время ожидания корректного завершения работы рабочих процессов. Если за указанное время рабочие процессы не успеют довести до конца обработку имеющихся запросов, то связанные с ними соединения будут закрыты принудительно;
  • В скрипт configure добавлен сборочный параметр "--with-compat", предоставляющий средства для компиляции и динамической загрузки любых модулей в работающий экземпляр nginx, той же версии, без пересборки самого nginx;
  • Новые модули:
    • ngx_stream_map_module, позволяющий создавать переменные, значения которых зависят от значений других переменных;
    • ngx_stream_return_module, который даёт возможность отправить заданное значение клиенту и после этого закрыть соединение;
    • ngx_stream_geo_module, позволяющий создавать переменные, значения которых зависят от IP-адреса клиента;
    • ngx_stream_geoip_module, позволяющий создавать переменные, значения которых зависят от IP-адреса клиента, используя готовые базы MaxMind для привязки диапазонов адресов к регионам;
    • ngx_stream_split_clients_module, позволяющий создавать переменные для A/B тестирования (также известного как "split-тестирование");
    • ngx_stream_log_module, позволяющий записывать логи сессий в указанном формате;
    • ngx_stream_realip_module, позволяющий менять адрес и порт клиента на переданные в заголовке протокола PROXY;
    • ngx_stream_ssl_preread_module, позволяющий извлекать информацию из сообщения ClientHello без терминирования SSL/TLS, например можно получить имя сервера, запрошенное через SNI;
  • Новые переменные:
    • $request_id, в которой содержится уникальный идентификатор запроса;
    • $proxy_protocol_port, содержащая номер клиентского сетевого порта, указанного в заголовке протокола PROXY;
    • $upstream_bytes_received, позволяющая получить число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr;
    • Формат переменных '$ssl_client_s_dn' и '$ssl_client_i_dn' приведён в соответствие с RFC 2253 (RFC 4514). Значения в старом формате доступны через переменные '$ssl_client_s_dn_legacy' и '$ssl_client_i_dn_legacy';
  • Изменения в директивах:
    • В директивы "proxy_bind", "fastcgi_bind", "memcached_bind", "scgi_bind" и "uwsgi_bind" добавлен новый параметр "transparent", который позволяет указать нелокальный IP-адрес для использования в исходящих соединениях (IP Transparency, т.е. можно использовать IP клиента в исходящих соединениях). Например, можно указать реальный IP клиента - "proxy_bind $remote_addr transparent" и перенаправить запрос к прокси от адреса данного клиента. Для работы рабочие процессы nginx должны выполняться с правами root, а в системе нужно специальным образом настроить маршрутизацию для прозрачного проброса. Также поддерживается режим Direct Server Return (DSR), при котором обработчик, принявший запрос от имени клиента, возвращает ответ напрямую клиенту, минуя перенаправивший запрос nginx;
    • В директиве "map" обеспечена возможность формирования результирующего значения, комбинируя несколько переменных. В map также добавлен новый параметр 'volatile', который создает некэшируемые переменные (по умолчанию директива map создает кэшируемые переменные);
    • В директиву log_format добавлен новый параметр 'escape', который позволяет настроить экранирование символов json;
    • Добавлены новые директивы 'proxy_cache_background_update', 'fastcgi_cache_background_update', 'scgi_cache_background_update' и 'uwsgi_cache_background_update', которые позволяют в фоновом режиме обновлять кэш. Фоновое обновление кэша позволяет продолжить отдавать клиентам из кэша просроченный, но ещё не вычищенный в процессе обновления, контент;
    • В директивы "proxy_cache_path", "fastcgi_cache_path", "scgi_cache_path" и "uwsgi_cache_path" добавлены параметры manager_files, manager_threshold и manager_sleep, которые управляют поведением процесса cache manager, осуществляющего чистку кэша;
    • В директиву server_tokens, добавлен новый параметр build, отвечающий за отображение версии сборки nginx;
    • В директивах proxy_bind, fastcgi_bind, memcached_bind, scgi_bind и uwsgi_bind теперь можно указывать номер сетевого порта.
    • По умолчанию выключена директива accept_mutex, определяющая метод уведомления рабочих процессов о поступлении новых соединений ("on" - по очереди, "off" - все разом);
    • В директиве 'proxy_method' добавлена поддержка переменных;
    • Добавлены директивы 'proxy_cache_max_range_offset', 'fastcgi_cache_max_range_offset', 'scgi_cache_max_range_offset' и 'uwsgi_cache_max_range_offset';
    • В директиве ssl_session_ticket_key добавлена поддержка шифрования TLS session tickets с помощью AES256 при использовании с 80-байтными ключами;
    • В директивы proxy_next_upstream, fastcgi_next_upstream, scgi_next_upstream и uwsgi_next_upstream добавлен новый параметр http_429, определяющий HTTP-код ответа 429 при котором запрос будет передан следующему серверу;
  • Изменения в модулях:
    • В модуле ngx_http_image_filter_module добавлена поддержка формата WebP;
    • В модуле stream добавлена возможность использования переменных и добавлена проверка клиентских SSL-сертификатов. Если сервер, описанный в блоке upstream, был признан неработающим, то после истечения fail_timeout он признавался работающим только после завершения тестового соединения, теперь достаточно чтобы соединение было успешно установлено;
    • В модуле ngx_http_v2_module появилась директива "http2_max_requests", определяющая максимальное число запросов, которые можно сделать по одному соединению при использовании протокола HTTP/2;
    • В модуле ngx_http_realip_module добавлена переменная $realip_remote_port, содержащая номер сетевого порта клиента, с которого было инициировано соединение;
    • В модулях stream и ngx_stream_upstream_module добавлены новые переменные:
      • $bytes_received - число байт, полученных от клиента;
      • $session_time - длительность сессии в секундах с точностью до миллисекунд;
      • $protocol - протокол, используемый для работы с клиентом: TCP или UDP;
      • $status - статус сессии;
      • $upstream_addr - хранит IP-адрес и порт или путь к UNIX-сокету сервера группы. Если при проксировании были сделаны обращения к нескольким серверам, то их адреса разделяются запятой, например "192.168.1.1:12345, 192.168.1.2:12345, unix:/tmp/sock";
      • $upstream_bytes_sent - число байт, переданных на сервер группы. Значения нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
      • $upstream_bytes_received - число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
      • $upstream_connect_time - время установки соединения с сервером группы, время хранится в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
      • $upstream_first_byte_time - время получения первого байта данных, время хранится в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr;
      • $upstream_session_time - длительность сессии в секундах с точностью до миллисекунд. Времена нескольких соединений разделяются запятыми подобно адресам в переменной $upstream_addr.
    • В модуле ngx_http_ssl_module добавлены новые переменные '$ssl_ciphers', '$ssl_curves',' $ssl_client_v_start', '$ssl_client_v_end' и '$ssl_client_v_remain':
      • $ssl_ciphers - возвращает список шифров, поддерживаемых клиентом. Известные шифры указаны по имени, неизвестные указаны в шестнадцатеричном виде, например: AES128-SHA:AES256-SHA:0x00ff;
      • $ssl_curves - возвращает список кривых, поддерживаемых клиентом. Известные кривые указаны по имени, неизвестные указаны в шестнадцатеричном виде, например: 0x001d:prime256v1:secp521r1:secp384r1;
      • $ssl_client_v_start - возвращает дату начала срока действия клиентского сертификата;
      • $ssl_client_v_end - возвращает дату окончания срока действия клиентского сертификата;
      • $ssl_client_v_remain - возвращает число дней, оставшихся до истечения срока действия клиентского сертификата.
  • Разное:
    • При использовании OpenSSL 1.0.2 и новее через директиву "ssl_ecdh_curve" теперь можно указать список эллиптических кривых;
    • Для использования шифров DHE отныне необходимо указать параметры DHE при помощи директивы "ssl_dhparam";
    • Добавлена проверка поддержки ядром событий EPOLLRDHUP, и при использовании механизма "epoll" включения соответствующих оптимизаций обработки соединений;
    • Клиенты HTTP/2 теперь могут сразу отправлять тело запроса, не дожидаясь готовности сервера принять данные. Размер используемого при этом буфера можно установить через директиву "http2_body_preread_size".
    • Упразднены параметры сборки "--with-md5" и "--with-sha1". Внутренние реализации MD5 и SHA1 теперь используются всегда;
    • Изменен формат заголовка кэша, ранее хранившиеся в кэше ответы после обновления будут загружены заново;
    • В заголовке ответа бэкенда, в строке "Cache-Control" добавлена поддержка расширений stale-while-revalidate и stale-if-error;
    • При поддержке в системе опции сокета IP_BIND_ADDRESS_NO_PORT, она теперь применяется по умолчанию;
    • На Linux-системах при вызове epoll задействован флаг EPOLLEXCLUSIVE;
    • Временные файлы в каталоге кэша теперь располагаются не в отдельном подкаталоге, а в том же подкаталоге, что и остальные файлы;
    • Добавлена поддержка кэширования ответов c заголовком Vary, длиной до 128 символов (вместо 42 символов в предыдущих версиях);
    • В почтовом прокси-сервере добавлена поддержка метода аутентификации EXTERNAL.


  1. Главная ссылка к новости (http://mailman.nginx.org/piper...)
  2. OpenNews: Root-уязвимость из-за некорректных настроек в пакете nginx для Debian и Ubuntu
  3. OpenNews: Выпуск http-сервера nginx 1.11.0
  4. OpenNews: Увидел свет HTTP-сервер nginx 1.10.0
  5. OpenNews: В HTTP-сервер nginx встроена поддержка JavaScript
  6. OpenNews: Релиз http-сервера nginx 1.8.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46367-nginx
Ключевые слова: nginx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним84701 (ok), 19:45, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Фух, наконец-то новость о nginx.
    А то аж целую неделю ничего не было слышно, я уже волноваться начал!  *rolleyes*
    1 [05.04.2017] Выпуск nginx 1.11.13
    2 [25.03.2017] Выпуск nginx 1.11.12
    3 [22.03.2017] Выпуск nginx 1.11.11
    4 [15.02.2017] Выпуск nginx 1.11.10
    5 [01.02.2017] Обновление nginx 1.10.3
    6 [24.01.2017] Выпуск nginx 1.11.9
    7 [28.12.2016] Выпуск nginx 1.11.8
    8 [14.12.2016] Выпуск nginx 1.11.7
     
     
  • 2.6, Аноним Анонимович Анонимов (?), 20:11, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну что же вы за люди-то? У них двухнедельный цикл по выпуску mainline-версии. Каждый считает своим долгом их упрекнуть в этом оставив тут свой комментарий?!
     

  • 1.3, th3m3 (ok), 19:53, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ничего себе изменений в этот раз.
     
  • 1.4, Аноним (-), 20:09, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Временные файлы в каталоге кэша теперь располагаются не в отдельном подкаталоге, а в том же подкаталоге, что и остальные файлы;

    Сомнительная доработка. Я бы точно такое не стал бы делать.

     
     
  • 2.7, Аноним (-), 20:31, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Напишешь свой сервер и не будешь так делать.
     
  • 2.8, angra (ok), 20:36, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А аргументировать сможешь или просто "патамушо"?
     
  • 2.9, omg (?), 20:49, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Во-первых, это опция. Во-вторых, она бывает полезна, когда временные файлы расположены на отдельной от остального кэша файловой системе. Почему - предстоит выяснить вам. Но только после того, как сделаете уроки!  Я проверю!
     
     
  • 3.12, Аноним (-), 22:28, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если вчитаться в текст "Временные файлы в каталоге кэша теперь располагаются не в отдельном подкаталоге, а в том же подкаталоге, что и остальные файлы", то не ясно остюда что это опция. Поэтому ваше "во-первых" - пшик.
    И во-вторых, ваше "во-вторых" снова пшик, т.к. именно когда нужно (а оно бывает нужно) например кэш вынести в отдельную ФС или носитель, то как раз нужно располагать отдельно от временных.
    Ну и в третьих, вам бы ума или фантазии, а то читать чушь про уроки несколько поднадоело.

    ps: только не распускайте свои сопли и не устраивайте здесь флуд

     
     
  • 4.31, Аноняша (?), 16:18, 15/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Дело в том, что nginx перед тем, как переместить файл в директорию с кэшом, вначале пишет во временный файл в директории для временных файлов. Объяснять, почему хорошо бы иметь обе директории на одной фс надеюсь не надо?
     
  • 2.10, Аноним (-), 20:50, 12/04/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Увеличение коллизии, праздник какой то!!!!
     

  • 1.5, jOKer (ok), 20:10, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Добавлена возможность ограничения максимального числа соединений для директивы server в блоке upstream, через указание параметра max_conns;

    Красавцы!!!!

     
  • 1.11, Аноним (-), 22:21, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уже поставил. Старый конфиг подошел
     
  • 1.13, lone_wolf (ok), 22:33, 12/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я так понимаю рекомендуется использовать основную ветку так как им нужны тестеры на баги?
     
  • 1.16, Snaut (ok), 09:04, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    как эту статистику считают. у нас на входе стоит балансер F5, который распределяет нагрузку и кеширование на несколько nginx. nginx никогда бы с таким количеством SSL соединений не справился бы
     
     
  • 2.17, Anoim (?), 09:10, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, так и считают )
    Результаты статистика никогда нельзя признавать достоверными на 100%
     
  • 2.18, XoRe (ok), 11:30, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > nginx никогда бы с таким количеством SSL соединений не справился бы

    С каким количеством, если не секрет?

     
     
  • 3.20, Snaut (ok), 12:33, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> nginx никогда бы с таким количеством SSL соединений не справился бы
    > С каким количеством, если не секрет?

    для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL Offload

     
     
  • 4.21, eRIC (ok), 14:43, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
    > Offload

    ведь это не проблема nginx, а все упирается в нижележащих мощностей на чем оно работает (ресурсы железа). SSL Offload иногда зачастую передают на плечи HAProxy для большой производительности.


     
     
  • 5.26, Snaut (ok), 08:38, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
    >> Offload
    > ведь это не проблема nginx, а все упирается в нижележащих мощностей на
    > чем оно работает (ресурсы железа). SSL Offload иногда зачастую передают на
    > плечи HAProxy для большой производительности.

    Так я к тому и веду, что статистика - чуть менее, чем полностью не правильная. nginx в первую очередь обеспечивает проход трафика, может быть его частичную модификацию. Все остальное на себя берут все остальные системы.

     
  • 4.24, Аноним (-), 19:42, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Даже на дохлом ноутбуке справится. Не распространяйте ЛПП, пожалуйста.

    Протестил. На моем core i7 4700hq 1700 хендшейков в секунду.

     
     
  • 5.27, Snaut (ok), 09:32, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Даже на дохлом ноутбуке справится. Не распространяйте ЛПП, пожалуйста.
    > Протестил. На моем core i7 4700hq 1700 хендшейков в секунду.

    так надо не только установить соединение, но еще и обслужить желательно ;)

     
     
  • 6.28, Аноним (-), 13:01, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это не зависит от конкретного веб-сервера и выносится за скобки. Факты говорят о том, что производительность nginx значительно выше, чем вы утверждаете. На типичном сервере с 16 физ. ядрами при обработке 1000 хендшейков в секунду примерно 80% процессорного времени будет свободно для других задач.

    P.S. Естественно, тест проводился с полноценной обработкой запроса, а не с голыми хендшейками.

     
  • 6.29, Serg (??), 17:49, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да, что-то наговариваете на nginx по поводу того, что он не сможет обслуживать указанное количество
     
  • 4.30, XoRe (ok), 21:06, 14/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > для начала хотя бы с 1000 новыми SSL соединениями в секунду. SSL
    > Offload

    Дернул ab на одном из балансирующих серверов. Где-то 1160 per server. Хотя признаю, ожидал большего.
    Проблема у жизни с внешним балансером в том, что привыкаешь к тем теплым ламповым условиям, которые он дает. А когда его опускаешь и пускаешь трафик прямо в nginx, случается "ой, втупляет, надо тюнить".

     
  • 2.25, Аноним (-), 20:56, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрите доклад Дмитрия Смирнова когда он еще работал в TNS, там он рассказывает как они считают статистику, довольно занятное чтиво да и человек он приятный когда трезвый.
     
  • 2.32, Anonim (??), 16:11, 18/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Прекрасно справляется и с 10К. Зависит только от железа. С openssl 1.0.2 очень хорошо перформит.
     

  • 1.19, XoRe (ok), 11:32, 13/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Комрады, имейте в виду, что в 1.11.10 изменен формат заголовка кэша, ранее хранившиеся в кэше ответы теперь будут загружены заново;
    Отсюда: https://www.opennet.dev/opennews/art.shtml?num=46048

    Я так понимаю, это приехало и в 1.12.
    После обновления до 1.12 ваш proxy_cache может внезапно инвалидироваться весь.

     
     
  • 2.22, KonstantinB (ok), 15:26, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Приехало. Не может, а совершенно точно инвалидируется.
     
     
  • 3.23, KonstantinB (ok), 15:29, 13/04/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, придется сначала запустить 1.12 рядом, настроить ему кэш в другую директорию и "прогреть" его.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру