NGINX — История перерождения под Windows

Как установить и запустить сервер Nginx на Windows 10

Nginx — это веб-сервер, который очень популярен в Linux и BSD системах. Многие полагают, что установить Nginx на Windows 10 невозможно. Это совсем не так.

Согласно информации, размещенной на сайте Nginx, установка на Windows 10 возможна, но есть несколько ограничений производительности, которые пока не были устранены. К ним относятся только одно рабочее веб-приложение, отсутствие масштабируемости и возможные проблемы с UDP аутентификацией. На данный момент Nginx уже упоминал, что он решит все проблемы в своих будущих выпусках.

Чтобы успешно установить и запустить Nginx на Windows 10, выполните следующие действия.

Загрузите Nginx Server

Существует много загружаемых версий Nginx для Windows, но Nginx рекомендует использовать “mainline version”. Однако, вы не найдете никаких проблем, если загрузите последнюю стабильную версию этой программы.

Выберите последний ZIP-файл и загрузите его в новую папку.

В качестве первого шага необходимо распаковать его. Вы можете использовать 7-Zip, WinRAR или любое другое популярное программное обеспечение для архивации.

После извлечения содержимого архива из первоначальной директории необходимо переместить папку, которая поставлялась со встроенной загрузочной копией. в «Program Files».

Мы запустим Nginx из этого места в качестве веб-сервиса по умолчанию.

Установка Nginx

Чтобы установить и запустить Nginx, выберите и дважды щелкните файл Nginx.exe.

На следующем шаге вам нужно проверить, была ли установка успешной. Для этого вы можете перейти в браузер по умолчанию и ввести “localhost”. Если вы увидите следующее окно с сообщением об успешной установке и работе веб-сервера Nginx, то проблем с установкой в Windows 10 не было.

Чтобы остановить Nginx, вы можете завершить его из окна Диспетчер задач.

Запуск Nginx на компьютере с ОС Windows

Для запуска Nginx, вы должны использовать Internet Information Services (IIS), который является веб-сервером Microsoft, обслуживающим запрошенные HTML страницы или файлы. Вы можете включить его в меню Turn Windows Features On or Off в Панели управления. Проверьте необходимые поля для Web Management Tools и IIS Management Console.

Для включения IIS на вашем компьютере потребуется некоторое время.

Менеджер IIS Manager можно открыть непосредственно из меню Пуск. Здесь вы сможете получить доступ к веб-сайту по умолчанию, который обычно расположен по адресу “inetpub wwwroot”. Он также известен как корень веб-приложения.

Полезно изменить физический путь этого корня в более подходящую папку. Я создал новую папку “Work” в C: и изменил физический путь на “C:Work”.

После этого перейдите в папку Nginx, которую переименовали в файлах программы. Нажмите “Conf” и выберите “nginx.conf”. Этот файл можно редактировать с помощью текстового редактора Notepad++.

В Notepad++ измените корень на отредактированный физический путь, о котором мы говорили выше.

Вы можете отредактировать файл index.html в корневой папке на отдельной вкладке. Измените текст на то, что вы хотите, чтобы веб-сервер отображался на экране.

Теперь снова запустите программу Nginx.exe и введите “localhost” в окне браузера. Веб-сервер Nginx выделит сделанные вами изменения.

На сайте ресурсов Nginx представлен полный список веб-приложений, которые можно использовать для запуска на Windows PC.

Вывод

Nginx является одной из ведущих компаний по разработке веб-серверов, которая, как ожидается, затмит Apache в будущем. Кроме того, он быстрее, может справляться с большим количеством параллельных задач и надежен. Подводя итог, можно сказать, что если у вас есть простой сайт, который вы хотите подключить к Nginx, вы можете сделать это прямо сейчас без каких-либо проблем.

Спасибо, что читаете! Подписывайтесь на мой канал в Telegram и Яндекс.Дзен. Только там последние обновления блога и новости мира информационных технологий. Также, читайте меня в социальных сетях: Facebook, Twitter, VK, OK.

Респект за пост! Спасибо за работу!

Хотите больше постов? Узнавать новости технологий? Читать обзоры на гаджеты? Для всего этого, а также для продвижения сайта, покупки нового дизайна и оплаты хостинга, мне необходима помощь от вас, преданные и благодарные читатели. Подробнее о донатах читайте на специальной странице.

На данный момент есть возможность стать патроном, чтобы ежемесячно поддерживать блог донатом, или воспользоваться Яндекс.Деньгами, WebMoney, QIWI и PayPal:

