Nginx что за программа

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, почтовый прокси-сервер, а также TCP/UDP прокси-сервер общего назначения, изначально написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 21.30% самых нагруженных сайтов в апреле 2023 года. Вот некоторые примеры успешного внедрения nginx (тексты на английском языке): Dropbox, Netflix, WordPress.com, FastMail.FM.

Исходные тексты и документация распространяются под BSD-подобной лицензией из 2 пунктов.

Коммерческая поддержка осуществляется компанией Nginx, Inc.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI/uwsgi/SCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI;
• Поддержка HTTP/2 с приоритизацией на основе весов и зависимостей.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов, запись в syslog;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Геолокация по IP-адресу;
• A/B-тестирование;
• Зеркалирование запросов;
• Встроенный Perl;
• сценарный язык njs.

Функциональность почтового прокси-сервера

• Перенаправление пользователя на IMAP- или POP3-сервер с использованием внешнего HTTP-сервера аутентификации;
• Проверка пользователя с помощью внешнего HTTP-сервера аутентификации и перенаправление соединения на внутренний SMTP-сервер;
• Методы аутентификации:

• POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
• IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
• SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;

Функциональность TCP/UDP прокси-сервера

• Проксирование TCP и UDP;
• Поддержка SSL и расширения TLS SNI для TCP;
• Распределение нагрузки и отказоустойчивость;
• Ограничение доступа в зависимости от адреса клиента;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение числа одновременных соединений с одного адреса;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов, запись в syslog;
• Геолокация по IP-адресу;
• A/B-тестирование;
• сценарный язык njs.

Архитектура и масштабируемость

• Один главный и несколько рабочих процессов, рабочие процессы работают под непривилегированным пользователем;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Поддержка kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), /dev/poll event ports select и poll;
• Использование возможностей, предоставляемых kqueue, таких как EV_CLEAR, EV_DISABLE (для временного выключения события), NOTE_LOWAT, EV_EOF, число доступных данных, коды ошибок;
• Использование возможностей, предоставляемых epoll, таких как EPOLLRDHUP (Linux 2.6.17+, glibc 2.8+) и EPOLLEXCLUSIVE (Linux 4.5+, glibc 2.24+);
• Поддержка sendfile (FreeBSD 3.1+, Linux 2.2+, macOS 10.5+), sendfile64 (Linux 2.4.21+) и sendfilev
• Поддержка файлового AIO (FreeBSD 4.3+, Linux 2.6.22+);
• Поддержка DIRECTIO (FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, macOS);
• Поддержка accept-фильтров (FreeBSD 4.1+, NetBSD 5.0+) и TCP_DEFER_ACCEPT (Linux 2.4+);
• На неактивных HTTP keep-alive соединений расходуется около 2.5M памяти;
• Минимум операций копирования данных.

Протестированные ОС и платформы

• FreeBSD 3 — 12 / i386; FreeBSD 5 — 12 / amd64; FreeBSD 11 / ppc; FreeBSD 12 / ppc64;
• Linux 2.2 — 4 / i386; Linux 2.6 — 5 / amd64; Linux 3 — 4 / armv6l, armv7l, aarch64, ppc64le; Linux 4 — 5 / s390x;
• Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; Solaris 11 / x86;
• AIX 7.1 / powerpc;
• HP-UX 11.31 / ia64;
• macOS / ppc, i386, x86_64;
• Windows XP, Windows Server 2003, Windows 7, Windows 10.

Источник: nginx.org

NGINX Explained in 100 Seconds

Для чего нужен NGINX.

NGINX изнутри: рожден для производительности и масштабирования

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

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

Подготавливаем сцену: модель NGINX процессов

Чтобы лучше представлять устройство, сперва необходимо понять как NGINX запускается. У NGINX есть один мастер-процесс (который от имени суперпользователя выполняет такие операции, как чтение конфигурации и открытие портов), а также некоторое количество рабочих и вспомогательных процессов.

# service nginx restart * Restarting nginx # ps -ef —forest | grep nginx root 32475 1 0 13:36 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf nginx 32476 32475 0 13:36 ? 00:00:00 _ nginx: worker process nginx 32477 32475 0 13:36 ? 00:00:00 _ nginx: worker process nginx 32479 32475 0 13:36 ? 00:00:00 _ nginx: worker process nginx 32480 32475 0 13:36 ? 00:00:00 _ nginx: worker process nginx 32481 32475 0 13:36 ? 00:00:00 _ nginx: cache manager process nginx 32482 32475 0 13:36 ? 00:00:00 _ nginx: cache loader process

На 4-х ядерном сервере мастер-процесс NGINX создает 4 рабочих процесса и пару вспомогательных кэш-процессов, которые управляют содержимым кэша на жестком диске.

Почему архитектура всё же важна?

Одна из фундаментальных основ любого Unix-приложения — это процесс или поток (с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в разделении адресного пространства). Процесс или поток — это самодостаточный набор инструкций, который операционная система может запланировать для выполнения на ядре процессора. Большинство сложных приложений параллельно запускают множество процессов или потоков по двум причинам:

• Чтобы одновременно задействовать больше вычислительных ядер;
• Процессы и потоки позволяют проще выполнять параллельные операции (например обрабатывать множество соединений одновременно).

Наиболее типичный подход к построению сетевого приложения — это выделять для каждого соединения отдельный процесс или поток. Такая архитектура проста для понимания и легка в реализации, но при этом плохо масштабируется когда приложению приходится работать с тысячами соединений одновременно.

Как же работает NGINX?

NGINX использует модель с фиксированным числом процессов, которая наиболее эффективно задействует доступные ресурсы системы:

• Единственный мастер-процесс выполняет операции, которые требуют повышенных прав, такие, как чтение конфигурации и открытие портов, а затем порождает небольшое число дочерних процессов (следующие три типа).
• Загрузчик кэша запускается на старте чтобы загрузить данные кэша, расположенные на диске, в оперативную память, а затем завершается. Его работа спланирована так, чтобы не потреблять много ресурсов.
• Кэш-менеджер просыпается периодически и удаляет объекты кэша с жесткого диска, чтобы поддерживать его объем в рамках заданного ограничения.
• Рабочие процессы выполняют всю работу. Они обрабатывают сетевые соединения, читают данные с диска и пишут на диск, общаются с бэкенд-серверами.

worker_processes auto;

Когда NGINX находится под нагрузкой, то в основном заняты рабочие процессы. Каждый из них обрабатывает множество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.

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

Внутри рабочего процесса

Каждый рабочий процесс NGINX инициализируется с заданной конфигурацией и набором слушающих сокетов, унаследованных от мастер-процесса.

Рабочие процессы начинают с ожидания событий на слушающих сокетах (см. также accept_mutex и разделяемые сокеты). События извещают о новых соединениях. Эти соединения попадают в конечный автомат — наиболее часто используемый предназначен для обработки HTTP, но NGINX также содержит конечные автоматы для обработки потоков TCP трафика (модуль stream) и целого ряда протоколов электронной почты (SMTP, IMAP и POP3).

Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.

Устройство конечного автомата

Конечный автомат можно представить себе в виде правил для игры в шахматы. Каждая HTTP транзакция — это шахматная партия. С одной стороны шахматной доски веб-сервер — гроссмейстер, который принимает решения очень быстро. На другой стороне — удаленный клиент, браузер, который запрашивает сайт или приложение по относительно медленной сети.

Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.

Блокирующийся конечный автомат

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

1. Процесс веб-сервера ожидает новых соединений (новых партий инициированных клиентами) на слушающих сокетах.
2. Получив новое соединение, он играет партию, блокируясь после каждого хода в ожидании ответа от клиента.
3. Когда партия сыграна, процесс веб-сервера может находиться в ожидании желания клиента начать следующую партию (это соответствует долгоживущим keepalive-соединениям). Если соединение закрыто (клиент ушел или наступил таймаут), процесс возвращается к встрече новых клиентов на слушающих сокетах.

NGINX, как настоящий Гроссмейстер

Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?

Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.

Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните — обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.

1. Рабочий процесс ожидает событий на слушающих сокетах и сокетах соединений.
2. На сокетах происходят события и процесс их обрабатывает:
3. Событие на слушающем сокете означает, что пришел новый клиент для начала игры. Рабочий процесс создает новый сокет соединения.
4. Событие на сокете соединений сигнализирует, что клиент сделал ход. Рабочий процесс ему мгновенно отвечает.

Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?

Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.

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

Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.

С адекватной настройкой системы, NGINX прекрасно масштабируется до многих сотен тысяч параллельных HTTP cоединений на каждый рабочий процесс и уверенно поглощает всплески трафика (толпы новых игроков).

Обновление конфигурации и исполняемого кода

Архитектура NGINX с малым количеством рабочих процессов позволяет достаточно эффективно обновлять конфигурацию и даже его собственный исполняемый код на лету.

Обновление конфигурации NGINX — очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.

1. Перезагружает конфигурацию и порождает новый набор рабочих процессов. Эти новые рабочие процессы сразу начинают принимать соединения и обрабатывать трафик (используя новые настройки).
2. Сигнализирует старые рабочие процессы о плавном завершении. Они перестают принимать новые соединения. Как только завершается обработка текущих HTTP-запросов, соединения закрываются (никаких затянувшихся keep-alive соединений). Как только все соединения закрыты, рабочий процесс завершается.

Обновление исполняемого кода NGINX — это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.

Процесс обновления исполняемого кода использует схожий с перезагрузкой конфигурации подход. Новый мастер-процесс NGINX запускается параллельно со старым и получает от него дескрипторы слушающих сокетов. Оба процесса загружены и их рабочие процессы обрабатывают трафик. Затем вы можете отдать команду старому мастер-процессу на плавное завершение.

Вся процедура подробно описана в документации.

Подведем итоги