Nginx - небольшой по размерам, очень быстрый, достаточно функциональный веб сервер и почтовый прокси-сервер, разработчик Игорь Сысоев ( rambler.ru ). Из-за очень маленького потребления ресурсов системы и скорости работы, а так-же гибкости конфигурирования, веб сервер Nginx часто используется в качестве фронтэнда к более тяжеловесным серверам, такими как Apache, в проектах с высокой нагрузкой. Классическим вариантом является связка, Nginx - Apache - FastCGI. Работая в такой схеме, сервер Nginx, принимает все запросы приходящие по HTTP, и в зависимости от конфигурации и собственно самого запроса, решает, обработать-ли запрос самому и отдать клиенту готовый ответ или отправить запрос на обработку, одному из бакэндов ( Apache или FastCGI ).
Как известно, сервер Apache, каждый запрос обрабатывает в отдельном процессе ( потоке ), которые надо сказать, отжирают довольно НЕмаленькое количество системных ресурсов, если таких процессов 10-20, ерунда, а если их 100-500 и больше, системе становится не весело.
Попробуем представить подобную ситуацию. Предположим, на Apache приходит 300 HTTP запросов от клиентов, 150 клиентов сидят на быстрых выделенных линиях, а другие 150, на сравнительно медленных интернет каналах, пусть даже не на модемах. Что происходит в данной ситуации? А происходит следующее, веб сервер Apache, что-бы обработать эти 300 соединений, создает на каждое по процессу ( потоку ), контент он сгенерит быстро, и 150 быстрых клиентов тут-же заберут результат своих запросов, процессы их обслуживавшие будут убиты а ресурсы высвобождены, а 150 медленных, и забирать результаты своих запросов будут медленно, в силу неширокого интернет канала, в результате чего в системе будет висеть 150 процессов Apache, ожидающих, когда-же клиенты заберут сгенерированный веб сервером контент, пожирая массу системных ресурсов. Естественно ситуация гипотетическая, но суть думаю понятна. Исправить вышеописанную ситуацию и помогает связка Nginx + Apache + FastCGI. Прочитав весь запрос от клиента, он передает его на обработку Apache, который в свою очередь генерирует контент и максимально быстро возвращает готовый ответ в Nginx, после чего может со спокойной совестью прибить процесс и освободить занимаемые им системные ресурсы. веб сервер Nginx, получив результат запроса от Apache, записывает его в буфер или вообще в файл на диске и может сколь угодно долго отдавать его медленным клиентам, при этом его рабочие процессы едят так мало ресурсов что.. "об этом даже смешно говорить" ©. :) Такая схема, существенно экономит системные ресурсы, повторюсь, но рабочие процессы Nginx потребляют мизерное количество ресурсов, это тем-более актуально для больших проектов.
И это только малая часть того, что умеет сервер Nginx, не стоит забывать про возможности кэширования данных и работу с memcached. Приведу список основных функциональных возможностей веб сервера Nginx.
Функционал сервера Nginx в качестве HTTP сервера
- Обработка статического контента, индексные файлы, листинг директорий, кэш дескрипторов открытых файлов;
- Акселерированное проксирование с кэширование, распределение нагрузки и отказоустойчивостью;
- Акселерированная поддержка FastCGI серверов с кэшированием, распределением нагрузки и отказоустойчивостью;
- Модульная структура, поддержка различных фильтров ( SSI, XSLT, GZIP, докачка, chunked ответы );
- Поддержка SSL и расширения TLS SNI;
- Ip-based или Name-based виртуальные сервера;
- Работа с KeepAlive и pipelined соединениями;
- Возможность конфигурирования любых таймаутов а так-же количества и размеров буферов, на уровне сервера Apache;
- Выполнение различных действий в зависимости от адреса клиента;
- Изменение URI с помощью регулярных выражений;
- Специальные страницы ошибок для 4хх и 5хх;
- Ограничение доступа на основе адреса клиента или по паролю;
- Настройка форматов лог-файлов, ротация логов;
- Ограничение скорости ответа клиенту;
- Ограничение количества одновременных подключений и запросов;
- Поддержка методов PUT, DELETE, MKCOL, COPY и MOVE;
- Изменение настроек и обновление сервера без остановки работы;
- Встроенный Perl;
Функционал сервера Nginx, в качестве почтового прокси-сервера
- Форвардинг на IMAP/POP3 бакэнд, используя внешний HTTP сервер аутентификации;
- Проверка SMTP пользователя на внешнем HTTP сервере аутентификации и форвардинг на внутренний SMTP сервер;
- Поддержка следующих способов аутентификации:
- POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
- IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
- SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
- Поддержка SSL;
- поддержка STARTTLS и STLS;
Операционные системы и платформы, поддерживаемые веб сервером Nginx
- FreeBSD, с 3 по 8 - платформы, i386 и amd64;
- Linux, с 2.2 по 2.6 - платформа i386; Linux 2.6 - amd64;
- Solaris 9 - платформы i386 и sun4u; Solaris 10 - платформы i386, amd64 и sun4v;
- MacOS X платформы ppc, i386;
- Windows XP, Windows Server 2003; ( на данный момент в стадии бета-тестирования )
Архитектура и масштабируемость сервера Nginx
- Основной ( master ) процесс, несколько ( настраивается в файле конфигурации ) рабочих процессов, работающих под непривилегированным пользователем;
- Поддержка следующих методов обработки соединений:
- select - стандартный метод. Соответствующий модуль Nginx собирается автоматически, если на данной платформе не найдено более эффективного метода. Можно принудительно включить или отключить сборку данного модуля с помощью параметров конфигурации --with-select_module или --without-select_module.
- poll - стандартный метод. Соответствующий модуль Nginx собирается автоматически, если на данной платформе не найдено более эффективного метода. Можно принудительно включить или отключить сборку данного модуля с помощью параметров конфигурации --with-poll_module или --without-poll_module.
- kqueue - эффективный метод, используемый в операционных системах FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и MacOS X. При использовании на двухпроцессорных машинах с MacOS X может вызвать kernel panic.
- epoll - эффективный метод, используемый в Linux 2.6+. В некоторых дистрибутивах, например SuSE 8.2, есть патчи для поддержки epoll ядром 2.4.
- rtsig - real time signals, эффективный метод, используемый в Linux 2.2.19+. По-умолчанию в очереди для всей системы, не может находиться более 1024 сигналов. Этого мало для серверов с высокой нагрузкой, размер очереди нужно увеличить с помощью параметра ядра /proc/sys/kernel/rtsig-max. Однако, начиная с Linux 2.6.6-mm2, этот параметр отсутствует, вместо этого у каждого процесса существует отдельная очередь сигналов, размер которой определяется с помощью RLIMIT_SIGPENDING.
- При переполнении очереди, сервер nginx сбрасывает её и обрабатывает соединения с помощью метода poll до тех пор, пока ситуация не придет в норму.
- /dev/poll - эффективный метод, поддерживается в операционных системах Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ и Tru64 UNIX 5.1A+.
- eventport - event ports, эффективный метод, используемый в Solaris 10. Перед использованием, необходимо установить патч, во избежания kernel panic.
- Использование возможностей метода kqueue, таких как EV_CLEAR, EV_DISABLE (для временного выключения события), NOTE_LOWAT, EV_EOF, число доступных данных, коды ошибок;
- Работа с sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) и sendfilev (Solaris 8 7/01+);
- Поддержка accept-фильтров (FreeBSD 4.1+) и TCP_DEFER_ACCEPT (Linux 2.4+);
- На 10 000 неактивных HTTP keep-alive соединений тратится примерно 2.5M памяти;
- Минимальное количество операций копирования данных;