Спасибо! Все собранные средства будут пущены на развитие сайта. Поддержка проекта является подарком владельцу сайта.

Раз уж тут у нас «неделя» nginx, например тут или тут, то попробую и я внести свою, так сказать, лепту. Речь пойдет про nginx 4 windows, а именно про более-менее официальную сборку для этой пропритарной, некоторыми не очень любимой платформы. Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься. И раз уж имеем Windows, но не хочется мучиться с IIS, apache и иже с ними, если хочется использовать любимые инструменты, а nginx однозначно к ним относится, то приходится иногда мириться даже с некоторыми ограничениями на этой платформе. Вернее приходилось… Хотя нужно заметить, что даже с этими ограничениями, nginx даст фору практически любому веб-серверу под windows по многим факторам, в том числе по стабильности, потреблению памяти, а главное производительности. Спешу сразу поделится хорошей новостью — больше ограничений, критичных к высокой производительности, при использовании nginx под windows практически не существует, и последнее из критичных, с высокой долей вероятности, тоже скоро отпадет. Но по порядку…Здесь описаны известные проблемы nginx 4 windows, а именно:

• Рабочий процесс может обслуживать не более 1024 одновременных соединений.
• Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
• Хоть и возможен запуск нескольких рабочих процессов, только один из них реально работает.

Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».

1024 одновременных соединений

На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений. Например для VS добавив директиву --with-cc-opt=-DFD_SETSIZE=10240, воркер nginx сможет управляться с 10K одновременными соединениями, если в конфигурации вы укажете worker_connections 10240;.

Кэш и другие модули, требующие поддержки разделяемой памяти

Все эти функции и модули до недавнего времени действительно не работали под Windows, начиная с версии x64 или там где по умолчанию вся система работает с включенным ASLR. Причем отключение ASLR для nginx ничего не меняет, т.к. функции для работы с shared memory зашиты глубоко в kernel, т.е. ASLR (а с ним вероятно и DEP, с ним почему-то не получалось) нужно отключать для всей системы. Это на самом деле довольно не маленький список функционала: Кэш, любые зоны, соответственно и limit_req и т.д. и т.п. Кстати без поддержки разделяемой памяти гораздо труднее было бы убрать 3-е ограничение, т.е. реализовать поддержку multiple workers под windows. Не буду утомлять читателя как я с этим боролся, но совместно с Максом (спасибо ) мы таки допилили это до релизной версии. Немного об этом, кому интересно см. под спойлером или в исходниках hg.nginx.org или github…Немного теории…Сама разделяемая память может быть использована и с рандомизацией адресного пространства. Одно другому как бы не мешает, просто при включенном ASLR вы в другом процессе практически гарантировано получите указатель на «ту же память», но под другим адресом. Это на самом деле не критично, пока содержимое этого пространства само не содержит прямых указателей, aka pointer. Т.е. указатели-смещения относительно начального адреса shmem допустимы, но не прямые указатели как они есть. Соответственно без того чтобы переписать весь функционал, работающий с pointer внутри shared mem в nginx — есть единственный вариант, обмануть заставить таки windows выдать ссылку на shmem под постоянным для всех рабочих процессов, адресом. Ну а далее все не очень сложно, на самом деле. Начало дискуссии про это можно почитать здесь. Максим, кстати починил упущенную мной проблему (remapping), иногда возникающую после перезагрузки воркеров (reload налету). Viva open source! Т.е. официально это ограничение больше не действует с Release 1.9.0 от 28 Apr 2015:

Feature: shared memory can now be used on Windows versions with  address space layout randomization. 

Только один рабочий процесс реально работает.

В nginx есть процесс мастер и дочерние процессы, называемые рабочими или worker. Под windows у nginx может быть запущено несколько рабочих процессов, т.е. указав в конфигурации «worker_processes 4;«, вы заставите мастера запустить четыре дочерних рабочих процесса. Проблема состоит в том, что только один из них, «украв» listener-соединение у мастера (используя SO_REUSEADDR) будет действительно слушать этот сокет, т.е. делать accept входящих соединений. В результате же у других воркеров — нет входящих соединений — нет работы. Это ограничение связано с технической реализацией winsock, и единственный способ получить распределенное listener-соединение для всех рабочих процессов в Windows — это клонировать сокет из мастер-процесса, т.е. использовать inherited handle от сокета из него. Кому интересны подробности реализации, могут посмотреть их под спойлером или в исходниках, пока только у меня на гитхаб.Подробнее…Начнем с того, что даже если запускать дочерние процессы (CreateProcess), используя bInheritHandle=TRUE, и установив SECURITY_ATTRIBUTES::bInheritHandle при создании сокета тоже равным TRUE, скорее всего у вас ничего не выйдет, т.е. в рабочем процессе используя этот handle, вы получите «failed (10022: An invalid argument was supplied)». А «успешно» продублировав этот сокет с помощью DuplicateHandle, дублированный handle тоже не примет ни одна функция работающая с сокетами (вероятно с ошибкой 10038 — WSAENOTSOCK). Почему так происходит приоткрывает одна цитата из MSDN — DuplicateHandle:Проблема в том, что для дублирования handle с помощью WSADuplicateSocket, необходимо заранее знать pid процесса, т.е. это нельзя сделать до того как процесс был бы запущен. В результате, чтобы сообщить дочернему процессу информацию полученную мастером от WSADuplicateSocket, необходимую для создания сокета-клона в рабочем процессе — имеем два варианта, либо использовать что-нибудь вида IPC, например как это описано в MSDN — WSADuplicateSocket, либо передать это через shared memory (благо мы уже это выше починили). Я решил использовать второй вариант, т.к. считаю, что это наименее трудоемкий из двух и наиболее быстрый способ реализации наследования соединения. Ниже изменения в алгоритме запуска рабочих процессов под windows (помечены *):

• Мастер-процесс создает все listener-сокеты;
• [cycle] Мастер-процесс создает рабочий процесс;
• * [win32] мастер вызывает новую функцию ngx_share_listening_sockets: для каждого listener-сокет опрашивается информация (для наследования) конкретно для этого нового воркера, («клонированная» через WSADuplicateSocket для pid), которая будет сохранена в shared memory — shinfo (protocol structure);
• Мастер-процесс ждет пока worker установит событие о готовности — event «worker_nnn»;
• * [win32] Рабочий процесс выполняет новую функцию ngx_get_listening_share_info для получения информации наследования shinfo, которая будет использоваться для создания нового дескриптора сокета для shared listener-сокета мастер-процесса;
• * [win32] Рабочий процесс создает все listener-сокеты, используя информацию shinfo от мастер-процесса;
• Рабочий процесс устанавливает событие — event «worker_nnn»;
• Мастер-процесс прекращает ожидание, и создает следующий рабочий процесс, повторяя [cycle].

Если нужно, здесь ссылка на дискуссию о фиксе, дабы она будет. В результате, nginx под windows запускает теперь N «полноценных», с точки зрения «прослушивания», а главное установления соединения, рабочих процессов, которые обрабатывают входящие соединения действительно параллельно. Этот фикс правда еще лежит «пул-реквестом» (я отправил changeset в nginx-dev), но его уже можно попробовать например скачав с моего github и самостоятельно собрав под windows. Если будут желающие выложу куда-нибудь бинарник. Я довольно долго истязал свое железо, гоняя это тестами и под нагрузочными «скриптами» — результат, все воркеры нагружены более-менее равномерно и действительно работают параллельно. Также я пробовал на лету (reload-ом) перезагружать nginx и случайным образом «убивал» некоторых воркеров имитируя «crash» последних — все работает без малейшего нарекания. Пока проявился единственный «недостаток», имхо — если запустить

netstat /abo | grep LISTEN 

то вы увидите только мастер-процесс в списке «слушателей», хотя в реальности как раз он никогда не устанавливает соединение, только его дочерние рабочие процессы. Кстати, мой опыт пока говорит, что accept_mutex для windows-платформы вероятно нужно отключать «accept_mutex off;«, т.к. по крайней мере на моих тестовых системах, с включенным accept_mutex они работали ощутимо медленнее, чем с выключенным. Но это думаю каждый должен проверять экспериментально (т.к. зависит от кучи параметров, типа количество ядер, воркеров, keep-alive соединений и т.д. и т.п.). Ну и как без красивых табличек с числами сравнения производительности, до (первый столбец помечен **NF) и после. Тест сделан на Windows7 — i5-2400 cpu @ 3.10GHz (4 core). Request: статика, 452 байта (+ header) — маленькие gif-иконки.

И да пребудет с вами nginx и под windows.Используемые источники:

• https://levashove.ru/install-nginx-server-windows/
• https://habr.com/post/260133/